Mobil uygulama yaptırma maliyeti neye bağlı

Mobil uygulama maliyeti neye bağlı?

Mobil uygulama maliyeti, uygulamanın ne yaptığına, kaç platformda çalıştığına ve arkasında ne kadar sistem olduğuna bağlıdır. Aynı adı taşıyan iki uygulamanın fiyatı arasında büyük fark olabilir. Birinde kullanıcı sadece içerik okur. Diğerinde ödeme yapar, sipariş verir, bildirim alır ve verisi muhasebeye gider.

Bu yazıda fiyatı oluşturan kalemleri tek tek anlatıyoruz. Rakam vermiyoruz. Çünkü rakam, kapsam yazılmadan söylenirse ya yanlış olur ya da sonradan değişir. Kalemleri bilirseniz gelen teklifleri de doğru karşılaştırırsınız.

Tek platform mu, iki platform mu?

İki platform her zaman iki kat maliyet demek değildir. Uygulamayı iOS için Swift, Android için Kotlin ile ayrı ayrı yazarsanız iki kod tabanı olur. İki ekip ya da iki kat iş gerekir. Flutter ya da React Native ile tek kod tabanından iki platforma çıkarsanız işin büyük kısmı bir kez yapılır.

Hangi yolun uygun olduğu uygulamanın ne yaptığına bağlıdır. Ayrıntısını Native mi, Flutter / React Native mi yazısında anlattık. Kısaca: çoğu iş uygulaması için tek kod tabanı yeterlidir ve bütçeyi korur.

Ekran sayısı fiyatı nasıl etkiler?

Ekran sayısı fiyatı etkiler ama tek başına belirlemez. Bir giriş ekranı ile bir ödeme ekranı aynı iş değildir. Ödeme ekranında doğrulama, hata durumları, iptal, iade ve güvenlik vardır. Bu yüzden ekranları saymak yerine her ekranın ne yaptığını yazmak daha doğru sonuç verir.

Genellikle şu ekranlar her uygulamada bulunur: giriş ve kayıt, şifre sıfırlama, profil, ayarlar, bildirim izinleri. Bunlar temel yükü oluşturur. Sizin işinize özel ekranlar bunun üstüne eklenir.

Arka uç ve yönetim paneli neden bütçenin büyük kısmı?

Arka uç, uygulamanın telefonda görünmeyen ama her şeyi çalıştıran kısmıdır ve çoğu projede işin en büyük parçasıdır. Kullanıcı hesapları, siparişler, içerikler ve bildirimler burada tutulur. Telefon bu sisteme bir API üzerinden bağlanır. API, iki yazılımın birbiriyle konuşmasını sağlayan kapıdır.

Bir de yönetim paneli vardır. Ürün eklemek, siparişi onaylamak, kullanıcıya mesaj göndermek için ekibinizin kullandığı web ekranıdır. Uygulama sahipleri bu paneli çoğu zaman teklifte fark etmez. Oysa ekibiniz her gün onu kullanır. Teklifte panelin olup olmadığını ve ne yaptığını mutlaka sorun.

Hangi özellikler maliyeti artırır?

Maliyeti en çok artıran özellikler, dışarıdaki bir sistemle konuşan ya da gerçek zamanlı çalışan özelliklerdir. Sık karşılaştığımız kalemler şunlar:

• Ödeme: Kart ile ödeme, taksit, iade ve mağaza içi satın alma.
• Bildirim: Anlık bildirimler ve hangi kullanıcıya ne zaman gideceğinin kuralları.
• Harita ve konum: Adres seçimi, en yakın şube, canlı konum takibi.
• Mesajlaşma: Kullanıcılar arası ya da destek ekibiyle canlı yazışma.
• Çevrimdışı çalışma: İnternet yokken veri girip sonra eşitleme.
• Dış sistemler: Muhasebe, e-fatura, kargo, CRM ya da mevcut web sitenizle bağlantı.
• Dil ve bölge: Birden fazla dil, para birimi ya da ülke kuralı.

Her biri tek başına makul bir iştir. Toplandıklarında ise bütçeyi belirgin biçimde büyütür. Bu yüzden ilk sürümde hangisinin gerçekten gerekli olduğunu konuşmak önemlidir.

Tasarım maliyeti ne kadar etkiler?

Tasarım, ne kadar özel olduğuna göre maliyeti etkiler. iOS ve Android kullanıcıların alıştığı standart bileşenler sunar. Bunları kullanmak hem hızlıdır hem de kullanıcı için tanıdıktır. Her düğmesi ve geçişi size özel bir arayüz daha fazla tasarım ve geliştirme süresi ister. İkisi de doğru olabilir. Önemli olan seçimi bilerek yapmaktır.

Yayından sonra hangi masraflar çıkar?

Yayından sonra mağaza hesapları, sunucu ve güncellemeler için düzenli masraf çıkar. Apple Developer Program yıllık üyelik ister. Google Play geliştirici hesabı ise bir kerelik kayıt ücretiyle açılır. Güncel ücretleri iki firmanın kendi sayfalarından kontrol edin. Uygulama içinden dijital içerik satıyorsanız mağazaların komisyon kuralları da geçerlidir.

Asıl gözden kaçan kalem güncellemelerdir. Apple ve Google her yıl işletim sistemlerini günceller. Mağaza kuralları da değişir. Uygulamanın bu değişikliklere uyarlanması gerekir. Aksi hâlde uygulama bir süre sonra düzgün çalışmayabilir ya da mağazada güncelleme yapamazsınız. Bu işi bakım ve destek kapsamında düşünün ve baştan fiyatını öğrenin.

Mağazaya ilk gönderim de ayrı bir iştir. Ekran görüntüleri, gizlilik bilgileri, inceleme süreci ve olası ret sebepleri takvime eklenmelidir. Bu adımları uygulamayı mağazaya yüklemek yazısında ayrıca anlattık.

Bizde teslimden sonraki 30 gün hata düzeltme ücretsizdir. Sonrası isteğe bağlı aylık bakımdır ve ayrı, tek sayfalık bir teklifle yazılır.

Maliyeti düşürmenin doğru yolu nedir?

Maliyeti düşürmenin doğru yolu kaliteden değil, kapsamdan kısmaktır. İlk sürümü, işinizin çalışması için gereken en küçük hâliyle yayına alın. Buna MVP denir. MVP, gerçek kullanıcıya çıkabilen en küçük çalışır üründür.

Kullanıcılar uygulamayı kullanmaya başlayınca neye ihtiyaç olduğu netleşir. İkinci sürümü tahmine değil, gerçek kullanıma göre yaparsınız. Bu yol genellikle hem daha ucuza hem de daha doğru sonuca çıkar. İlk sürümün kapsamını nasıl daralttığımızı MVP nasıl yapılır yazısında adım adım anlattık.

Doğru teklif için neler hazırlanmalı?

Doğru teklif için uygulamanın kimin için olduğunu ve ne yapacağını yazmanız yeterlidir. Teknik belge gerekmez. Şu soruların cevabı işi büyük ölçüde netleştirir:

1. Uygulamayı kim kullanacak: müşterileriniz mi, çalışanlarınız mı?
2. Kullanıcı uygulamada ilk ne yapacak, en sık ne yapacak?
3. Uygulama iOS, Android ya da ikisinde mi olacak?
4. Hangi mevcut sistemlerinize bağlanması gerekiyor?
5. Ödeme alınacak mı, bildirim gönderilecek mi?
6. Yayına çıkması gereken bir tarih var mı?

Bu cevaplarla size tek sayfalık bir teklif hazırlarız. Fiyat baştan bellidir. Ardından ne zaman bittiğini yazan bitiş tanımı imzalanır ve iş başlar. Sürecin tamamını nasıl çalışıyoruz sayfasında görebilirsiniz. Mobil tarafta ne yaptığımızı ise mobil uygulama geliştirme sayfasında anlattık.

Uygulama mı, mobil uyumlu site mi?

Kullanıcı uygulamayı sık açmayacaksa çoğu zaman mobil uyumlu bir site yeterlidir ve daha az maliyetlidir. Bir kez bakılan bilgi, bir kampanya sayfası ya da ayda bir verilen sipariş için kullanıcı uygulama indirmek istemez. Telefonda iyi çalışan bir site bu işi görür. Buna responsive tasarım denir: sayfa ekran boyutuna göre kendini düzenler.

Uygulama, kullanıcının haftada birkaç kez döndüğü işlerde anlam kazanır. Bildirim göndermek, kamerayı ya da konumu kullanmak ve giriş yapmış kullanıcıya hızlı erişim sunmak uygulamanın güçlü yanlarıdır. Arada bir yol da vardır. PWA, tarayıcıda çalışan ama ana ekrana eklenebilen web uygulamasıdır. Bazı işler için makul bir orta noktadır. Ancak cihaz özelliklerine erişimi ve mağaza görünürlüğü mağaza uygulamasına göre sınırlıdır.

Karar verirken şu soruyu sorun: kullanıcı bu işi ne sıklıkla yapıyor ve işi telefona ne kadar bağlı? Cevap "ara sıra" ise önce siteyi güçlendirin. Cevap "her gün" ise uygulama bütçesini konuşmaya değer.

Mobil uygulama bütçesinde sık yapılan hatalar nelerdir?

En sık hata, bütçeyi sadece telefonda görünen ekranlara göre planlamaktır. Teklif aşamasında şu hataları sık görüyoruz:

• Yönetim panelini unutmak: Uygulama hazırdır ama içeriği kimin, nereden güncelleyeceği belli değildir.
• İlk sürüme her şeyi koymak: Mesajlaşma, sadakat programı, çoklu dil ve harita aynı anda istenir. Takvim uzar, bütçe büyür, gerçek kullanıcı geri bildirimi gecikir.
• Bakımı hesaba katmamak: Yayından sonraki işletim sistemi uyarlamaları bütçede yer almaz. Bir süre sonra uygulama mağazada güncellenemez hâle gelir.
• Kullanıma bağlı ücretleri görmemek: SMS, harita ve bildirim servisleri kullanıcı sayısı arttıkça ücretlenebilir.
• Hesapları başkasının adına açtırmak: Mağaza hesabı geliştiricinin adına açılırsa uygulamayı sonradan taşımak zahmetli olur.
• Teklifleri sadece toplam rakama göre karşılaştırmak: Ucuz görünen teklifte panel, test ya da mağaza gönderimi olmayabilir.

Teklifleri kalem kalem nasıl yan yana koyacağınızı yazılım teklifi karşılaştırma yazısında anlattık.

Örnek senaryo: randevu uygulamasının kalemleri nasıl çıkar?

Kalemler, uygulamanın her adımında hangi kuralın çalıştığı yazılınca çıkar. Bunu varsayımsal bir örnekle gösterelim. Birkaç şubesi olan bir güzellik salonu, müşterilerinin telefondan randevu almasını istiyor. Rakam vermeden işin hangi parçalardan oluştuğuna bakalım.

Telefonda kayıt, giriş, şube ve hizmet seçimi, uygun saatlerin listesi, randevu onayı ve randevu geçmişi ekranları vardır. Arka uçta şubeler, çalışanlar, hizmet süreleri ve çalışma saatleri tutulur. Aynı saate iki randevu düşmemesi için kurallar yazılır. Yönetim panelinde salon ekibi günlük takvimi görür, randevuyu iptal eder ya da başka saate taşır. Randevudan bir gün önce hatırlatma bildirimi gider.

İlk sürümde online ödeme, sadakat puanı ve çoklu dil gerekmeyebilir. Bunlar ikinci sürüme bırakılırsa ilk sürüm daha kısa sürede yayına çıkar. Salonun gerçek kullanım verisi de ikinci sürümün önceliklerini belirler. Aynı uygulama baştan ödeme ve puan sistemiyle istenirse iş belirgin biçimde büyür. Fark ekran sayısından değil, arkadaki kurallardan gelir.

İki platformu tek kod tabanıyla nasıl çıkardığımızı Flutter ile uygulama geliştirme sayfasında anlattık.