Mobil uygulamanın maliyetini yalnızca ekran sayısı belirlemez. “Kayıt ekranı” olarak görünen tek bir bölüm; mikrofon izni, bağlantı kesilmesi, taslak kurtarma ve yeniden deneme davranışları içerebilir. Sağlıklı teklif, ekranları olduğu kadar bu durumları da tanımlar.
Önce tek bir ana kullanıcı akışı belirleyin
Kullanıcı neyle başlayacak ve hangi sonuçla çıkacak? Bir günlük uygulamasında kayıt oluşturmak, kaydetmek ve yeniden açmak temel akış olabilir. Sosyal paylaşım, gelişmiş rapor ve web paneli ayrı kapsam başlıklarıdır.
Nurena’da sesli veya yazılı kayıttan analize geçişin yanında, yarım kalan metne geri dönme davranışı da ele alındı. Teklif isterken “bağlantı giderse ne olur?” sorusunu bu nedenle sorun.
Bütçeyi değiştiren başlıklar
- Platform: iOS, Android veya ikisi; hedef cihaz ve işletim sistemi aralığı.
- Kimlik ve veri: hesap, rol, senkronizasyon, çevrimdışı kayıt ve veri aktarımı.
- Ödeme: abonelik, satın almayı geri yükleme ve erişim durumları.
- Entegrasyon: mevcut API, AI işlevleri, bildirim ve yönetim paneli.
- Yayın: cihaz kontrolleri, mağaza görselleri, açıklamalar ve inceleme düzeltmeleri.
Bunların her biri teklif satırına veya kabul kriterine dönüşmeli. Belirsiz bir “tüm özellikler dahil” ifadesi karşılaştırma için yeterli değildir.
Native mi, ortak kod tabanı mı?
Platforma çok özel donanım veya arayüz gereksinimleri native geliştirmeyi gündeme getirebilir. Paylaşılabilir ürün akışları için React Native gibi bir yaklaşım değerlendirilebilir. Ortak kod kullanmak, platform testlerini ortadan kaldırmaz.
Nurena React Native/Expo kullanıyor. Bu, her projenin aynı seçimi yapması gerektiği anlamına gelmez. Mevcut ekibin bilgisi, cihaz gereksinimleri ve bakım planı birlikte değerlendirilir. Teknik başlangıç için React Native dokümantasyonuna bakabilirsiniz.
İlk geliştirme ve işletim giderlerini ayırın
Tasarım ve geliştirme teklifinden ayrı olarak mağaza hesapları, sunucu, AI kullanımı, e-posta ve bakım giderlerini listeleyin. Kullanıma bağlı servislerde aylık tek bir sabit rakam varsaymak yerine kullanıcı sayısı ve kullanım sıklığına göre senaryo hazırlayın.
“Ne kadar sürer?” sorusu da aynı kapsama bağlıdır. Teklifin hangi teslimlere bölündüğünü, müşteri geri bildiriminin nerede beklendiğini ve mağaza incelemesinin takvime nasıl dahil edildiğini sorun.
Teklif karşılaştırma kontrolü
Kaynak kodun teslimi, test cihazları, hata kapsamı, yayın sorumluluğu, bakım koşulları ve kapsam değişikliği yöntemi yazılı olsun. Aynı özellik listesini kullanarak teklif alın; eksik bir akışın sonradan eklenmesi ilk fiyatı yanıltıcı kılabilir.
İlk MVP kapsamını seçme rehberi önceliklendirmeye yardımcı olur. Mobil geliştirme hizmetimizi inceleyip projenizi paylaşabilirsiniz.
Takvim ve yayın sonrasını birlikte planlayın
Teklifin hangi teslimatları kapsadığını mobil uygulama geliştirme takvimi üzerinden inceleyin. Yayın sonrasında devam eden sorumluluklar için uygulama bakım kontrol listesini kullanın.