Mobil Uygulama Yaptırmanın Gerçek Maliyeti ve Süreci

"Mobil uygulama ne kadar tutar" sorusunun cevabı her zaman "kapsama bağlı" ile başlıyor ve bu can sıkıcı bir cevap. Aşağıda kapsamı neyin belirlediğini ve süreçte nelerin sizi beklediğini yazdık.

Rakam vermiyoruz çünkü uydurma bir aralık yazmak size fayda sağlamaz. Bunun yerine bir teklif aldığınızda neye baktığınızı bileceksiniz.

Tek kod tabanı mı, iki ayrı uygulama mı

İki yol var. Her platform için ayrı ayrı yazmak ya da tek koddan iki platforma çıkmak.

Ayrı yazmak en yüksek performansı ve platforma özgü her özelliğe erişimi veriyor. Karşılığında iki ayrı geliştirme, iki ayrı test ve iki ayrı bakım demek.

Tek kod tabanı çoğu uygulama için yeterli ve maliyeti belirgin şekilde düşürüyor. Aynı işi iki kez yaptırmıyorsunuz.

Ayrı yazmak şu durumlarda mantıklı. Yoğun grafik işleyen oyunlar, donanıma çok yakın çalışan uygulamalar ve platforma özgü çok sayıda özel özellik gerektiren işler.

Bunların dışındaki çoğu iş uygulaması için tek kod tabanı doğru karar.

Bütçeyi belirleyen kalemler

• Ekran sayısı. Her ekran tasarım, geliştirme ve test demek.
• Backend var mı. Uygulama bir sunucuyla konuşacaksa o sunucu da yazılacak.
• Kullanıcı hesabı. Kayıt, giriş, şifre sıfırlama, hesap silme. Küçük görünür, değildir.
• Entegrasyonlar. Ödeme, harita, kamera, bildirim, sosyal giriş.
• Çevrimdışı çalışma. İnternetsiz de çalışması gerekiyorsa maliyeti belirgin artırıyor.
• Tasarım. Hazır bileşenlerle mi, özel tasarımla mı.
• Yönetim paneli. İçeriği ve kullanıcıları kim yönetecek.

Üçüncü madde en çok küçümsenen. Hesap sistemi düzgün kurulmak zorunda çünkü güvenlik ve gizlilik doğrudan ona bağlı.

Görünmeyen maliyetler

Geliştirme dışında da kalemler var ve bunlar tekliflerde çoğu zaman görünmüyor.

Apple ve Google geliştirici hesapları ücretli ve yıllık. Apple tarafında şirket hesabı açmak için ek belge süreçleri var.

Sertifikalar ve imzalama anahtarları yönetilmesi gereken şeyler. Kaybedilirse ya da yanlışlıkla iptal edilirse uygulama güncellemesi yayınlanamıyor.

Test dağıtımı için bir altyapı gerekiyor. Uygulamayı yayınlamadan önce test kullanıcılarına ulaştırmanın yolu var ve kurulması gerekiyor.

Sunucu maliyeti de süreklilik arz ediyor. Uygulama bir backend'e bağlıysa o backend her ay çalışmaya devam ediyor.

Apple tarafında şirket hesabı

Şirket adına uygulama yayınlayacaksanız Apple bir kurumsal kimlik doğrulaması istiyor. Bunun için firmanızın uluslararası bir işletme numarasına sahip olması gerekiyor.

Bu numara yoksa başvurulup alınıyor ve süreç birkaç hafta sürebiliyor. Projeye başlarken bu süreci paralel yürütmezseniz uygulama hazır olur ama yayınlanamaz.

Biz bu süreci kendi şirketimiz için de yaşadık. Uygulamayı bitirip mağaza tarafında beklemek moral bozucu, o yüzden hesap işlemlerini ilk haftada başlatıyoruz.

Mağaza inceleme süreci

Uygulama yüklendikten sonra mağaza tarafından inceleniyor. Süre değişken, birkaç saatten birkaç güne kadar sürebiliyor.

Reddedilme yaygın ve normal. İlk yayında bir kez reddedilmeyi hesaba katın.

Sık reddedilme sebepleri şunlar. Gizlilik politikası eksik ya da ulaşılamıyor. Hesap silme seçeneği yok. İzin isteme gerekçesi açıklanmamış. Test hesabı verilmemiş. Uygulama web sitesinin birebir kopyası ve ek değer sunmuyor.

Son madde önemli. Sitenizi olduğu gibi uygulamaya çevirmek çoğu zaman reddediliyor. Uygulamanın bir sebebi olmalı, bildirim, çevrimdışı erişim ya da cihaz özelliklerinin kullanımı gibi.

Gizlilik bildirimi zorunlu

Her iki mağaza da uygulamanın hangi veriyi topladığını beyan etmenizi istiyor. Beyan ile uygulamanın gerçekte yaptığı örtüşmek zorunda.

Yanlış beyan uygulamanın kaldırılmasına kadar gidebiliyor. Bu yüzden hangi kütüphanenin arka planda ne topladığını bilmek gerekiyor.

Analitik ya da reklam kütüphanesi eklediğinizde beyanınız değişiyor. Ekleyen kişi bunu bildirmezse beyan eskiyor.

Yayından sonrası

Uygulama yayınlandığında iş bitmiyor, başlıyor.

İşletim sistemleri her yıl yeni sürüm çıkarıyor ve bazı değişiklikler uygulamayı bozabiliyor. Yılda en az bir kez uyumluluk güncellemesi gerekiyor.

Mağazalar da kurallarını güncelliyor. Yeni bir zorunluluk geldiğinde uygulamanın güncellenmesi gerekiyor, yoksa mağazadan kaldırılabiliyor.

Bir de kullanıcı geri bildirimi var. Mağaza yorumları hem itibar hem ürün geliştirme kaynağı.

Uygulama içi satın alma varsa

Dijital bir içerik ya da abonelik satıyorsanız mağazalar kendi ödeme sistemlerini kullanmanızı isteyebiliyor ve komisyon alıyor.

Fiziksel ürün ya da uygulama dışında tüketilen bir hizmet satıyorsanız kendi ödeme altyapınızı kullanabiliyorsunuz. Ayrım her zaman net değil ve kural yanlış yorumlanırsa uygulama reddediliyor.

Bu konuyu geliştirme başlamadan netleştirin. İş modelinizin komisyona tabi olup olmadığı fiyatlandırmanızı doğrudan etkiliyor.

Bildirim göndermek göründüğü kadar basit değil

Anlık bildirim uygulamanın en değerli özelliği ama kurulumu birkaç parçadan oluşuyor. Sunucu tarafı, sertifikalar ve kullanıcı izni.

Kullanıcı izin vermezse bildirim gönderemiyorsunuz. Bu yüzden izni ne zaman istediğiniz önemli. Uygulama ilk açıldığında sormak en düşük onay oranını veriyor. İzni, kullanıcı faydayı anladıktan sonra istemek daha iyi sonuç veriyor.

Bir de bildirim yorgunluğu var. Çok bildirim gönderen uygulamalar sessize alınıyor ya da siliniyor.

Gerçekçi bir zaman çizelgesi

Sürelerin tamamı kapsama bağlı ama sıralama hemen her projede aynı.

• Keşif ve kapsam belirleme
• Tasarım ve akış onayı
• Backend ve API geliştirme
• Uygulama geliştirme
• İç test
• Test kullanıcılarıyla dağıtım ve geri bildirim
• Mağaza başvurusu ve inceleme
• Yayın

Mağaza hesabı işlemleri en baştan, birinci adımla paralel başlatılmalı. Bu tek başına haftalar kazandırıyor.

Sürüm yönetimi web'den farklı

Web sitesinde hata bulursanız düzeltip yayınlarsınız, birkaç dakika sürer. Uygulamada öyle olmuyor.

Düzeltmeyi yayınlamak için yeni sürüm çıkarmanız, mağaza incelemesinden geçmeniz ve kullanıcıların güncellemesini beklemeniz gerekiyor. Bir kısmı hiç güncellemiyor.

Bu yüzden mobil tarafta test daha kritik. Web'de tolere edilebilecek bir hata, uygulamada haftalarca ekranlarda kalıyor.

Mağazada bulunabilirlik

Uygulamanızı yayınlamanız kimsenin bulacağı anlamına gelmiyor. Mağazaların kendi araması var ve orada sıralanmak ayrı bir iş.

Başlık, alt başlık ve açıklama metni aramada karşılık buluyor. Ekran görüntüleri indirme kararını doğrudan etkiliyor. İlk iki görsel çoğu kişinin gördüğü tek şey.

Bir de puan var. Düşük puan hem sıralamayı hem indirmeyi düşürüyor. Kullanıcıdan puan istemenin doğru anı var, uygulama ilk açıldığında değil, işe yaradığını gösterdikten sonra.

Bu kalemler geliştirme bütçesinin içinde değil ama işin başarısını belirliyor. Plan yaparken hesaba katın.

Uygulamaya gerçekten ihtiyacınız var mı

Dürüst soru bu. Uygulama pahalı ve sürekli bakım istiyor. İhtiyacınız mobil uyumlu bir siteyle karşılanıyorsa uygulama yaptırmak para yakmak olabilir.

Uygulama şu durumlarda anlamlı. Kullanıcılar düzenli ve sık geliyorsa. Bildirim göndermek işin merkezindeyse. Kamera, konum gibi cihaz özellikleri gerekiyorsa. Çevrimdışı çalışması gerekiyorsa.

Yılda birkaç kez girilen bir hizmet için uygulama, indirilmiyor ve indirilse bile siliniyor.

Nasıl ilerlemeli

Küçük başlayın. Önce çekirdek işlevle bir sürüm çıkarın, kullanıcıyı izleyin, sonra ekleyin. Baştan her özelliği koymak hem pahalı hem riskli, çünkü hangi özelliğin kullanılacağını yayınlamadan bilemezsiniz.

Kapsamı konuşmak isterseniz yazın. Neyin gerekli neyin ertelenebilir olduğunu birlikte ayıralım.