Mobil uygulama geliştirme süresi ve maliyeti neye bağlı

"Bir uygulama yaptırmak kaç paraya çıkar" sorusuna dürüst cevap şudur: bağlı olduğu değişkenler netleşmeden hiçbir rakam gerçek değildir. Aynı soruyu "bir bina yapmak kaç paraya çıkar" diye sormak gibi — 3 katlı bir ofis ile 30 katlı bir rezidansın maliyeti aynı kalemle konuşulmaz. Uygulama geliştirmede de fiyatı belirleyen birkaç somut değişken var, ve teklif almadan önce bunları bilmek pazarlık gücü kazandırır.

Birinci değişken ekran sayısı ve karmaşıklığı. Basit bir randevu/katalog uygulaması (5-8 ekran, sabit içerik, kullanıcı girişi opsiyonel) ile gerçek zamanlı mesajlaşma, ödeme entegrasyonu, harita/konum takibi içeren bir uygulama arasında işçilik farkı kat kat büyür. Ekran sayısını ve her ekranın neyi yapması gerektiğini netleştirmeden alınan bir teklif, sonradan revize edilmeye mahkumdur.

İkinci değişken native mi cross-platform mü seçildiği. Native geliştirme, iOS için Swift, Android için Kotlin ile iki ayrı kod tabanı demektir — daha yüksek performans, platforma özgü daha ince deneyim sunar ama iki kat işçilik gerektirir. Cross-platform (React Native, Flutter gibi) tek kod tabanından iki platforma çıkar, bütçe ve süre açısından çoğu küçük-orta ölçekli işletme için daha gerçekçi bir başlangıç noktasıdır. Uygulamanın kamera, sensör, arka planda konum takibi gibi donanıma çok yakın çalışan özellikleri yoksa cross-platform'un performans dezavantajı kullanıcı için genelde fark edilmez düzeydedir.

Üçüncü değişken backend/API ihtiyacı. Uygulama sadece statik içerik gösteriyorsa (menü, katalog, iletişim bilgisi) sunucu tarafı iş azdır. Ama kullanıcı hesabı, sipariş takibi, gerçek zamanlı bildirim, ödeme gibi bir sunucuyla sürekli konuşan özellikler varsa, görünmeyen ama zaman alan bir backend geliştirme süreci de devreye girer — bu, ekran sayısından bağımsız, çoğu zaman gözden kaçan bir maliyet kalemidir.

Dördüncü değişken yayın süreci. Uygulama hazır olduğunda iş bitmiyor — App Store ve Play Store'un kendi inceleme süreçleri var, Apple'ın incelemesi günler sürebilir ve ilk denemede reddedilme (gizlilik metni eksikliği, test hesabı verilmemesi gibi teknik gerekçelerle) sık görülen bir durumdur. Bu süreç plana dahil edilmezse "uygulama bitti ama hâlâ yayında değil" boşluğu müşteri için sürpriz olur.

Son değişken, en sık atlanan: yayın sonrası bakım. iOS ve Android yılda birkaç kez sürüm güncellemesi yapıyor, mağaza kuralları değişiyor, kullanıcıdan gelen hata bildirimleri düzeltme gerektiriyor. Bir uygulamanın 'bir kere yapılıp bitecek' bir proje değil, düzenli bakım isteyen canlı bir ürün olduğunu baştan konuşmak, hem beklenti yönetimi hem bütçe planlaması için gerekli.

Bu beş değişken netleşmeden alınan herhangi bir 'X liraya yaparız' teklifi ya çok iyimserdir ya da tersine, gereğinden yüksektir. Doğru sıra: önce hangi ekranlar, hangi özellikler, ne kadar backend ihtiyacı olduğu netleşir, sonra rakam ve süre buna göre şekillenir.