Mobil Uygulama Fiyatları Neye Göre Değişir?

İşletmeniz için bir uygulama fikriniz var: müşteriler sipariş versin, randevu alsın ya da kampanyalardan bildirimle haberdar olsun. İlk sorunuz büyük ihtimalle “bu kaça mal olur?” olacak. Mobil uygulama fiyatları, telefonda gördüğünüz ekranlardan çok daha fazlasına bağlıdır: hangi platformda çalışacağı, verileri nerede tutacağı, hangi servislerle konuşacağı ve mağazalarda nasıl yaşatılacağı. Bu yazıda rakam vermeden, maliyeti oluşturan kalemleri ve bütçeyi nasıl daha verimli kullanabileceğinizi anlatıyorum.

Bir mobil uygulama aslında üç parçadan oluşur

Kullanıcının gördüğü uygulama, buzdağının yalnızca görünen kısmıdır. Çoğu uygulama arkasında iki parça daha taşır:

• Mobil uygulama: Telefonda çalışan arayüz; ekranlar, butonlar, formlar ve bildirimler.
• Backend (sunucu tarafı): Kullanıcı hesapları, siparişler, randevular gibi verilerin tutulduğu ve iş kurallarının işletildiği sistem. Uygulama bu sistemle bir API üzerinden konuşur.
• Yönetim paneli: İşletmenin içerik, ürün, kullanıcı ve siparişleri yönettiği web tabanlı arayüz.

Tekliflerde bu üç parçanın ayrı ayrı görünmesi önemlidir. Yalnızca uygulama ekranlarını fiyatlayan bir teklif, sunucu ve panel kısmını sonradan ek maliyet olarak karşınıza çıkarabilir. Sunucu tarafının neleri kapsadığını mobil uygulama backend’i yazısında ayrıca anlattım.

Platform tercihi mobil uygulama fiyatlarını nasıl etkiler?

Uygulamanın iOS ve Android’de çalışması gerekiyorsa iki yol vardır. Birincisi her platform için ayrı ayrı native uygulama yazmaktır; bu, iki ayrı kod tabanı ve genellikle daha fazla emek demektir. İkincisi Flutter gibi çapraz platform bir teknolojiyle tek kod tabanından iki platforma da uygulama çıkarmaktır.

Çoğu işletme uygulaması için çapraz platform yaklaşım, geliştirme ve bakım maliyetini belirgin biçimde düşürür. Kamera, Bluetooth veya yoğun grafik gibi cihaza çok bağımlı işlerde native geliştirmenin avantajları öne çıkabilir. Bu kararın ayrıntılarını native mi hibrit mi karşılaştırmasında bulabilirsiniz.

Fiyatı belirleyen başlıca kalemler

Kalem	Neye göre değişir?
Ekran sayısı ve akışlar	Kaç farklı ekran, form ve kullanıcı yolculuğu olduğu
Kullanıcı hesapları	E-posta, telefonla doğrulama veya sosyal hesapla giriş seçenekleri
Arayüz tasarımı	Hazır bileşenlerle sade tasarım mı, markaya özel kapsamlı tasarım mı
Backend ve panel	Mevcut bir sistem mi kullanılacak, sıfırdan mı yazılacak
Entegrasyonlar	Ödeme, harita, SMS, kargo, mevcut web sitesi veya ERP bağlantıları
Bildirimler	Toplu duyuru mu, kullanıcıya özel tetiklenen bildirimler mi
Çevrimdışı çalışma	İnternet yokken verinin saklanıp sonra senkronize edilmesi
Mağaza süreçleri	Geliştirici hesapları, mağaza görselleri, inceleme ve yayınlama

Tablodaki her kalem, kendi içinde basit ya da karmaşık olabilir. Örneğin bildirim özelliği “tüm kullanıcılara kampanya duyurusu” düzeyindeyse görece hızlı yapılır; “siparişiniz yola çıktı” gibi duruma bağlı bildirimler ise backend tarafında ek kurgu gerektirir.

Mevcut bir web siteniz varsa

Halihazırda çalışan bir web siteniz ya da yönetim sisteminiz varsa, uygulama aynı veriyi kullanabilir. Bu durumda backend’i sıfırdan yazmak yerine mevcut sisteme bir API katmanı eklemek yeterli olabilir. Örneğin altın fiyatları eklentisi ve mobil uygulaması projesinde Flutter uygulaması, WordPress eklentisinin önbellekli REST API’si üzerinden aynı fiyat verisini kullanıyor. Böyle bir yapı, hem maliyeti hem de iki ayrı sistemi güncel tutma yükünü azaltır.

Örnek senaryo: aynı fikir, iki farklı kapsam

Bir restoran sahibi, müşterilerinin telefondan sipariş verebileceği bir uygulama istiyor. Birinci kapsamda uygulama menüyü gösteriyor, müşteri sepetini oluşturuyor ve siparişi kapıda ödeme seçeneğiyle gönderiyor; restoran siparişleri basit bir panelden görüyor. İkinci kapsamda buna online kartla ödeme, sadakat puanı, kurye takibi, kampanya bildirimleri ve kasadaki adisyon sistemiyle senkronizasyon ekleniyor.

İki proje de “restoran sipariş uygulaması” diye anılır, ama ikincisi hem backend hem test açısından katlarca fazla emek ister. Bu yüzden mobil uygulama fiyatları konuşulurken önce kapsamı ilk sürüm ve sonraki sürümler olarak ayırmak, bütçeyi gerçekçi tutmanın en etkili yoludur. İlk sürüm sahada denendikten sonra hangi ek özelliğin gerçekten talep gördüğü de netleşir.

Yayından sonra da maliyet devam eder

Uygulama mağazaya çıktığında iş bitmiş olmaz. Mobil uygulama fiyatları planlanırken şu düzenli kalemler de hesaba katılmalıdır:

1. Mağaza geliştirici hesapları: Apple ve Google’ın geliştirici hesapları için kendi ücret ve kuralları vardır; güncel şartları ilgili mağazanın sitesinden kontrol edin.
2. Sunucu ve servisler: Backend’in çalıştığı sunucu, bildirim, SMS veya harita gibi kullanıma bağlı servisler.
3. İşletim sistemi güncellemeleri: iOS ve Android’in yeni sürümleriyle uyumluluk ve mağazaların değişen gereksinimleri, uygulamanın düzenli güncellenmesini gerektirir.
4. Hata düzeltme ve yeni özellikler: Kullanıcı geri bildirimleriyle doğan iyileştirmeler.

Bu kalemleri teklif aşamasında konuşmak, uygulamanın bir yıl sonra güncellenemediği için mağazadan kalkması gibi tatsız sürprizleri önler.

Bütçeyi verimli kullanmanın yolları

• Çekirdek özelliklerle başlayın: İlk sürümde kullanıcının uygulamayı indirme nedeni olan bir iki temel işleve odaklanın.
• Önce PWA’yı değerlendirin: Bazı ihtiyaçlar, mağazaya çıkmadan telefona eklenebilen bir web uygulamasıyla karşılanabilir.
• Tasarımı sadeleştirin: Platformun kendi bileşenlerini kullanan temiz bir arayüz, hem daha hızlı geliştirilir hem kullanıcıya tanıdık gelir.
• Kaynak kodunu güvenceye alın: İleride başka bir geliştiriciyle devam edebilmek için kodun ve mağaza hesaplarının sizin adınıza olması gerekir.

Uygulama geliştirme sürecinin genel adımlarını merak ediyorsanız mobil uygulama geliştirme rehberine göz atabilirsiniz.

Bu işi nasıl birlikte yaparız?

1. İhtiyacı dinleme: Uygulamanın kimler için olduğunu, kullanıcının hangi işi yapmak için açacağını ve mevcut sistemlerinizi konuşuruz.
2. Kapsam ve teklif: Uygulama, backend ve yönetim panelini ayrı kalemler olarak gösteren, ilk sürüm ile sonraki sürümleri ayıran bir teklif hazırlarım.
3. Geliştirme ve test: Flutter ile tek kod tabanından ilerler, test sürümünü telefonunuza yükleyerek gerçek cihazda denemenizi sağlarım.
4. Teslim ve destek: Mağaza başvurusu ve yayın sürecinde yanınızda olur, sonrasında işletim sistemi güncellemeleri ve iyileştirmeler için bakım planı yaparız.

Uygulama fikrinizi konuşmak ve kalemleri netleştirmek isterseniz iletişim sayfasından bana ulaşabilirsiniz.

Sık sorulan sorular

iOS ve Android için ayrı ayrı mı ödeme yaparım?

Native geliştirmede iki ayrı uygulama yazıldığı için emek artar. Flutter gibi çapraz platform teknolojilerle tek kod tabanından iki platforma da çıkılabildiği için maliyet genellikle daha dengeli olur.

Uygulamanın yönetim paneli fiyata dahil midir?

Teklife göre değişir. İçerik, ürün veya kullanıcı yönetimi gerekiyorsa panelin kapsamda olup olmadığını mutlaka sorun; ayrı fiyatlanması sık görülen bir durumdur.

Uygulamayı mağazaya kim yükler?

Yükleme işini genellikle geliştirici yapar, ancak geliştirici hesaplarının işletme adına açılması önerilir. Böylece uygulamanın sahipliği her zaman sizde kalır.

Yayından sonra güncelleme yapmak zorunlu mu?

Mağazalar ve işletim sistemleri zamanla yeni gereksinimler getirir. Düzenli güncellenmeyen uygulamalar uyumsuz hâle gelebilir; bu yüzden bir bakım planı yapılması önerilir.

Sonuç

Mobil uygulama fiyatları; platform tercihi, ekran ve akış sayısı, backend ve panel ihtiyacı, entegrasyonlar ve yayın sonrası bakım kalemlerinin toplamıyla belirlenir. Fikrinizi bu kalemlere göre birlikte netleştirmek isterseniz bana yazabilirsiniz.