Platform kararının maliyete gerçek etkisi
Fiyatı sessizce büyüten özellikler
İlk sürümü küçük tutmanın doğru yolu
Önce platform kararı: tek kod tabanı mı, iki ayrı uygulama mı
Aynı uygulama, native ve çapraz platform seçeneklerinde iki farklı iş yükü doğurur.
Çapraz platform geliştirmede iOS ve Android tek kod tabanından üretilir; tasarım, test ve bakım tek yerde toplandığı için toplam maliyet düşer. Native geliştirmede her platform ayrı yazılır: iki kod tabanı, iki test döngüsü, iki bakım hattı demektir.
Native seçimi her zaman gereksiz değildir. Yoğun kamera işleme, arka planda sürekli konum takibi, giyilebilir cihaz entegrasyonu veya platforma özel gelişmiş arayüz beklentisi varsa native gerekçelendirilebilir. Bu gerekçe yoksa çapraz platform, aynı sonucu belirgin biçimde daha düşük bütçeyle verir.
Teklif karşılaştırırken hangi yaklaşımın seçildiğini ve nedenini sorun. İki teklif arasındaki büyük farkın kaynağı çoğu zaman kalite değil, bu karardır.
- Native mi çapraz platform mu
- Gerekçesi yazılı mı
- Hedef iOS ve Android sürümleri
- Tablet desteği kapsamda mı
Ekran sayısı değil, özelliğin cihaza ne kadar dokunduğu
Yirmi basit ekran, cihaz donanımı kullanan üç ekrandan daha ucuza gelebilir.
İçerik listeleyen, form gösteren ve detay açan ekranlar öngörülebilir iş yüküdür. Maliyeti büyüten kalemler farklıdır: uygulama içi ödeme ve mağaza komisyon kuralları, harita ve rota, anlık bildirim altyapısı, çevrimdışı çalışma ve veri senkronizasyonu, kamera ile belge veya barkod okuma, arka planda konum takibi.
Bu özelliklerin her biri yalnızca geliştirme değil; test, izin yönetimi, hata durumu tasarımı ve mağaza inceleme riski de getirir. Örneğin arka plan konumu, App Store incelemesinde ayrı gerekçe ister ve reddedilme ihtimalini artırır.
Teklifte özellikleri tek tek listeletin. “Kullanıcı girişi var” ifadesi; e-posta, telefon doğrulama, sosyal hesapla giriş ve kurumsal kimlik doğrulama arasında dört farklı iş yükünü gizleyebilir.
- Ödeme ve abonelik var mı
- Bildirim ve konum kapsamda mı
- Çevrimdışı çalışma gerekli mi
- Giriş yöntemleri tek tek yazılı mı
Arka uç ve yönetim paneli çoğu teklifte görünmeyen kalemdir
Mobil uygulama tek başına bir ürün değildir; verinin yaşadığı yer de projeye dahildir.
Uygulamanın gösterdiği içerik bir yerden gelir ve bir yerde yönetilir. Mevcut bir sistem varsa entegrasyon maliyeti; yoksa veritabanı, API ve yönetim panelinin sıfırdan kurulması gerekir. Bu, çoğu projede mobil tarafla karşılaştırılabilir büyüklükte bir kalemdir.
Mevcut ERP, CRM veya e-ticaret altyapısına bağlanılacaksa o sistemin API'sinin var olup olmadığı, dokümante edilip edilmediği ve test ortamı sunup sunmadığı süreyi doğrudan etkiler. API yoksa önce onun yazılması gerekir.
Ayrıca sunucu, veritabanı, bildirim servisi ve dosya depolama gibi kalemlerin aylık işletim maliyeti vardır. Teklifte bunların kime ait olduğu ve tahmini tutarı yazılı olmalıdır.
- Arka uç sıfırdan mı kurulacak
- Entegre edilecek sistemin API'si var mı
- Yönetim paneli kapsamda mı
- Aylık işletim maliyeti kimde
Yayın günü bitiş değil; mağaza ve bakım sorumluluğunu yazılı hâle getirin
Uygulama, yayınlandıktan sonra da düzenli bakım gerektiren tek dijital üründür.
App Store ve Google Play geliştirici hesapları ücretlidir ve işletme adına açılmalıdır. Yayın süreci ikon, ekran görüntüsü, gizlilik formu, veri kullanım beyanı ve inceleme yanıtlarını içerir. İlk gönderimin reddedilmesi olağandır; teklif buna zaman ayırmış olmalıdır.
Apple ve Google her yıl işletim sistemi sürümü çıkarır ve zaman zaman geliştirici kurallarını değiştirir. Güncellenmeyen uygulama önce hata vermeye, sonra mağazadan kaldırılmaya kadar gider. Yıllık bakım, isteğe bağlı bir kalem değil, ürünün yaşamaya devam etmesinin koşuludur.
Sözleşmede kaynak kodun, mağaza hesaplarının ve imza sertifikalarının kime ait olacağı açık olmalıdır. Bunlar geliştiricide kalırsa uygulamanın sahipliği pratikte size ait olmaz.
- Mağaza hesapları işletme adına mı
- Yıllık bakım kapsamı ve bedeli
- Kaynak kod ve sertifika devri
- Kritik hata müdahale süresi
Bütçeyi kontrol etmenin yolu kaliteyi değil, ilk sürümün kapsamını küçültmektir
En pahalı uygulama, kimsenin kullanmadığı özellikler için ödenen uygulamadır.
İlk sürüm tek bir işi çok iyi yapmalıdır: rezervasyon almak, saha ekibine iş emri iletmek, sadakat puanı biriktirmek gibi. Bu işi tamamlayan en kısa akış belirlenir, geri kalan istekler sonraki fazlara yazılır.
Yayına çıktıktan sonra hangi ekranın kullanıldığı, kullanıcının nerede vazgeçtiği ve hangi özelliğin hiç açılmadığı ölçülür. Sonraki faz bu veriye göre planlanır; tahmine göre değil.
Bu yaklaşım toplam bütçeyi de düşürür: kullanılmayacak özellik hiç yazılmaz, yazılan özellik ise gerçek kullanımla doğrulanmış olur.
- İlk sürümün tek işi ne
- Sonraki fazların yazılı sınırı
- Ölçülecek kullanım sinyalleri
- Faz bazlı ödeme planı