Mobil Uygulama Fiyatları 2026: Maliyeti Gerçekte Ne Belirliyor?

Telefonda en sık duyduğumuz soru şu: “Basit bir uygulama istiyoruz, aşağı yukarı ne tutar?” Soran haklı, bütçe planı yapması gerekiyor. Ama masaya oturduğumuzda o “basit” kelimesinin içinden üyelik, ödeme, bildirim ve bir yönetim paneli çıkıyor.

Burada TL rakamı yok. Kur, kapsam ve ekip maliyeti değiştikçe yazılan rakam birkaç ayda anlamını yitiriyor ve okuyanı yanlış bir yere çapalıyor. Kalemleri konuşmak daha dürüst: bir teklif hazırlarken neye baktığımızı bilirseniz, elinize gelen teklifleri de kendiniz okuyabilirsiniz.

Kısaca

• Maliyetin büyük kısmı ekranlarda değil, görünmeyen tarafta: API, yönetim paneli ve entegrasyonlar.
• İki platform için tek kod tabanı çoğu projede ciddi tasarruf sağlar; iki platformda test ve iki ayrı mağaza süreci ise yine ortadan kalkmaz.
• Yayın, işin bitişi değil. İşletim sistemleri her yıl güncellenir ve uygulamanın buna ayak uydurması ayrı bir bakım kalemidir.
• Aynı fikir için gelen iki teklif arasında büyük fark varsa, büyük ihtimalle iki firma farklı bir kapsamı fiyatlamıştır.

Platform: iOS mu, Android mi, ikisi birden mi?

Eskiden iki platform, iki ayrı ekip ve neredeyse iki kat bütçe demekti. iOS için Swift, Android için Kotlin ile ayrı uygulamalar yazılır, her özellik iki kez geliştirilirdi. Bu yol hâlâ geçerli ve bazı projelerde doğru tercih, ama çoğu işletme uygulaması için artık varsayılan değil.

Biz mobil uygulama projelerinde çoğunlukla React Native kullanıyoruz, gerektiğinde Flutter'a da uzanıyoruz. Tek kod tabanıyla iki platforma çıkmak, uygulama katmanındaki emeği belirgin biçimde azaltıyor. Yine de her platformda ayrı test, ayrı izin ve bildirim ayarları, iki ayrı mağaza süreci var. “İkinci platform bedava gelir” beklentisi doğru değil. Daha ucuza gelir, o kadar.

Tek platformla başlamak da mantıklı olabilir; yalnız bu kararı tahminle değil veriyle verin. Mevcut web sitenizin ziyaretçi istatistiklerinde iPhone ve Android dağılımına bakmak iyi bir başlangıç.

Ekran sayısı ve tasarım

Teklif isterken çoğu müşteri ekran sayısını söylüyor. Bu iyi bir başlangıç ama tek başına yanıltıcı. “Hakkımızda” ekranı ile filtreli, aramalı, kaydırdıkça yüklenen bir ürün listesi aynı sayılmaz. Birincisi birkaç saatlik iş; ikincisi boş durumu, hata durumu, yükleniyor durumu ve çevrimdışı hâli olan küçük bir sistem.

Tasarım tarafında fark şuradan doğuyor: hazır bir bileşen kütüphanesine marka renklerini giydirmek mi, yoksa her ekranı sıfırdan tasarlamak mı? Özel animasyonlar, tablet uyumu, karanlık mod ve erişilebilirlik (telefonda büyük yazı tipi seçildiğinde ekranın dağılmaması gibi) her biri ayrı saat demek. Hiçbiri lüks değil. Ama hepsinin ilk sürümde olması da gerekmiyor.

Görünmeyen taraf: API ve yönetim paneli

Bütçe konuşmalarında en çok atlanan kalem bu. Uygulama ekranda bir ürün, randevu ya da sipariş gösteriyorsa o veri bir yerden geliyor ve biri onu bir yerden giriyor. Uygulamanın konuştuğu sunucu tarafı (API) ve içerikleri yöneteceğiniz web paneli, çoğu projede uygulamanın kendisi kadar, bazen daha fazla emek istiyor.

İki durum var. Elinizde API'si olan bir sistem (ERP, e-ticaret altyapısı, kendi yazılımınız) varsa uygulama onun üzerine oturur ve maliyet düşer. Hiçbir şey yoksa sunucu tarafı sıfırdan yazılır: veritabanı, kimlik doğrulama, yetkilendirme, bildirim gönderimi, raporlar. API'nin ne olduğunu ve ne işe yaradığını ayrıca anlatmıştık; teklifleri karşılaştırırken bu kalemin dahil olup olmadığını mutlaka sorun.

Özellikler: aynı kelime, çok farklı iş

“Bildirim olsun” cümlesi, herkese aynı mesajı atan tek bir buton da olabilir, kullanıcı gruplarına göre zamanlanmış bir kampanya sistemi de. Aşağıdaki tablo, sık istenen özelliklerin maliyete tipik etkisini gösteriyor. Kesin bir ölçü değil, yön duygusu vermesi için.

Özellik	Maliyete etkisi	Farkı yaratan
Bilgi ve içerik ekranları	Düşük	İçeriğin panelden yönetilip yönetilmeyeceği
Üyelik ve giriş	Orta	SMS doğrulama, şifre sıfırlama, hesap silme
Google / Apple ile giriş	Düşük	Mevcut üyelik yapısıyla eşleştirme
Anlık bildirim	Düşük–orta	Hedefleme ve zamanlama
Harita ve konum	Orta–yüksek	Canlı takip, arka planda konum
Ödeme	Orta–yüksek	Sanal POS mu, uygulama içi satın alma mı
Mesajlaşma, canlı sohbet	Yüksek	Gerçek zamanlı altyapı, moderasyon
Çevrimdışı çalışma	Yüksek	Senkronizasyon ve çakışma çözümü
ERP, muhasebe, kargo entegrasyonu	Değişken	Karşı sistemin belgeleri ve kalitesi
Çoklu dil	Düşük–orta	Baştan planlanıp planlanmadığı

Ödeme satırı ayrıca dikkat istiyor. Fiziksel ürün ya da yerinde verilen bir hizmet satıyorsanız (yemek siparişi, randevu, kargoyla giden ürün) bankanızın sanal POS'uyla çalışırsınız. Dijital içerik satıyorsanız (üyelik, premium özellik, dijital ders) Apple ve Google çoğu durumda kendi uygulama içi satın alma sistemlerini kullanmanızı ister ve bundan komisyon alır. Hangisine girdiğiniz, geliştirme işini de iş modelinizin hesabını da değiştirir.

Entegrasyonlar ise tablodaki en öngörülemez satır. İyi belgelenmiş bir kargo firması API'si birkaç günde bağlanır; belgesi olmayan eski bir muhasebe programıyla veri alışverişi haftalar sürebilir. Karşı sistemi görmeden entegrasyona kesin rakam veren bir teklife biraz şüpheyle bakın.

Mağaza hesapları ve yayın süreci

Uygulamayı yayınlamak için bir Apple Developer hesabı ve bir Google Play geliştirici hesabı gerekiyor. Apple yıllık üyelik ücreti alıyor, Google tek seferlik bir kayıt ücreti. Tutarlar proje bütçesinin yanında küçük kalıyor ama iki ayrıntı önemli.

Birincisi, hesaplar sizin adınıza açılmalı. Uygulamanın ajansın ya da serbest çalışan bir geliştiricinin hesabında yayınlanması, ileride firma değiştirmek istediğinizde başınızı ağrıtır. İkincisi, şirket adına hesap açarken D-U-N-S numarası isteniyor ve bu numaranın çıkması zaman alabiliyor. Bu işi geliştirmenin son haftasına bırakmayın; sözleşmeyi imzaladığınız hafta başlatın.

Mağaza incelemesi de takvime yazılması gereken bir aşama. İlk gönderimde red almak nadir değil; demo hesabı, gizlilik beyanları ve izin açıklamaları gibi ayrıntılar yeniden gönderim gerektirebiliyor. Google Play'de yeni açılan kişisel geliştirici hesapları için, uygulamayı herkese açmadan önce bir kapalı test şartı da var.

Yayından sonra: bakım neden ayrı bir kalem?

Bir web sitesi yayına girdikten sonra uzun süre dokunulmadan çalışabilir. Mobil uygulamada bu lüks yok. Apple ve Google her yıl yeni işletim sistemi sürümleri çıkarıyor. Google Play, uygulamaların belirli bir süre içinde güncel Android sürümlerini hedeflemesini şart koşuyor; Apple da mağazaya gönderilen derlemelerin güncel geliştirme araçlarıyla hazırlanmasını istiyor. Kullandığınız kütüphaneler güncelleniyor, bazıları terk ediliyor.

Pratikte şu anlama geliyor: hiç yeni özellik eklemeseniz bile yılda birkaç kez uygulamayı derleyip test edip yeniden yayınlamanız gerekiyor. Bunun üstüne sunucu barındırma, SMS, harita ve bildirim servisleri gibi kullanıma göre artan giderler geliyor. Bir mobil yazılımın gerçek maliyetini hesaplarken ilk geliştirme bedelinin yanına yıllık bir bakım ve işletim bütçesi koymak gerekiyor. Bunu teklifte açıkça görmek istemek de sizin hakkınız.

Neden iki firma arasında bu kadar fark var?

Aynı brifi üç firmaya gönderip birinden diğerinin birkaç katı teklif almak şaşırtıcı değil. Bunun ardında genellikle şu farklardan biri ya da birkaçı yatıyor:

• Biri yönetim panelini ve API'yi fiyatlamış, diğeri yalnızca uygulama ekranlarını.
• Biri hazır bir şablonu uyarlıyor, diğeri tasarımı sıfırdan yapıyor.
• Birinin teklifinde gerçek cihazlarda test ve mağaza yayını var, diğerinde yok.
• Kaynak kod ve mağaza hesapları birinde size teslim ediliyor, diğerinde firmada kalıyor.
• Yayın sonrası hata düzeltme süresi birinde birkaç ay, diğerinde hiç yok.

Teklifleri toplam rakamla değil, kalem kalem karşılaştırın. Bir teklif diğerinin yarısıysa, eksik yarının hangi kaleme denk geldiğini sorun. Bazen cevap makul çıkar. Bazen de o yarı, yayından birkaç ay sonra ek fatura olarak geri gelir.

Bütçeyi düşürmenin doğru ve yanlış yolları

Bütçeniz sınırlıysa bunu açıkça söyleyin. Rakamı saklayan müşteriye doğru kapsam önermek zor; bütçeyi bilen ekip, o bütçeye sığan en iyi ilk sürümü tasarlayabilir.

Doğru yollar

• İlk sürümü tek bir ana iş akışına indirmek. Kullanıcı uygulamayı neden açacak? O işi iyi yapan bir sürüm, on işi yarım yapan bir sürümden değerlidir.
• İki platform için tek kod tabanıyla çalışmak.
• Yönetim panelini sade tutmak, rapor ekranlarını gerçek ihtiyaç ortaya çıktıkça eklemek.
• Mevcut sistemlerinizin API'sini kullanmak, aynı veriyi ikinci kez girdirmemek.
• Mesajlaşma gibi ağır özellikleri ikinci sürüme bırakmak ya da hazır bir servisle çözmek.

Yanlış yollar

• Test süresini kısmak. Kazandığınız para ilk kötü yorumlarla geri gider.
• Tasarımı atlayıp “ekranları geliştirici yapıversin” demek.
• Ucuz olsun diye kaynak kodu ve mağaza hesaplarını başkasında bırakmak.
• Bakıma hiç bütçe ayırmamak. Birkaç işletim sistemi güncellemesi sonra uygulama sessizce bozulur.
• Web sitesini bir kabuğa sarıp uygulama diye yayınlamaya çalışmak. Mağaza incelemesi buna genelde geçit vermez; verse bile kullanıcı fark eder.

Fikriniz şimdilik iki paragraflık bir nottan ibaretse bile başlamak için yeterli. Teklif formundan gönderin; neyin dahil, neyin hariç olduğunu kalem kalem gösteren bir teklifle dönelim.