Mobil uygulama geliştirme maliyeti için tek bir rakam vermek mümkün değil; çünkü aynı isimle anılan iki uygulama aynı işi yapmıyor. Fiyatı belirleyen şey uygulama fikri değil, o fikrin içine koyduğunuz kararlardır: kaç platform, kaç özellik, ne kadar özgün tasarım, ne kadar arka plan altyapısı. Bu yazıda bütçeyi hangi kalemlerin büyüttüğünü ve nerede kısmanın gerçekten işe yaradığını anlatıyoruz.
Kaç platform için geliştirme yapılacak?
Maliyet konuşması burada başlar. Sadece iOS, sadece Android ya da ikisi birden; bu tercih projenin hem süresini hem de bakım yükünü doğrudan belirler. Native geliştirmede iOS için Swift, Android için Kotlin ile iki ayrı kod tabanı yazılır. Bu da iki ayrı geliştirme, iki ayrı test ve yayına aldıktan sonra iki ayrı bakım süreci anlamına gelir.
React Native ve Flutter gibi çapraz platform teknolojileri tek kod tabanıyla iki mağazaya çıkmanızı sağlar; katalog, rezervasyon, üyelik ya da saha ekibi uygulamalarının çoğunda maliyeti belirgin biçimde düşürür. Buna karşılık yoğun kamera işleme, arka planda kesintisiz konum takibi, karmaşık animasyon veya cihaza özel donanım kullanımı varsa native tarafa geçmek gerekebilir. Karar kriteriniz şu olsun: uygulamanız cihazın derin özelliklerine ne kadar bağlı? Bağımlılık arttıkça native geliştirmenin ek maliyeti haklı çıkar, azaldıkça tek kod tabanı en makul seçenek olur.
Hedef kitlenizin cihaz dağılımına da bakın. Kullanıcılarınızın büyük çoğunluğu tek bir platformdaysa ilk sürümü orada yayınlamak, bütçenin yarısını ikinci platforma ayırmadan önce ürünü doğrulama imkânı verir.
Özellik kapsamı maliyeti nasıl büyütür?
Bütçeyi en çok büyüten kalem özellik listesidir. Her özellik ekranda bir düğmeden ibaret görünür; arkasında ise iş mantığı, hata durumları, yetkilendirme kuralları ve test yükü vardır. Basit bir tanıtım veya katalog uygulaması ile kullanıcı hesabı, ödeme, mesajlaşma ve bildirim içeren bir uygulama arasındaki fark ekran sayısıyla ölçülmez.
Şu başlıkların her biri projeyi ayrı bir seviyeye taşır: üyelik ve giriş yönetimi, ödeme altyapısı, canlı içerik yönetim paneli, harita ve konum, sohbet, anlık bildirim, çevrimdışı çalışma, çoklu dil desteği. Ödeme eklendiği anda güvenlik, iade akışı, fatura ve muhasebe entegrasyonu da konuşulmaya başlar; yani tek satırlık bir özellik birden fazla iş kalemi doğurur.
Teklif almadan önce özellik listesini ikiye ayırın: ilk sürümde olmazsa uygulama anlamsız kalacak olanlar ve sonra eklenebilecek olanlar. Bu ayrım yapılmadan alınan teklifler karşılaştırılamaz, çünkü her ekip farklı bir uygulamayı fiyatlamış olur.
Tasarım ve backend bütçede ne kadar yer tutar?
Tasarımda kabaca üç seviye vardır. Hazır bileşen kitleriyle ilerlemek en hızlısıdır ve şirket içi kullanılan uygulamalarda çoğu zaman yeterlidir. İkinci seviye, standart bileşenlerin marka kimliğinize uyarlanmasıdır. Üçüncü seviye ise özgün bir arayüz dili, kendine ait ikon seti ve hareket kurgusu üretmektir; uygulamanın karakterini bu belirler ama tasarım ve geliştirme süresini birlikte uzatır. Tüketiciye satış yapan bir üründe özgünlük doğrudan dönüşümü etkilediği için bu yatırım genelde geri döner; şirket içi bir süreç uygulamasında ise gereksiz olabilir.
Backend, tekliflerde en sık gözden kaçan kısımdır. Uygulama çoğu zaman yalnızca bir arayüzdür; verinin nerede durduğu, kimin yönettiği ve kaç kullanıcıyı kaldırdığı sorularının cevabı sunucu tarafındadır. Halihazırda çalışan bir sisteminiz varsa iş, API entegrasyonuyla sınırlı kalabilir. Sıfırdan veritabanı, kullanıcı yönetimi, yetkilendirme ve içerik yönetim paneli kurulacaksa bu, projenin içindeki ikinci bir yazılım projesidir ve bütçede ayrı bir satır olarak görünmelidir.
Hangi maliyetler bütçe çıkarılırken unutulur?
Geliştirme bedeli toplam maliyetin tamamı değildir. Apple Developer Program yıllık, Google Play Console ise tek seferlik ücretlidir. Kurumsal hesaplarda şirket doğrulaması istenir; bu süreç bütçeden çok takvimde yer kaplar ve yayın tarihini geciktirebilir. Sertifika ve imzalama dosyalarının yönetimi de ekip değişikliklerinde sorun çıkaran, çoğu zaman hiç planlanmayan bir iştir.
Üzerine düzenli giderler eklenir: sunucu ve veritabanı barındırma, alan adı, e-posta ve bildirim servisleri, harita kullanımı, ödeme sağlayıcısının işlem komisyonu, hata takip ve analitik araçları. Bunlar tek seferlik değil aylık tekrar eden kalemlerdir; yani uygulamanın bir işletme gideri vardır ve bu gider kullanıcı sayısıyla birlikte artar.
Son olarak bakım gelir. iOS ve Android her yıl yeni sürüm çıkarır, mağaza politikaları değişir, kullanılan kütüphaneler eskir. Hiçbir yeni özellik eklemeseniz bile uygulamanın çalışır kalması için yıllık bir uyum çalışması gerekir. Bakımı bütçelemeyen projeler genelde ikinci yılda uygulamanın güncelleme alamaz hâle gelmesi ya da mağazadan kaldırılması riskiyle karşılaşır.
MVP ile başlamak bütçeyi neden korur?
MVP, uygulamanın ucuzlatılmış hâli değildir. Ana faydayı eksiksiz veren en küçük sürümdür; kısaltılan şey kalite değil kapsamdır. Amaç, gerçek kullanım verisi olmadan yapılan varsayımlara para harcamamaktır. Ekiplerin en pahalı hatası, kimsenin kullanmayacağı özellikleri baştan yaptırmaktır.
İşleyen yöntem şudur: tek bir ana kullanıcı yolculuğu seçin, onu kusursuz çalıştırın, yayına alın ve sıradaki özelliği tahminle değil kullanım verisiyle belirleyin. Böylece bütçe tek seferde değil, kanıta dayalı olarak parça parça harcanır. Yayına alma süresi de kısalır; erken yayınlanan bir uygulama, geliştirme devam ederken geri bildirim toplamaya başlar.
Bu yaklaşım fiyat pazarlığından çok daha etkilidir. Aynı bütçeyle daha az özellik yaptırmak, aynı özellikleri daha ucuza yaptırmaya çalışmaktan neredeyse her zaman daha iyi sonuç verir.
Bütçeyi düşürmenin doğru yolları nelerdir?
Maliyeti düşürmenin sağlıklı yolu kapsamı sadeleştirmektir, kaliteyi düşürmek değil. Test edilmemiş, dokümante edilmemiş ve aceleye getirilmiş bir kod tabanı ilk yıl ucuz görünür; ikinci yıl her küçük değişiklik pahalı hâle gelir. Teknik borç faiziyle geri döner ve bu faizi genellikle ilk ekip değil, sonraki ekip öder.
Bütçeyi korurken gerçekten işe yarayan başlıklar şunlardır. Kapsamı fazlara bölün ve her fazın sonunda yayına çıkın. Ödeme, kimlik doğrulama, bildirim ve harita gibi çözülmüş problemleri sıfırdan yazmak yerine hazır servislerle entegre edin. Uygun bir projeyse tek kod tabanıyla iki platforma çıkın. Tasarımı geliştirme başlamadan önce netleştirin; kod yazıldıktan sonra gelen tasarım değişiklikleri en pahalı revizyon türüdür.
En az bunlar kadar önemli bir konu daha var: karar süreci. Projelerde harcanan sürenin önemli bir kısmı kod yazmaya değil, onay beklemeye gider. İçerik kimden gelecek, kararı kim verecek, geri bildirim kaç günde toplanacak; bunlar baştan belirlenmezse takvim uzar ve uzayan her takvim maliyettir.
Teklif alırken tek bir rakam yerine kalem kalem dökülmüş bir kapsam isteyin. Neyin dahil olduğu, kaç revizyon hakkı bulunduğu, backend ve yayın sonrası bakımın nasıl işlediği yazılı değilse elinizdeki şey bir fiyat değil, bir tahmindir. Aynı kapsamı gören iki teklif karşılaştırılabilir; farklı kapsamları gören iki rakam karşılaştırılamaz.
