Mobil uygulama yaptırma maliyeti: fiyatı ne belirliyor

Üç ayrı ajansa "işletmem için bir mobil uygulama" diye teklif sor, aralarında üç kata varan fark olan üç rakam görürsün. Fark kâr marjından değil, kapsamdan geliyor: her ajans aynı tek cümleni farklı bir işe çevirmiş. Bu yazı sana bir rakam vermiyor. Hangi kararın fiyatı hangi yönde hareket ettirdiğini gösteriyor, böylece bir teklifi okuduğunda içinde gerçekte ne olduğunu anlarsın.

Üç kat fark nereden geliyor

"Mobil uygulama" çok farklı işleri kapsayan bir tabir. Bir teklif, çalışan bir girişi bile olmayan tıklanabilir bir arayüz kabuğunu kapsıyor olabilir. Bir başkası, gerçek kimlik doğrulama, bir backend ve uçtan uca mağaza gönderimini içeren üretim seviyesinde bir build'i kapsıyor. Üçüncüsü, zaten bir backend'in olduğunu sessizce varsayıp sadece ekranları fiyatlandırıyor olabilir. Hiçbiri rakamda yalan söylemiyor, sadece sorduğun sorudan farklı bir soruyu cevaplıyorlar.

Çözüm daha düşük bir rakam istemek değil. Her ajanstan, aşağıdaki listeye karşı, neyin dahil neyin dışarıda olduğunu kalem kalem yazmasını istemek.

Tek platform mu çift mi: React Native kararının etkisi

Maliyetteki ilk gerçek ayrım, iki platform için tek bir kod tabanı mı yoksa iki ayrı native uygulama mı yazacağın.

Mobil uygulama geliştirme işimiz bu yüzden varsayılan olarak React Native ve Expo'ya dayanıyor: çoğu işletme uygulaması için doğru cevap bu, ve tek bir ekibin tek kod tabanından iki mağazaya birden çıkabilmesini sağlıyor.

Backend var mı yok mu: tek büyük değişken

Sadece statik içerik gösteren bir uygulama, menü, katalog, salt okunur bir sayfa seti, hiçbir backend gerektirmez. Hesap eklediğin, cihazlar arasında senkron olan veri eklediğin ya da bir yöneticinin yeni bir uygulama sürümü çıkarmadan güncelleyebileceği bir şey eklediğin an, bir backend gerekir: ya özel bir tane, ya da doğru kurulmuş bir backend-as-a-service platformu (Supabase veya Firebase, auth, veritabanı, row-level security, storage kuralları dahil).

Bu karar, bu sayfadaki herhangi bir entegrasyondan daha fazla maliyet hareket ettiriyor, çünkü bir özellik değil, tasarlanması, güvenli hale getirilmesi ve çalışır tutulması gereken ikinci bir sistem bütünüyle. Uygulamanın çalışan bir web sürümü ve backend'i zaten varsa, mobil istemci genelde onu yeniden kullanabilir. Gerçek bir uygulamaya giden en ucuz yollardan biri bu.

Ödeme, abonelik ve mağaza komisyonu

Uygulama içinde dijital ürün veya abonelik satmak Apple'ın ve Google'ın uygulama içi satın alma kurallarını devreye sokar, ikisi de bu gelirden komisyon alır (tam oran ve küçük işletme indirimli oranı kendi geliştirici şartlarında; hesabına uygulanan güncel oranı fiyatlamadan önce kontrol et). Fiziksel ürün veya hizmet satışı genelde mağazanın payı dışında kendi ödeme sağlayıcından geçebilir, ama neyin "dijital" neyin "fiziksel" sayıldığına dair kurallar spesifik; kapsamı belirlemeden önce mağazanın kendi kurallarına bakmakta fayda var.

Abonelik kendi mühendisliğini getiriyor: deneme süresi, yenileme, iptal ve yeni bir cihazda satın almayı geri yükleme. Bir kere abonelik sunmaya karar verdiğinde bunların hiçbiri opsiyonel değil, ve hiçbiri bir demo'da sadece bir kere gösterilen ödeme ekranında görünmüyor.

Push, harita, kamera, konum: her biri ayrı bir iş kalemi

Tek tek küçük görünen özellikler, küçük göründükleri için ücretsiz değil. Aşağıdaki aralıklar bu tür işin genelde nasıl kapsandığına dair kaba bir iş ağırlığı, kesin bir teklif değil, senin entegrasyonun ve uç durumların bunları değiştirir.

Sabit maliyetler: geliştirici hesapları ve altyapı

Herhangi bir ajansın işçiliğinden bağımsız olarak, her mağaza uygulamasına üç platform ücreti uygulanıyor, ve bunlar teklifte neredeyse hiç kalem kalem gösterilmiyor:

Apple ve Google hesapları senin adına olmalı, ajansına veya uygulamayı iskeletleyen yapay zeka aracına değil. O hesaba sonradan erişimi kaybetmek, zaten yayında olan bir uygulamaya güncelleme gönderme yeteneğini de kaybetmek demek.

Mağazaya çıkış süreci

Hesap ücretlerinin ötesinde, gönderimin kendisi gerçek bir iş: mağaza listeleme metni, gerekli cihaz boyutlarında ekran görüntüleri, bir gizlilik politikası, ve başka bir uygulamadan kopyala-yapıştır değil doğru doldurulmuş Apple'ın App Privacy anketi veya Google'ın Data Safety formu. Apple'ın incelemesi de gönderimin şablonun varsayılan çıktısı değil senin gerçek ürünün gibi okunup okunmadığına bakıyor; bu konuda Apple'ın hangi inceleme maddelerinin yapay zeka üretimi uygulamaları takıldığını ayrı bir yazıda ele aldık. En az bir inceleme gidiş-dönüşü için pay bırak: ilk gönderimler bir metadata veya izin detayında yeterince sık reddediliyor ki bu bir yayın tarihini raydan çıkarmamalı.

Yayın sonrası: bakım, sürüm, mağaza kural değişiklikleri

Bir mağaza uygulaması, deploy edilen bir web sitesi gibi yayınlandığı anda bitmiyor. Apple ve Google her yıl yeni OS sürümleri çıkarıyor, ve uygulamanın üzerine kurulduğu SDK er ya da geç yeni cihazlarda kurulabilir kalmak için bir yükseltme istiyor. Mağaza kuralları da değişiyor, bazen geçen yıl gerekmeyen yeni bir gizlilik beyanı veya izin gerekçesi isteniyor. Bunların hiçbiri opsiyonel bakım değil, uygulamayı mağazada tutan şey bu. LumiCare paketimizin kapatmak için var olduğu boşluk tam olarak bu: sertifika yenileme, SDK yükseltmeleri ve hiç bitmeyen mağaza yeniden incelemeleri.

Kapsamı küçültmenin doğru yolu

Kimlik doğrulamadan, veri erişim kurallarından ya da ödemenin doğruluğundan kısarak tasarruf etme, bu hatalar sonradan çok daha pahalıya patlıyor. Bunun yerine kıs: gerçek kullanıcılarının olduğu platformda yayınla, ikinciyi trafik görünce ekle; içeriğin gerçekten gerektirmiyorsa backend olmadan başla; harita veya kamera gibi ana işlev dışı entegrasyonları ikinci sürüme ertele. Dört soruya cevap verir vermez anında tek bir rakam tükürten bir form bu kararların hiçbirini bilemez, o rakamı bir teklif değil, kaba bir başlangıç tahmini olarak gör.

Sık sorulan sorular

Sabit fiyat mı yoksa kapsam bazlı teklif mi istemeliyim?
Kapsam bazlı, bu sayfadaki kalemler açıkça adlandırılmış olarak. Sabit fiyat ancak iki taraf da neyin dahil olduğunda anlaştığında bir anlam ifade ediyor.

Native (Swift/Kotlin) React Native'den ne zaman gerçekten daha ucuza gelir?
İlk sürüm için neredeyse hiçbir zaman. Sonradan, tek bir platform için, uygulama köprünün iyi kaldıramadığı bir şeye dayanıyorsa, örneğin kalıcı arka plan işlem, mantıklı olabilir.

Backend'i sonradan eklemek mi en baştan kurmak mı daha ucuz?
Hesap veya senkron veri gerekeceğini zaten biliyorsan en baştan. Statik içerik olarak yapılmış bir uygulamaya sonradan backend eklemek, bir kere yayınladığın veri akışını yeniden kurmak demek.

Apple ve Google'ın komisyonu her ödemeye mi uygulanıyor?
Hayır. Uygulama içinde satın alınan dijital ürün ve aboneliklere uygulanıyor. Fiziksel ürün ve çoğu hizmet genelde kendi ödeme sağlayıcından geçebiliyor; kapsamı belirlemeden önce kategorine uygulanan güncel mağaza kurallarına bak.

MVP'yi tek platformda yayınlayıp ikinciyi sonra mı eklemeliyim?
Sadece kullanıcıların gerçekten tek bir OS'te yoğunlaşmışsa. Kitlen karma ise, tek platformda yayınlamak diğer yarının dönüşüp dönüşmediğini öğrenmeyi sadece erteliyor.