Mobil uygulama maliyetini ne belirler? Teklif istemeden önce

Mobil uygulama maliyetini tek bir rakam değil, uygulamanın ne kadar iş yaptığı belirler. Başlıca faktörler ilk sürümün kapsamı, sunucu ve hesap sistemi ihtiyacı, başka sistemlerle bağlantılar, platform ve dil sayısı, tasarımın özgünlüğü ve yayından sonraki bakımdır. Bu yazıda her faktörü teker teker açıyor, teklif istemeden önce hazırlayabileceğiniz bir kontrol listesi veriyoruz.

Bir not: fiyat listemiz yok. Bu yazıda da rakam bulmayacaksınız. Bunun nedeni gizlilik değil; aynı cümleyle tarif edilen iki uygulamanın maliyeti arasında çok büyük fark olabilmesi. Kapsamı ilk görüşmede birlikte netleştiriyor, ardından yazılı teklif veriyoruz.

“Bir ev kaça olur?” sorusunu düşünün. Kaç oda, hangi semt, hangi malzeme, bahçe var mı? Mobil uygulama da böyledir. “Randevu alınan bir uygulama” cümlesi; tek bir işletmenin takvimini gösteren sade bir uygulamayı da, ödeme alan, hatırlatma gönderen, yönetim paneli olan ve muhasebeye bağlanan bir sistemi de anlatabilir.

Bu yüzden maliyeti konuşmanın en sağlıklı yolu, onu oluşturan parçaları ayırmaktır. Süreç tarafını — keşif, prototip, geliştirme, mağaza yayını — mobil uygulama yaptırmak yazımızda anlattık. Burada yalnız maliyete odaklanıyoruz.

1. Kapsam: ilk sürümde ne olacak?

Maliyetin en büyük belirleyicisi kapsamdır. Kapsam da ekran sayısından çok, işlev sayısıyla ölçülür. Bir ekranda yalnız liste gösterilebilir; bir başka ekranda filtreleme, düzenleme, paylaşma ve çevrimdışı kayıt aynı anda çalışabilir.

En büyük tasarruf, ilk sürümü küçültmekten gelir. İlk sürüm her şeyi yapan bir ürün değil, tek bir sorunu iyi çözen bir MVP olmalı. Tako’da çekirdek baştan netti: abonelikleri tek ekranda toplamak, aylık ve yıllık toplamı göstermek, yenileme gününden önce hatırlatmak. Bunun dışındaki her fikir “sonra” listesine yazıldı.

Kendinize şu soruyu sorun: Bu özellik olmasa, kullanıcı uygulamayı yine de kullanır mı? Cevap evetse, o özellik ilk sürümün dışında kalabilir.

2. Veri nerede duruyor? Sunucu ve hesap sistemi

Görünmeyen ama maliyeti en çok etkileyen kararlardan biri budur. İki temel yol var:

• Veri cihazda. Uygulama, verisini telefonda tutar. Hesap açmak, giriş yapmak, sunucu işletmek gerekmez. Yapı sadeleşir.
• Veri sunucuda. Kullanıcılar hesap açar, veriler bir sunucuda tutulur, cihazlar arası eşitleme yapılır. Bu, bir arka uç (backend), bir yönetim paneli ve sunucu işletme maliyeti demektir.

Tako ikinci yolu bilinçli olarak seçmedi. Hesap yok, zorunlu bağlantı yok; veriler yerel öncelikli bir yaklaşımla cihazda. Bu hem gizliliği varsayılan yaptı hem de yapıyı sadeleştirdi. Ama her ürün için doğru değildir: ekip içinde paylaşılan veri, merkezi rapor ya da birden fazla cihazda aynı hesap gerekiyorsa sunucu kaçınılmazdır.

Sunucu gerekiyorsa şu sorular maliyeti belirler: Kaç kullanıcı rolü olacak? Yönetim paneli gerekiyor mu? Veriler gerçek zamanlı mı eşitlenecek?

3. Entegrasyonlar: uygulama kimlerle konuşuyor?

Uygulama tek başına mı çalışıyor, yoksa başka sistemlerle mi konuşuyor? Her bağlantı ayrı bir iş kalemidir:

• Ödeme altyapısı ya da uygulama içi satın alma,
• Mevcut bir CRM, sipariş ya da stok sistemi,
• Harita, konum ve takvim servisleri,
• Bildirim altyapısı,
• Üçüncü taraf bir API ile veri alışverişi.

Bağlantının maliyetini karşı tarafın belgeleri ve kararlılığı da etkiler. İyi belgelenmiş bir servisle konuşmak kolaydır. Belgesi eksik, eski bir iç sistemle konuşmak ise keşif ve test ister.

Gelir modeli de bir entegrasyondur. Dijital içerik ve abonelik satışında mağazaların uygulama içi satın alma kuralları geçerlidir. Tako’da ücretsiz sürüm reklam destekli, genişletilmiş özellikler uygulama içi satın almayla geliyor. Bu kurgu baştan planlandığı için sonradan maliyetli bir yeniden düzenleme gerekmedi.

4. Platform: iOS, Android ya da ikisi

iOS ve Android’e ayrı ayrı uygulama yazmak, iki ayrı proje ve iki ayrı bakım demektir. Tek kod tabanı yaklaşımıyla iki platform tek projeden çıkar; maliyet ve bakım tek elde kalır. Buna rağmen her platformun kendi testi, kendi mağaza başvurusu ve kendi kuralları vardır. “İkisi birden” demek, işin iki katı değildir ama sıfır ek iş de değildir.

Platform kararını ayrıntılı olarak iOS mu, Android mi yazımızda ele alıyoruz.

5. Tasarım, diller ve cihaz özellikleri

Özgün tasarım mı, standart bileşenler mi?

Platformların standart bileşenleriyle kurulan bir arayüz daha hızlı ilerler. Özgün bir görsel dil, özel animasyonlar ve markaya özgü etkileşimler ise daha fazla tasarım ve test emeği ister. İkisi de meşru bir tercihtir; önemli olan bunu bilerek seçmek.

Dil sayısı

Her yeni dil; metin, çeviri, ekran düzeni ve test demektir. Arapça gibi sağdan sola yazılan diller ise arayüzün aynalanmasını gerektirir. Mümin 360 Türkçe, İngilizce ve Arapça çalışıyor. Tako ilk günden 11 dilde. Bu, her metnin ve ekranın on bir dilde düşünülmesi anlamına geliyordu.

Cihaz özellikleri

Kamera, konum, pusula, bildirim, çevrimdışı çalışma. Her biri ayrı izin metni, ayrı test ve ayrı mağaza beyanı ister. Mümin 360’ta namaz vakitleri konuma göre hesaplanıyor, kıble yönü cihaz pusulasıyla bulunuyor ve Kur’an-ı Kerim tamamen çevrimdışı okunabiliyor. Bu özellikler ürünün kalbiydi; ama her biri kapsama ayrı bir satır olarak girdi.

6. Yayından sonrası: bakım da maliyetin parçası

Teklif konuşulurken en sık unutulan kalem budur. Apple ve Google her yıl işletim sistemlerini günceller, yeni cihazlar çıkar, mağaza kuralları değişir. Güncellenmeyen bir uygulama zamanla hata vermeye, hatta mağazadan kaldırılma riskiyle karşılaşmaya başlar.

Mümin 360’ın yolculuğu bunun iyi bir örneği: App Store lansmanının ardından Ramazan Merkezi’ni getiren 2.1, sonra Namaz Alışkanlık Paneli’ni getiren 2.5.0 sürümü geldi. Yaşayan bir uygulama, düzenli sürümlerle yaşar. Bakımı baştan planlamak, sonradan sürpriz bir maliyetle karşılaşmamanın yoludur. Biz bu işi istenirse aylık bakım olarak üstleniyoruz.

Özet ve teklif öncesi hazırlık

Maliyeti artıranlar ve azaltanlar

Faktör	Maliyeti artıran	Maliyeti azaltan
Kapsam	İlk sürüme her şeyi sığdırmak	Tek sorunu çözen bir MVP
Veri	Sunucu, hesap, eşitleme, panel	Cihazda tutulan veri
Entegrasyon	Belgesi zayıf iç sistemler	Az ve iyi belgelenmiş bağlantı
Platform	İki ayrı kod tabanı	Tek kod tabanı
Tasarım	Çok sayıda özel etkileşim	Sade, tekrarlanan akışlar
Diller	Çok dil, sağdan sola diller	Az dille başlamak
Geri bildirim	Uzun onay döngüleri	Düzenli ve hızlı dönüş

Teklif istemeden önce hazırlayabilecekleriniz

Bu listeyi hazırlamanız, gelen teklifleri karşılaştırmayı da kolaylaştırır:

1. Uygulamanın çözdüğü tek cümlelik sorun.
2. Kullanıcı kim? Tek tip mi, yoksa yönetici ve müşteri gibi farklı roller mi var?
3. İlk sürümde olmazsa olmaz üç beş özellik ve “sonra” listesi.
4. Hesap ve giriş gerekiyor mu? Veriler başka cihazda da görünmeli mi?
5. Bağlanması gereken sistemler ve varsa belgeleri.
6. Gelir modeli: ücretsiz, abonelik, tek seferlik satın alma, reklam?
7. Hedef platformlar ve diller.
8. Beğendiğiniz iki üç uygulama ve neden beğendiğiniz.
9. Yayından sonra bakımı kimin yapacağı.

Gelen teklifleri değerlendirirken kapsamın, kaynak kod devrinin ve bakımın nasıl yazıldığına bakmak gerekir. Bunu yazılım teklifi nasıl okunur yazımızda ayrıntılı anlatıyoruz.

Sık sorulan sorular

Neden fiyat listesi yayınlamıyorsunuz?

Çünkü aynı adı taşıyan iki uygulamanın kapsamı birbirinden çok farklı olabilir. Liste fiyatı ya sizi gereksiz yere yüksek bir rakamla karşılar ya da sonradan büyüyen bir faturaya yol açar. Kapsamı birlikte netleştirip yazılı teklif vermeyi daha dürüst buluyoruz.

Teklifler arasındaki büyük farkı nasıl yorumlamalıyım?

Önce kapsamları yan yana koyun. Bir teklif bakım, mağaza yayını ya da yönetim panelini içermiyor olabilir. Kaynak kodun kime ait olacağı ve test sürecinin nasıl işleyeceği de farkın önemli bir kısmını açıklar.

Maliyeti düşürmenin en etkili yolu nedir?

İlk sürümü küçültmek. Tek bir sorunu iyi çözen, verisini mümkünse cihazda tutan ve az sayıda bağlantıyla çalışan bir ilk sürüm, hem daha hızlı yayına çıkar hem de gerçek kullanıcı geri bildirimiyle doğru yönde büyür.

Bakım zorunlu mu?

Sözleşme olarak zorunlu değil; ama uygulamanın çalışmaya devam etmesi için pratikte gereklidir. Kaynak kod size devredildiyse bakımı kendi ekibiniz de yapabilir. Önemli olan, bunun yayından önce planlanmış olması.

Uygulama fikrinizin ilk sürümünü ve onu belirleyen kalemleri birlikte çıkarmak isterseniz mobil uygulama geliştirme sayfamıza bakabilir ya da bize yazabilirsiniz. En geç iki iş günü içinde dönüyoruz.