Bu fiyat kalemini netleştiren unsurlar: ekran ve akışlar
Mobil uygulama fiyatını en hızlı etkileyen şey, ekranda gördüğünüz şey değildir; ekranda yapılacak işlerin sayısıdır. Örneğin tek bir “Üyelik” ekranı, giriş/çıkış akışının yanında e-posta doğrulama, şifre sıfırlama, hata mesajları, oturumun kalıcılığı ve kullanıcı durumunu yönetmeyi gerektirir. Aynı mantık “Profil”, “Sipariş/Rezervasyon”, “Yardım”, “Ödeme” ve “Ayarlar” için de geçerlidir. Ekran sayısını yazın; her ekranda veri okuma/yazma, dosya yükleme, liste/pagination, arama, filtreleme var mı kontrol edin. Fiyatı artıran tipik hata: sadece UI tasarlamak, fakat veri katmanı gereksinimlerini eksik varsaymaktır.
iOS ve Android farkı: aynı uygulama değil, iki hedef
iOS ve Android geliştirme çoğu zaman benzer görünür ama teknik maliyetleri aynı değildir. En belirleyici başlıklar: bildirim altyapısı, uygulama içi satın alma/abonelik kuralları, uygulama ikon/splash standartları, izinler (konum, kamera, dosya erişimi) ve farklı performans beklentileri. Backend tarafı ortak olabilir; fakat mobil istemcinin hata yönetimi, cihaz uyumluluğu ve sürüm bazlı davranışları test maliyetini artırır. Örneğin iOS’ta APNs ayarı ve sertifika yönetimi, Android’de FCM token yenileme davranışları farklı ele alınır. Fiyat planlarken “iki platform için tek iş” varsaymayın; istemci + test + mağaza yayın süreçlerini ayrı bütçeyle görün.
Backend neden bütçeyi belirler? Oturumdan veri güvenliğine
Mobil fiyatı sadece uygulama ekranları değildir; backend kapasitesi ve güvenlik tasarımı da belirler. Üyelik/oturum yönetimi için token üretimi, yenileme süreci ve oturum süreleri vardır. Kullanıcı verisi için şema tasarımı, rol yetkilendirme (ör. admin/normal kullanıcı), veri doğrulama ve audit log ihtiyacı doğar. En basit “liste getir” isteği bile cache, rate limit, sayfalama ve hata senaryosu ister. Ödeme söz konusu olduğunda ise webhook doğrulama, sipariş durum makinesi ve tekrar deneme mantığı gerekir. Tipik maliyet kaçağı: backend’i “basit CRUD” sanmak; oysa uygulama büyüdükçe tutarlılık ve güvenlik adımları maliyeti artırır.
Entegrasyonlar: harita, bildirim, ��deme ve üçüncü taraflar
Harita, bildirim ve ödeme entegrasyonları bütçeyi en çok zorlayan kalemlerdendir. Harita tarafında; konum izni, haritada işaretleme, geocoding/route ihtiyacı, veri doğruluğu ve cihaz performansı test gerektirir. Bildirimde; segmentasyon, token yaşam döngüsü ve kullanıcının uygulama durumuna göre davranışlar önemlidir (arka planda, uygulama kapalıyken, veri kısıtı varken). Ödemede; üyelik/tek sefer, iade senaryoları, webhook gecikmeleri ve hatalı ödeme akışları için durum yönetimi gerekir. Entegrasyon eklemeden önce “Hangi istekler backend üzerinden mi gidiyor, kim imza/secret yönetiyor?” sorusunu yazın. Sık hata: ana sistemden doğrudan bağlanıp gizli bilgileri istemciye gömmek.
Üyelik ve üyelik dışı kullanım: abonelik maliyeti dahil mi?
Üyelik sistemi fiyatı hem mobilde hem backend’de büyütür. Basit e-posta ile giriş mi var, yoksa sosyal giriş, cihaz bazlı oturum, çoklu kullanıcı rolü gibi adımlar var mı? Abonelik veya üyelik dışı kullanım varsa, lisans kontrolü nasıl yapılacak sorusu çıkar. Mobil istemci uygulamada kullanıcıya “satın alma var/yok” bilgisini gösterir; ancak asıl doğrulama backend veya mağaza webhook’larıyla desteklenmelidir. Ayrıca ücretsiz deneme, iptal, yenileme ve geri dönüş senaryoları planlanır. Bütçe için pratik kontrol: her abonelik durumu için UI/Backend davranışını maddeleyin. En sık kaçan: iptal/yenileme sonrası eski ekranların güncellenmemesi.
Test ve kalite: iOS/Android sürümleri kadar senaryo sayısı da önemlidir
Test bütçesini belirleyen şey sadece “test yapacağız” cümlesi değildir; hangi senaryoların kapsamda olduğu yazılmalıdır. En kritik senaryolar: oturum açma/çıkma, ağ kesintisi, yavaş bağlantı, ödeme tamamlandı/başarısız, webhook gecikmesi, bildirim tıklanınca doğru sayfaya gitme, izin reddedilmesi ve konum vermeme durumları. Ayrıca mağaza onayı için gereken ekran görüntüsü, açıklama metni ve gizlilik politikası gibi yayın öncesi kontroller test planına dahil edilmelidir. Fiyatı şişiren yaygın hata: test için geri dönüp tasarımda değişiklik yapmak. Doğru yaklaşım, test senaryolarını geliştirme sprintlerine yaymaktır.
Mağaza süreçleri: yayın, onay, sürümleme ve dokümantasyon
App Store ve Google Play yayın süreci bütçeyi dolaylı ama somut biçimde etkiler. Uygulama sürümleme (build number, sürüm notları), izin açıklamaları, veri toplama beyanları ve gizlilik dokümanı gereksinimleri değişkenlik gösterebilir. Abonelik/ödeme varsa mağazada doğru ürün tanımları, test abonelikleri ve üretime geçiş adımları gerekir. Ayrıca iOS’ta gizlilik izinleri ve arka plan davranışları mağaza incelemesinde yakalanabilir. Tipik hata: geliştirme bitti sanılıp yayın öncesi checklist atlanır; bu durumda yeniden çalışma çıkar. Yayın planını baştan netleştirin: kim hesapları, kim sertifikaları, kim sürüm notlarını hazırlar?
Neptün Medya yaklaşımı: fiyatı kestirme değil, kalem kalem doğrulama
Fiyatı doğru görmenin yolu, mobil uygulamayı parçalayarak her parçanın gerektirdiği işi yazmaktır. Önce ekran envanteri çıkarılır: liste/arama, detay, ödeme, profil, ayarlar, hata ekranları dahil edilir. Sonra veri işleri belirlenir: hangi endpoint’ler var, hangi kimlik doğrulama modeli kullanılıyor, rol kontrolü nasıl yapılacak. Ardından entegrasyon listesi netleşir: harita mı var, bildirim hangi mekanizma ile çalışacak, ödeme abonelik mi tek sefer mi? Son kısım test ve yayın hazırlığıdır: senaryo matrisi ve mağaza onay maddeleri planlanır. Neptün Medya, bu doğrulamayı sprint planına dönüştürerek gereksiz yeniden iş çıkarmayı azaltır. İstediğiniz “yaklaşık” değil, kontrol edilebilir bir bütçe görürsünüz.
Uygulama sonrası kontrol listesi
- Mobil görünüm, form ve WhatsApp yönlendirmeleri test edilir.
- Title, description, canonical ve sitemap kayıtları kontrol edilir.
- Kırık link, hatalı görsel ve boş CTA alanı bırakılmaz.
- İçerikler gerçek hizmet kapsamıyla uyumlu kalır.