Mobil uygulama geliştirme maliyetini belirleyen şey ekran sayısından çok, uygulamanın bu ekranların arkasında ne kadar iş yaptığıdır: kapsam, hedef platformlar, arka uç ve entegrasyonlar, cihaz özellikleri, güvenlik, test ve yayından sonraki bakım. Bu etkenler birlikte projenin süresini ve gereken ekibi, dolayısıyla bütçeyi şekillendirir.
Aynı görünen iki uygulamanın bütçesi arasında büyük fark olabilir. Biri yalnızca içerik gösterirken diğeri ödeme alır, çevrim dışı çalışır ve mevcut sistemlerinizle konuşur. Mobil uygulama geliştirme projelerinde tahmin yapmadan önce bu yüzden etkenleri tek tek konuşuyoruz. Bu yazıda fiyat vermiyoruz; bütçenin neden büyüyüp küçüldüğünü anlatıyoruz.
Maliyetin temel denklemi nedir?
Yazılım maliyeti büyük ölçüde emekten oluşur: bir işin gerektirdiği süre ile o işi yapacak ekibin birleşimi. Tasarımcı, mobil geliştirici, arka uç geliştiricisi, test uzmanı ve proje yönetimi bu ekibin tipik parçalarıdır. Ekibin deneyimi de denklemin parçasıdır: benzer bir sorunu daha önce çözmüş bir ekip aynı işi daha az denemeyle bitirir.
Dolayısıyla asıl soru "Kaç ekran var?" değil, "Her ekranın arkasında ne kadar iş var?" sorusudur. Bir giriş ekranı basit bir form olabilir. Tek kullanımlık şifre, biyometrik giriş, hesap silme ve oturum yönetimi eklendiğinde ise aynı ekranın arkasındaki iş katlanır. Aşağıdaki etkenler bu görünmeyen işin nereden geldiğini gösterir.
Kapsam ve kullanıcı akışları bütçeyi nasıl etkiler?
Kapsam, uygulamanın yaptığı işlerin toplamıdır. Bütçeyi en çok etkileyen kapsam unsurları şunlardır:
- Kullanıcı tipleri: tek bir kullanıcı tipi mi var, yoksa müşteri, kurye ve işletme gibi farklı rollerin her biri kendi ekranlarını mı istiyor?
- Akışların sayısı ve derinliği: kayıt, sipariş, ödeme, iade ya da mesajlaşma gibi her uçtan uca akış ayrı tasarım, geliştirme ve test ister.
- Kenar durumlar: bağlantı koptuğunda, ödeme yarıda kaldığında ya da kullanıcı bir izni reddettiğinde ne olacağı.
- Yönetim paneli: uygulamadaki içeriği, kullanıcıları ve talepleri kim, nereden yönetecek?
- Medya: fotoğraf ve video yükleme, kırpma, sıkıştırma ve depolama, basit bir metin alanına göre katlarca iş çıkarır.
- Dil sayısı: her dil çeviri, farklı metin uzunluklarına uyan tasarım ve ek test demektir.
Yönetim paneli en sık unutulan kalemdir. Uygulamanın arkasındaki operasyon ekranları da en az uygulamanın kendisi kadar bütçenin parçasıdır.
Platform ve teknoloji seçimi neyi değiştirir?
İlk büyük karar hedef platformdur: yalnızca iOS, yalnızca Android ya da ikisi birden. Native ve cross-platform yaklaşımlar arasındaki seçim de bütçeyi etkiler; bu karşılaştırmayı ayrı bir yazıda ele aldık. Platform kararının yanında şu sorular da iş yükünü belirler:
- Cihaz yelpazesi: Android'de üretici ve ekran çeşitliliği fazladır; test edilecek cihaz listesi uzadıkça test süresi de uzar.
- Tablet ve yatay ekran: telefona göre tasarlanmış ekranların tablette de iyi görünmesi ayrı bir tasarım işidir.
- Desteklenecek en eski sürüm: eski işletim sistemi sürümlerini desteklemek ek uyumluluk çalışması ve ek test demektir.
- Ek yüzeyler: ana ekran widget'ı, akıllı saat uygulaması ya da araç içi ekranlar ayrı birer geliştirme kalemidir.
- Erişilebilirlik: ekran okuyucu ve büyük yazı tipi desteği baştan planlandığında ucuzdur, sonradan eklendiğinde pahalıdır.
Arka uç, entegrasyonlar ve cihaz özellikleri ne kadar iş çıkarır?
Çoğu mobil uygulama, kullanıcının hiç görmediği bir sunucu tarafına, yani arka uca dayanır: veri tabanı, API, kimlik doğrulama, bildirim gönderimi ve dosya depolama burada çalışır. İyi belgelenmiş bir API zaten varsa iş azalır; yoksa arka uç projenin en büyük kalemlerinden biri olabilir.
Bütçeyi büyüten tipik teknik gereksinimler şunlardır:
- Ödeme: kartla ödeme, kayıtlı kart ve iade akışları; dijital içerik satılıyorsa mağaza içi satın alma kuralları.
- Mevcut sistemlerle entegrasyon: ERP, CRM, muhasebe ya da sektöre özel yazılımlarla veri alışverişi. Karşı tarafın API kalitesi süreyi doğrudan etkiler.
- Çevrim dışı çalışma: veriyi cihazda saklamak ve bağlantı geri geldiğinde çakışmaları çözerek eşitlemek, en çok emek isteyen özelliklerdendir.
- Anlık bildirimler: basit duyurudan kişiye özel, çok dilli ve zamanlanmış bildirimlere kadar geniş bir yelpaze vardır.
- Cihaz donanımı: kamera, konum, Bluetooth, NFC, biyometrik doğrulama ve arka planda çalışma; her biri kendi izinleri, pil etkisi ve platform kurallarıyla gelir.
- Analitik: kullanıcıların hangi adımda vazgeçtiğini görmek için olay takibi ve KVKK'ya uygun onay yönetimi.
- Gerçek zamanlı özellikler: canlı konum takibi, sohbet ya da anlık durum güncellemeleri sürekli bağlantı kuran bir altyapı ister.
React Native ile iOS ve Android için geliştirdiğimiz Kemerköy Sitesi sakin uygulamasında çevrim dışı da çalışan giriş QR kodu, daireye özel anlık bildirimler ve site yönetim sistemine bağlanan bir API köprüsü bir arada bulunuyor.
Tasarım, güvenlik ve test neden ayrı bütçe kalemleridir?
Bu üç alan, proje sıkıştığında ilk kısılan ve sonradan en pahalıya düzeltilen kalemlerdir.
- Tasarım: hazır bileşenlerle kurulmuş sade bir arayüz ile markaya özel animasyonlar, özel ikonlar ve karanlık tema içeren bir arayüz arasında büyük bir iş farkı vardır. Bir tasarım sistemi kurmak ilk yatırımı artırır, ama sonraki her ekranı hızlandırır.
- Güvenlik: güvenli oturum yönetimi, cihazda saklanan verinin korunması, API'nin yetkisiz erişime kapatılması ve KVKK ile GDPR uyumu. Sağlık ya da finans gibi hassas alanlarda bu kalem belirgin biçimde büyür.
- Test: farklı cihaz ve işletim sistemi sürümlerinde elle test, kritik akışlar için otomatik testler ve mağazaların test kanallarında gerçek kullanıcılarla deneme.
Mağazaların da kendi gereksinimleri vardır: gizlilik beyanları, ekran görüntüleri ve inceleme süreci. Bu adımları App Store ve Google Play yayın süreci yazımızda anlattık.
Yayından sonra hangi maliyetler devam eder?
Bir mobil uygulama yayınlandığında bitmez, asıl o zaman yaşamaya başlar. Bütçe planlarken şu sürekli kalemleri de hesaba katın:
- Mağaza hesapları: Apple yıllık geliştirici üyeliği, Google Play ise tek seferlik kayıt ücreti ister. Dijital içerik ve abonelik satışlarında mağazalar ayrıca komisyon alır.
- Sunucu ve servisler: barındırma, veri tabanı, bildirim, harita, SMS ve e-posta gibi, kullanım arttıkça büyüyebilen hizmetler.
- İşletim sistemi güncellemeleri: Apple ve Google her yıl yeni sürüm çıkarır ve mağazalar, uygulamaların güncel geliştirme araçlarıyla derlenmesini ve yeni sürümleri hedeflemesini belirli takvimlerle zorunlu tutar. Uygulamayı güncel tutmak isteğe bağlı değildir.
- Hata düzeltme ve izleme: çökme raporları, performans takibi ve kullanıcı geri bildirimine göre iyileştirme.
- Yeni özellikler: kullanım verisi geldikçe yol haritası değişir; bunun için düzenli bir geliştirme kapasitesi ayırmak gerekir.
Bu kalemlerin bir kısmı kullanıcı sayısıyla birlikte büyür. Bu yüzden yalnızca ilk yılın değil, büyüme senaryonuzun da bütçesini düşünün.
Bakım ve sürüm planlamasını yayından sonra mobil uygulama yazımızda ayrıntılı olarak ele aldık.
Bütçeyi kontrol altında tutmak için ne yapabilirsiniz?
Bütçeyi en çok sapmalar büyütür. Şu beş alışkanlık sapmaları baştan sınırlar:
- Akışları yazıya dökün: ekran listesi yerine kullanıcının yapacağı işleri adım adım tarif edin.
- Öncelik verin: her özelliği "olmazsa olmaz", "olsa iyi olur" ya da "sonra" diye etiketleyin.
- Mevcut sistemleri erken paylaşın: entegre edilecek API'lerin belgelerini ve test ortamlarını projenin başında sağlayın.
- Kararları hızlı verin: bekleyen tasarım ve içerik kararları takvimi, takvim de bütçeyi uzatır.
- Değişiklikleri yönetin: proje ortasında gelen her yeni isteği kapsamı, süresi ve etkisiyle birlikte değerlendirin.
Bir mobil uygulamanın maliyeti ekranlarında değil, o ekranların arkasında yaptığı işte saklıdır.
Sık sorulan sorular
Mobil uygulama için neden baştan tek bir fiyat verilemez?
Çünkü aynı fikir, kapsama ve entegrasyonlara göre çok farklı iş yüklerine dönüşebilir. Kısa bir keşif görüşmesiyle akışları, platformları ve entegrasyonları netleştirdikten sonra kapsamı tanımlanmış bir tahmin paylaşıyoruz.
Arka uç ve yönetim paneli mobil uygulama bütçesine dahil mi?
Uygulamanın ihtiyacına göre değişir. Mevcut bir sistem ve API varsa uygulama yalnızca bunlara bağlanır; yoksa arka uç ve yönetim paneli de projenin parçası olur ve bütçede ayrı kalemler olarak görünmelidir.
Hazır bir şablonla başlamak maliyeti düşürür mü?
Standart ihtiyaçlarda başlangıcı hızlandırabilir. Ancak akışlarınız, entegrasyonlarınız ve markanız şablonun varsayımlarından uzaklaştıkça uyarlama işi büyür ve kazanç azalır.
Uygulamayı önce tek platformda çıkarmak tasarruf sağlar mı?
Başlangıç bütçesini düşürür ve öğrenmeyi hızlandırabilir, ancak bu karar kullanıcılarınızın hangi platformda olduğuna dair veriye dayanmalıdır. İkinci platform sonradan eklendiğinde arka uç ve tasarımın büyük kısmı yeniden kullanılabilir.
Bakım bütçesi neye göre planlanır?
Entegrasyon sayısına, uygulamanın ne kadar yoğun kullanıldığına, işletim sistemi ve mağaza kurallarındaki değişikliklerin hızına ve yol haritanızdaki özelliklere göre. Çok entegrasyonlu ve aktif gelişen bir uygulama, sade bir içerik uygulamasından daha fazla sürekli kapasite ister.
Nereden başlamalı?
Uygulamanızın kullanıcılarını, en önemli üç akışını ve bağlanması gereken sistemleri birer paragrafla yazın. Bu kısa belge, gerçekçi bir tahminin ve sağlıklı bir projenin başlangıç noktasıdır.
Mobil uygulama fikrinizi bu etkenler üzerinden birlikte değerlendirmek isterseniz bizimle iletişime geçin.