Mobil Uygulama Fiyatları 2026: Bütçeyi Ne Belirler?

Fiyat sorusunun altında ne var

"Mobil uygulama kaç para?" sorusunun tek bir doğru cevabı yok; çünkü bu soru "araba kaç para" sorusuyla aynı yapıdadır. Anlamlı cevap, uygulamanın ne iş yaptığına bağlıdır.

Uygulamayı üç katmana ayırdığınızda tablo netleşir: ekranlar, arka uç ve süreç. Tekliflerin çoğu yalnız ilk katmanı fiyatlar, fark buradan doğar.

Ekranlar maliyetin küçük kısmıdır

Yirmi ekranlık bir uygulama, on ekranlık bir uygulamanın iki katı sürmez. Tasarım sistemi bir kez kurulduktan sonra yeni ekran eklemek ucuzlar.

Asıl fark, ekranın arkasında ne olduğudur. Statik bir "Hakkımızda" ekranı ile canlı stok gösteren bir liste ekranı aynı kalemde değerlendirilemez.

Kendi ürünlerimizde bunu net ölçtük: Zindora'da 113 ekran vardı ama maliyetin ağırlığı ekran sayısında değil, üyelik, randevu ve ödeme akışlarındaydı.

Arka uç, veri ve entegrasyonlar

Uygulama verilerini bir yerden alır. O yer bir API'dir ve genellikle sıfırdan yazılır. Kullanıcı hesabı, bildirim, arama, raporlama gibi her yetenek arka uçta ayrı iş demektir.

Üçüncü taraf entegrasyonlar bütçenin en sinsi kalemidir. Ödeme sağlayıcı, kargo, muhasebe ya da pazaryeri API'si eklemek, dokümantasyonun vaat ettiğinden daha uzun sürer.

NetKâr'da Trendyol API'sinden gelen sipariş ve komisyon verisini panel rakamlarıyla kuruşu kuruşuna eşleştirmek, ekranları yazmaktan daha uzun sürdü. Doğrulama işin kendisidir.

Mağaza süreci bir kalemdir

Uygulama bittiğinde iş bitmez. App Store ve Google Play incelemeleri ayrı bir uzmanlık ister ve ilk gönderimde ret almak olağandır.

Apple tarafında en sık karşılaştığımız ret sebepleri; işlevsiz görünen düğmeler, eksik hesap silme akışı ve başka sosyal girişler varken Apple ile Giriş'in bulunmamasıdır.

Google tarafında yeni bireysel geliştirici hesapları için kapalı test zorunluluğu vardır: belirli sayıda test kullanıcısıyla kesintisiz bir test dönemi tamamlanmadan üretime çıkamazsınız. Bu süre takvime baştan yazılmalıdır.

Bakım, ilk yılın gizli kalemi

Mobil uygulama canlı bir üründür. Her yıl yeni iOS ve Android sürümleri çıkar, kütüphaneler eskir, mağaza kuralları değişir.

Bakımı olmayan bir uygulama iki yıl içinde derlenemez hale gelir. Bu noktada yapılan iş güncelleme değil, yeniden yazımdır ve ilk maliyetin yarısına yaklaşır.

Sağlıklı yaklaşım, ilk yıl için yıllık bakım bütçesini baştan ayırmaktır.

Teklif karşılaştırırken sorulacaklar

Kaynak kodun mülkiyeti kimde? Mağaza hesapları kimin adına açılacak? İmzalama anahtarları teslim edilecek mi?

Arka uç dahil mi, yoksa "sizin API'niz hazır" varsayımıyla mı fiyatlandırıldı? Test kullanıcıları ve mağaza inceleme süreci kimin sorumluluğunda?

Bu dört soruya net yazılı cevap veren teklif, rakamı düşük olan tekliften daha ucuzdur.

Ödeme planı ve aşamalandırma

Tek kalemde ödeme yerine aşamalara bağlı ödeme her iki tarafı da korur. Tasarım onayı, ilk çalışan sürüm, mağaza gönderimi ve kabul; dört doğal kilometre taşıdır.

Her aşamanın neyi içerdiği yazılı olmalıdır. "Tasarım bitti" ifadesi, kaç ekranın hangi durumda teslim edildiği yazılmadan ölçülemez.

Kapsam dışı taleplerin nasıl fiyatlanacağı baştan belirlenirse, proje ortasında pazarlık yapmak zorunda kalmazsınız.

Bütçeyi küçültmenin doğru yolu

Kapsamı daraltın, kaliteyi değil. On özelliği yarım yapmak yerine üç özelliği tam yapmak her zaman daha ucuza gelir.

İlk sürümde yönetim paneli yerine basit bir veri giriş ekranı yeterli olabilir. Panel, kullanıcı sayısı arttığında eklenir.

Tasarımı sıfırdan yaptırmak yerine mevcut bir tasarım sistemi üzerine markanızı uygulamak, görsel kalitede belirgin kayıp olmadan süreyi kısaltır.

Kaçınılması gereken kısma ise testtir. Test edilmemiş uygulama, mağaza reddi ve kullanıcı şikayeti olarak geri döner.