Mobil Uygulama Fiyatları: Maliyeti Ne Belirler?

Mobil uygulama fiyatları tek bir rakama bağlanamaz, çünkü "uygulama" çok farklı işleri kapsar. Randevu listesi gösteren bir uygulama ile fotoğraftan yemek tanıyıp günlük plan çıkaran bir uygulama aynı sınıfta fiyatlanmaz. Maliyeti platform sayısı, özellikler, sunucu tarafı, entegrasyonlar ve yayın sonrası bakım belirler. Bu yazıda tutar vermiyoruz, çünkü piyasa rakamları çabuk eskir ve kesin sayı ancak yazılı kapsamla çıkar. Onun yerine fiyatı hangi kararların oluşturduğunu ve gelen teklifleri nasıl karşılaştıracağınızı anlatıyoruz. Uygulamanın arkasında kendi iş kurallarınıza göre bir sistem de gerekiyorsa özel yazılım yaptırmak yazısı o tarafı anlatıyor.

Mobil uygulama maliyetini hangi kararlar belirler?

Faturayı altı karar şekillendirir.

Platform sayısı ve yaklaşımı: tek platform mu, iki platform mu; her biri için native mi, tek kod tabanlı çapraz platform çözümü mü. Bu tercih hem geliştirme emeğini hem bakım yükünü değiştirir. Ayrıntısı aşağıda.

Ekran ve özellik sayısı: görünen kısım fiyatın yalnızca bir parçasıdır. Giriş, profil, bildirim, mesajlaşma, ödeme ve harita gibi her özellik geliştirme süresini ve test yükünü artırır, yayından sonra da bakım ister.

Sunucu tarafının karmaşıklığı: kullanıcı yönetimi, veritabanı, gerçek zamanlı özellikler, dosya depolama ve yönetim paneli çoğu uygulamada ekrandan fazla iş demektir. Örneğin kullanıcı bir fotoğraf yüklediğinde arka planda dosyanın saklanması, işlenmesi, hesabına bağlanması ve yedeklenmesi gerekir. Kullanıcı bunların hiçbirini görmez, ama işin büyük kısmı orada.

Entegrasyonlar: ödeme, harita, bildirim ve mevcut sistemlerinizle bağlantılar. Üçüncü taraf bir servisin arayüzü beklenenden zor çıkarsa süre ve maliyet birlikte uzar.

Tasarımın özgünlüğü: platformun hazır bileşenleriyle kurulan bir arayüz ile baştan çizilen özgün bir arayüz farklı emek ister. Tıklanabilir prototip, bu farkı kodlamadan önce telefonda görmenizi sağlar. Değişiklik prototipte ucuzdur, kodda pahalıdır.

Yayın sonrası bakım: App Store ve Google Play geliştirici hesapları, sunucu giderleri ve düzenli güncellemeler yayınla bitmez. Her yıl yeni iOS ve Android sürümleri çıkar, mağaza kuralları değişir. Bakımı yapılmayan bir uygulama yeni cihazlarda sorun çıkarmaya başlar ya da mağaza kurallarına uymadığı için yayından kalkabilir. Bakımı bütçede baştan ayrı bir kalem olarak görün.

İlk sürümü küçük tutmak maliyeti nasıl düşürür?

İlk sürümün (MVP) sınırını tek bir cümle çizer: uygulama kimin hangi sorununu nasıl çözüyor? Bir özellik bu cümleye hizmet etmiyorsa ilk sürümde olması gerekmez. Basit bir test de işe yarar: bu özellik olmadan uygulama işe yarar mı? Ödeme almayan bir randevu uygulaması yayına çıkabilir, randevu almayan bir randevu uygulaması çıkamaz.

Küçük başlamanın iki faydası var. Başlangıç maliyeti düşer ve hangi özelliğin büyütüleceğine gerçek kullanıcı geri bildirimi karar verir. Kullanılmayacak bir özelliği tahmine dayanarak yaptırmak en pahalı israftır.

Native mi çapraz platform mu?

Native yaklaşımda her platform için ayrı bir uygulama geliştirilir ve platformun kendi arayüzleri kullanılır. Çapraz platform tek kod tabanıyla iki platformu hedefler. Karar uygulamanın ne yaptığına ve bütçeye bağlıdır:

Ölçüt	Native	Çapraz platform
Kod tabanı	Her platform için ayrı	Tek ortak kod tabanı
Cihaz özellikleri	En doğrudan erişim	Çoğu zaman ek bir katman üzerinden
Platform alışkanlıkları	Platformun kendi bileşenleri	Ortak bileşenler, uyarlama gerekir
Uygun durum	Donanım ve performans öncelikliyse	Basit ve iki platformda aynı arayüz yeterliyse

Native tarafın resmi dilleri ve araçları Swift ile Kotlin belgelerinde, çapraz platform seçenekleri ise Flutter ve React Native sitelerinde anlatılıyor. Mobil uygulama projelerini her platforma özel, native yaklaşımla ele alıyoruz. Saat, sağlık verisi ya da kamera gibi cihaz özellikleri ürünün merkezindeyse çapraz platform yolunun kazancı küçülür. Uygulamanız yalnızca form, liste ve bildirimden oluşuyorsa hesap başka çıkabilir. Bunu ilk görüşmede açıkça konuşmak, sonradan mimariyi değiştirmekten ucuzdur.

Kullanıcı kitleniz belirgin biçimde tek platformda toplanıyorsa o platformdan başlamak da bütçeyi dengeler.

Süreç adımları fiyatı nasıl etkiler?

Sağlıklı bir uygulama projesi sekiz adımdan geçer: strateji ve planlama, ürün mimarisi, UX/UI tasarım, frontend geliştirme, backend ve AI, test, içerik ve optimizasyon, yayın ve gelişim. Adımlar kâğıt üzerinde sıralı görünse de bazıları iç içe ilerler. Maliyet açısından önemli olan nokta şu: bir önceki adımın kararı netleşmeden sonrakine geçmek, işi daha pahalı bir aşamada yeniden yapmak demektir.

Bu yüzden maliyeti belirleyen kararların çoğu ilk iki adımda verilir. Strateji adımında ilk sürümün kapsamı, platform ve başarı ölçütü belirlenir ve çıktı yazılı bir kapsam belgesi olur: hedef kullanıcılar, ekran listesi, kullanıcı akışları, bağlanacak sistemler ve hedef platformlar. Mimari adımında verilerin nerede tutulacağı, uygulamanın sunucuyla nasıl konuşacağı ve internet yokken ne yapacağı gibi sorular cevaplanır. Bu kararlar sonradan değiştirilebilir, ama geliştirme ilerledikçe değiştirmenin bedeli hızla artar.

Test ve yayın adımları da fiyata girer. Uygulama farklı cihazlarda, zayıf bağlantıda, performans ve güvenlik açısından sınanır. Android tarafında cihaz çeşitliliği ayrı bir test yükü getirir. Apple tarafında TestFlight, Google tarafında Play Console test kanalları yayın öncesi kapalı test için kullanılır.

Yayında iki mağazanın geliştirici hesapları, inceleme süreçleri ve kuralları ayrıdır. Her mağazanın gereksinimleri ayrı ayrı kontrol edilmelidir. Ret sebepleri çoğu zaman öngörülebilir: eksik gizlilik politikası, çalışmayan giriş akışı, inceleme ekibine test hesabı verilmemesi ya da açıklamayla örtüşmeyen içerik. Her iki mağaza uygulamanın hangi veriyi topladığını beyan etmenizi ister. Apple'ın App Store inceleme yönergeleri gizlilik ve veri kullanımı kurallarını ayrıntılı anlatıyor. Reddin yol açtığı yeni tur hem süreyi hem emeği uzatır.

Maliyeti etkileyen üç karar

Bir mobil ürünün fiyatını yalnızca ekranlar belirlemez. Aşağıdaki üç karar teklifteki kalemleri doğrudan değiştirir ve ilk görüşmede konuşulmaları gerekir.

Ek donanım istemek ya da istememek. Bir bileklik ya da sensör gerektiren ürünün ilk engeli satın alma olur; ek donanım ayrıca entegrasyon ve test işi getirir. Telefonun ve saatin zaten verdiği veriyle çalışan bir ürün daha az engelle başlar. Bedeli, ürünün cihazın sunduğu veriyle sınırlı kalmasıdır. Hangi verinin gerçekten gerekli olduğunu baştan yazmak, kapsamı küçültür.

Yapay zekayı ekranda değil sonuçta göstermek. Bir ürünün içindeki görüntü tanıma, tahmin ya da kişiselleştirme çoğu zaman ekranda ayrı bir bölüm olarak görünmez, ama sunucu tarafında ciddi iş yükü oluşturur. Teklifte AI özelliğinin hangi kalemde yer aldığını sormak gerekir. Yapay zekanın başka alanlardaki kullanımı için yapay zeka örnekleri yazısına bakabilirsiniz.

Uygulamanın ön kapısını da hesaba katmak. Mobil ürün mağaza sayfasından önce çoğu zaman bir arama sonucunda tanınır. Bu yüzden uygulamanın tanıtım sayfası ve içerik işi de planlanmalı. Teklifte web sitesi ve tanıtım işinin yer alıp almadığını sormak gerekir. Bu kısım için web tasarım ve geliştirme hizmetimize bakabilirsiniz.

Gelen teklifleri nasıl karşılaştırırsınız?

Belirgin biçimde düşük bir teklif çoğu zaman şu kalemlerden birinin eksik hesaplandığını gösterir: sunucu tarafı, test, mağaza hazırlığı ya da bakım. Aynı kapsam belgesini birkaç ekibe vermek, teklifleri gerçekten karşılaştırılabilir yapar. Web tarafında da aynı mantık işliyor, web sitesi fiyatları yazısı maliyetin kalem kalem nasıl kurulduğunu gösteriyor.

Fiyattan önce dört soru sorun:

• Kodun ve mağaza hesaplarının sahibi kim olacak? Projenize özel kodun hakları size ait olmalı, mağaza hesapları işletmeniz adına açılmalı. İleride ekip değiştirmek isterseniz uygulamanızı yanınızda taşıyabilmeniz buna bağlı.
• Tasarımı yapanla kodu yazan aynı ekip mi? Devir teslimlerle ilerleyen projeler yavaşlar, ayrıntılar yolda kaybolur.
• Ne sıklıkla çalışan bir sürüm göreceksiniz? Aylarca haber alamamak en riskli senaryodur.
• Yayın sonrası bakım teklife dahil mi? Sunucu ve üçüncü taraf servis ücretlerini kimin ödeyeceği de yazılı olsun.

Bu cevapları yazılı alın. Sözlü verilen "tabii ki hallederiz", iş bittiğinde farklı yorumlanabilir.

Mobil uygulama teklifi için ilk görüşmeye ne hazırlanmalı?

İlk görüşmeye şunları getirin:

• Uygulamanın çözdüğü sorunu anlatan tek cümle.
• İlk sürümde olması şart olan özelliklerin listesi.
• Beğendiğiniz ve beğenmediğiniz benzer uygulamalar.
• Bağlanması gereken sistemler ve varsa mevcut altyapınız.
• Hedef kitleniz ve kabaca bir zaman beklentisi.

Bu beş maddeyle görüşme "acaba ne yapsak" yerine "bunu nasıl yaparız" konuşmasına döner ve teklif daha isabetli çıkar.

Sık Sorulan Sorular

Mobil uygulama geliştirme süreci hangi aşamalardan oluşur?

Sağlıklı bir süreç sekiz adımdan geçer: strateji ve planlama, ürün mimarisi, UX/UI tasarım, frontend geliştirme, backend ve AI, test, içerik ve optimizasyon, yayın ve gelişim. Adımların sırası önemli. Tasarım onaylanmadan kodlamaya başlamak ya da testi kısa kesmek, sonradan daha pahalı düzeltmelere yol açar.

App Store ve Google Play yayın süreci arasında ne fark var?

İki mağazanın geliştirici hesapları, inceleme süreçleri ve kuralları ayrıdır. Her mağazanın inceleme ölçütleri farklıdır; eksik gizlilik bilgisi, çalışmayan giriş akışı ya da inceleme ekibine test hesabı verilmemesi en sık görülen ret sebepleridir. Her iki mağaza için de açıklama, ekran görüntüleri ve veri kullanımı bilgileri ayrı ayrı hazırlanır.

Uygulama yayına çıktıktan sonra ne oluyor?

Yayından sonra belirli bir destek süresi başlar. Bu dönemde uygulamanın çalışması takip edilir ve ortaya çıkan teknik sorunlar çözülür. Ardından işletim sistemi güncellemelerine uyum, mağaza kurallarındaki değişiklikler, performans iyileştirmeleri ve yeni özellikler için sürekli bakım gerekir.

Mobil uygulama yaptırmanın maliyetini ne belirler?

Platform sayısı ve yaklaşımı (native ya da çapraz platform), özellik sayısı, sunucu tarafının karmaşıklığı, entegrasyonlar, tasarımın özgünlüğü ve yayın sonrası bakım. Ekran sayısı faturanın küçük bir kısmıdır; asıl iş kullanıcının görmediği sunucu tarafındadır. Kesin rakam yazılı bir kapsam belgesiyle çıkar, bu yüzden yazıda tutar vermiyoruz.

Uygulama için iOS mu Android mi önce gelmeli?

Kullanıcı kitleniz belirgin biçimde tek tarafta toplanıyorsa oradan başlayın. İki platform da gerekiyorsa iki yol var: her platform için ayrı native uygulama ya da tek kod tabanıyla çapraz platform çözümü. Cihaz özelliklerine yakın çalışan uygulamalarda native yol daha az uzlaşma gerektirir.

Mobil uygulama fiyatı için nereden başlamalı?

Fiyatı belirleyen kararların çoğu ilk iki adımda verilir: ilk sürümün kapsamı, platform seçimi, entegrasyonlar ve sunucu tarafının kurulumu. Bunları baştan netleştiren projeler daha öngörülebilir ilerler. Mobil uygulama geliştirme hizmetimizde iOS ve Android için native uygulamaları fikirden UX/UI tasarıma, entegrasyonlara ve App Store ile Google Play yayınına kadar tek ekip olarak üstleniyoruz. Uygulama fikrinizi kapsam ve maliyet açısından konuşmak için hello@ozgnstudio.com adresine kısa bir mesaj yazmanız yeterli.