Mobil Uygulama Maliyeti Neye Göre Değişir? İşletmeler İçin Rehber

"Bir mobil uygulama kaça yapılır?" sorusu, "bir ev kaça yapılır?" sorusuna benzer. Kaç oda olacağı, hangi malzemenin kullanılacağı ve arsanın nerede olduğu bilinmeden verilen her rakam ya çok iyimserdir ya da gereğinden temkinli. Mobil uygulama fiyatları da aynı şekilde, ne yapılacağı netleşmeden sağlıklı biçimde konuşulamaz.

Bu yazı, uygulama yaptırmayı düşünen işletme sahipleri ve kurumlar için hazırlandı. Rakam vermek yerine mobil uygulama geliştirme maliyetinin neye göre belirlendiğini anlatıyoruz: hangi kararlar bütçeyi büyütür, hangileri küçültür, yayından sonra hangi giderler devam eder ve mobil uygulama geliştirme firmalarından teklif alırken nelere dikkat etmek gerekir.

Maliyeti belirleyen temel faktörler#

Bir uygulamanın maliyeti, büyük ölçüde harcanacak geliştirme emeğinden oluşur. Bu emeği büyüten ya da küçülten kararlar aşağıdaki başlıklarda toplanır.

Platform: iOS, Android ya da ikisi#

İlk soru, uygulamanın hangi cihazlarda çalışacağıdır. Yalnızca Android uygulama geliştirme ya da yalnızca iOS uygulama geliştirme, iki platformu birden hedeflemekten daha az iş demektir. Ancak hedef kitlenizin hangi telefonları kullandığını bilmeden tek platforma karar vermek, kullanıcıların bir kısmını baştan dışarıda bırakmak anlamına gelebilir. Kurumsal uygulamalarda bu karar çoğu zaman çalışanların ya da müşterilerin kullandığı cihazlara bakılarak verilir.

Native mi, cross-platform mu?#

Native geliştirmede her platform için ayrı kod yazılır: iOS için Swift, Android için Kotlin gibi. Bu yaklaşım platformun tüm imkânlarına doğrudan erişim sağlar, ama iki ayrı kod tabanı demektir ve her özellik iki kez geliştirilir, iki kez test edilir.

Flutter ve React Native gibi cross-platform araçlarda ise tek bir kod tabanından iki platform için uygulama çıkar. İş uygulamalarının, kurumsal araçların ve içerik ağırlıklı uygulamaların büyük bölümü için bu yaklaşım hem geliştirme hem bakım maliyetini belirgin biçimde azaltır. Yoğun grafik işleyen, cihaz donanımını sınırına kadar kullanan ya da platforma özgü yeni özelliklere ilk günden ihtiyaç duyan uygulamalarda native geliştirme daha doğru tercih olabilir.

Ekran ve özellik sayısı#

Maliyetin en doğrudan göstergesi, uygulamanın kaç ekrandan oluştuğu ve bu ekranların ne yaptığıdır. Sadece bilgi gösteren bir ekran ile kullanıcının veri girdiği, filtrelediği, düzenlediği bir ekran aynı emeği gerektirmez. Bu yüzden ekran sayısı tek başına değil, her ekrandaki iş mantığıyla birlikte değerlendirilmelidir.

Kullanıcı girişi, ödeme, bildirim, harita, çevrimdışı çalışma#

Bazı özellikler kulağa basit gelir ama arkasında ciddi bir iş yükü vardır:

• Kullanıcı girişi: E-posta ile giriş, telefon doğrulaması, Google ya da Apple ile giriş, şifre sıfırlama ve rol bazlı yetkiler ayrı ayrı iş kalemleridir.
• Ödeme: Uygulama içi satın alma, abonelik ya da kartla ödeme; ödeme sağlayıcısı entegrasyonu, iade senaryoları ve mağaza kurallarına uyum gerektirir.
• Bildirim: Bildirim göndermek kolaydır; doğru kişiye, doğru zamanda, doğru içerikle göndermek için arka uçta bir kurgu gerekir.
• Harita ve konum: Konum gösterme, rota çizme, yakındaki noktaları listeleme ya da arka planda konum takibi, karmaşıklık açısından birbirinden çok farklıdır.
• Çevrimdışı çalışma: İnternet yokken de çalışan ve bağlantı gelince verileri eşitleyen bir uygulama, çakışan değişikliklerin nasıl çözüleceğinin tasarlanmasını gerektirir. Bu, en çok hafife alınan özelliklerden biridir.

Arka uç ve yönetim paneli#

Kullanıcının gördüğü uygulama, buzdağının görünen kısmıdır. Verinin saklandığı sunucu, uygulamanın konuştuğu API ve içeriği yöneten panel çoğu projede en az mobil taraf kadar emek ister. Ürün listesini, kullanıcıları, siparişleri ya da duyuruları kimin, nereden yöneteceği baştan konuşulmazsa bu ihtiyaç proje ortasında ortaya çıkar ve planı değiştirir.

Entegrasyonlar#

Uygulama kendi başına mı çalışacak, yoksa ERP, muhasebe, CRM ya da okul yönetim sisteminiz gibi mevcut yazılımlarla konuşacak mı? Her entegrasyon ayrı bir iş kalemidir. Karşı sistemin iyi belgelenmiş bir API'si varsa iş hızlı ilerler; yoksa önce veri alışverişinin nasıl yapılacağı çözülmelidir.

Tasarım#

Hazır bileşenlerle sade bir arayüz ile markaya özel, animasyonlu ve kullanıcı testleriyle şekillenmiş bir arayüz arasında ciddi bir emek farkı vardır. Tasarımı baştan netleştirmek, geliştirme sırasında "bu ekranı baştan yapalım" turlarını azaltır ve toplam maliyeti düşürür.

Yapay zeka özellikleri#

Metin özetleme, sohbet asistanı, görüntüden ürün tanıma ya da kişiselleştirilmiş öneri gibi yapay zeka özellikleri giderek daha sık isteniyor. Bunların maliyeti, hazır bir model servisinin mi kullanılacağına yoksa kuruma özel veriyle bir sistem mi kurulacağına bağlıdır. Hazır servislerde kullanım arttıkça artan bir işletme gideri oluşur; bunun da baştan hesaba katılması gerekir. Konuya yeniyseniz Yapay Zeka Nedir? yazımız iyi bir başlangıç noktası olabilir.

Güvenlik ve KVKK#

Kişisel veri işleyen her uygulama, KVKK kapsamındaki yükümlülükleri tasarım aşamasından itibaren dikkate almalıdır: hangi verinin neden toplandığı, nerede saklandığı, kimin erişebildiği ve nasıl silineceği. Şifreli veri aktarımı, rol bazlı yetkilendirme ve düzenli yedekleme sonradan eklenecek ayrıntılar değil, mimarinin parçasıdır. Sağlık, eğitim ya da finans gibi hassas alanlarda bu başlığın payı daha da büyür.

Küçük, orta ve büyük kapsam neye benzer?#

Rakam vermeden de kapsamı tarif etmek mümkün. Aşağıdaki üç örnek, aynı soruya farklı cevaplar veren projeleri temsil ediyor.

Küçük kapsam: Tek bir işi yapan, az sayıda ekrandan oluşan bir uygulama. Örneğin bir işletmenin ürün kataloğunu gösteren, basit bir talep formu içeren ve içeriği hazır bir panelden yönetilen bir uygulama. Kullanıcı girişi yoktur ya da basittir, ödeme ve entegrasyon yoktur.

Orta kapsam: Kullanıcı hesapları, rol bazlı yetkiler, bildirimler, özel bir yönetim paneli ve bir ya da iki entegrasyon içeren uygulama. Randevu, sipariş takibi ya da saha ekibi uygulamaları çoğunlukla bu gruptadır.

Büyük kapsam: Birden fazla kullanıcı tipinin (örneğin müşteri, kurye ve işletme) ayrı arayüzlerle çalıştığı, ödeme, harita, çevrimdışı çalışma, birden fazla entegrasyon ve yapay zeka özelliği barındıran, yüksek kullanıcı sayısına göre ölçeklenmesi gereken platformlar.

Kapsam büyüdükçe yalnızca geliştirme süresi uzamaz; test, güvenlik ve bakım yükü de onunla birlikte artar.

Proje aşamaları: keşiften bakıma#

Sağlıklı ilerleyen bir mobil uygulama projesi genellikle beş aşamadan geçer:

1. Keşif: Uygulamanın kimin için, hangi problemi çözmek üzere yapılacağı, hangi özelliklerin ilk sürümde şart olduğu ve neyin sonraya bırakılabileceği netleştirilir. Doğru bir fiyatlandırma ancak bu aşamadan sonra mümkündür.
2. Prototip: Ekranlar ve kullanıcı akışı tıklanabilir bir taslak olarak hazırlanır. Kod yazılmadan önce yanlış anlaşılmaları yakalamanın en ucuz yolu budur.
3. MVP: Uygulamanın temel işini yapan ilk sürüm geliştirilir. MVP yarım bir ürün değildir; az özellikli ama işini düzgün yapan bir üründür.
4. Yayın: Mağaza hesapları açılır, uygulama App Store ve Google Play inceleme süreçlerinden geçirilir. Mağaza kurallarına uyulmazsa uygulama reddedilebilir; bu yüzden bu adım da plana dahil edilmelidir.
5. Bakım ve geliştirme: Kullanıcı geri bildirimleriyle yeni sürümler çıkar, hatalar giderilir, yeni işletim sistemi sürümlerine uyum sağlanır.

Yayından sonra gelen maliyetler#

Teklif karşılaştırırken en çok gözden kaçan kalemler, uygulama yayına girdikten sonra devam eden giderlerdir:

• Mağaza hesapları: Apple Developer Program üyeliği yıllık 99 ABD dolarıdır (bölgeye göre yerel para biriminde gösterilebilir; kâr amacı gütmeyen kuruluşlar, akredite eğitim kurumları ve kamu kurumları belirli koşullarla muafiyet talep edebilir). Google Play geliştirici hesabı ise 25 ABD doları tutarında tek seferlik bir kayıt ücretiyle açılır.
• Sunucu ve servisler: Veritabanı, dosya depolama, bildirim servisi, harita ve yapay zeka servisleri genellikle kullanıma göre ücretlendirilir. Kullanıcı sayısı arttıkça bu gider de artar.
• Bakım: Hata düzeltmeleri, güvenlik güncellemeleri ve küçük iyileştirmeler için düzenli bir bakım bütçesi ayrılmalıdır.
• İşletim sistemi güncellemeleri: Apple ve Google her yıl yeni işletim sistemi sürümleri çıkarır ve mağazalar zamanla yeni sürümlere uyum şartı getirir. Hiç dokunulmayan bir uygulama bir süre sonra güncelleme yapılamaz ya da mağazada görünmez hale gelebilir.

Maliyeti düşürmenin yolları#

Bütçeyi kontrol altında tutmanın yolu kaliteden kısmak değil, doğru sırayla ilerlemektir:

• MVP ile başlamak: İlk sürümde yalnızca uygulamanın varlık sebebi olan özellikleri geliştirin. Kullanıcıların gerçekten ne istediğini gördükten sonra eklenen özellikler hem daha isabetli hem daha ucuzdur.
• Cross-platform tercih etmek: Uygun projelerde tek kod tabanı, iki platform için ayrı ayrı geliştirme ve bakım yapmaktan daha ekonomiktir.
• Hazır servisleri kullanmak: Kimlik doğrulama, bildirim, ödeme ve harita gibi işler için olgun hazır servisler vardır. Bunları sıfırdan yazmak nadiren mantıklıdır.
• Mobil uygulamaya gerçekten ihtiyaç olup olmadığını sorgulamak: Bazı ihtiyaçlar, telefonda sorunsuz çalışan bir web uygulamasıyla karşılanabilir. Örneğin İspat Koleji için geliştirdiğimiz soru çözüm uygulaması web tabanlı ve mobil uyumlu çalışıyor; öğrencinin tarayıcıdan giriş yapması yeterli, ayrıca bir kurulum gerekmiyor. Benzer bir kurumlara özel etüt uygulaması düşünen kurumlar için bu yaklaşım, mağaza süreçlerini ve iki ayrı uygulamanın bakım yükünü ortadan kaldırır.

Teklif alırken sorulacak sorular#

Mobil uygulama geliştirme firmalarından gelen teklifleri karşılaştırabilmek için şu sorulara net cevap alın:

• Teklife hangi ekranlar ve özellikler dahil, hangileri dahil değil?
• Arka uç ve yönetim paneli teklifin içinde mi?
• Native mi, cross-platform mu geliştirilecek? Neden bu tercih yapıldı?
• Kaynak kodu ve mağaza hesapları kimin adına olacak?
• Test süreci nasıl işleyecek, teslimden sonra ne kadar süre hata düzeltme kapsamında?
• Yayından sonraki bakım nasıl fiyatlanıyor?
• Sunucu ve üçüncü taraf servislerin aylık giderleri ne olacak, kim ödeyecek?
• Kişisel veriler nerede saklanacak, KVKK yükümlülükleri nasıl karşılanacak?
• Proje ortasında kapsam değişirse süreç nasıl yürüyecek?

Kırmızı bayraklar#

Aşağıdaki işaretler, teklifin ya da firmanın daha dikkatli incelenmesi gerektiğini gösterir:

• İhtiyaç dinlenmeden fiyat verilmesi: Kapsam konuşulmadan söylenen her rakam, ileride ek faturayla düzeltilecek bir tahmindir.
• Kalem kalem ayrıştırılmamış tek satırlık teklif: Neyin dahil olduğu yazılı değilse, neyin dahil olmadığı da tartışma konusu olur.
• Kaynak kodunun ve hesapların firmada kalması: Uygulamanın ve mağaza hesaplarının sahibi siz olmalısınız; aksi halde firmayı değiştirmek çok zorlaşır.
• Bakım ve güncellemelerden hiç söz edilmemesi: Yayın, projenin sonu değil başlangıcıdır.
• Gerçekçi olmayan süre ve fiyat vaatleri: Diğer tekliflerin çok altında kalan bir rakam, genellikle eksik anlaşılmış bir kapsama işaret eder.
• Güvenlik ve veri korumayla ilgili sorulara belirsiz cevaplar: Verinin nerede durduğunu net söyleyemeyen bir ekip, o veriyi korumayı da planlamamış olabilir.

Sonuç#

Mobil uygulama maliyetini belirleyen şey teknoloji değil, kapsamdır: kaç platform, kaç özellik, hangi entegrasyonlar ve yayından sonra ne kadar bakım. Bu yüzden doğru teklif, iyi yapılmış bir keşifle başlar. Fikrinizi birlikte netleştirmek, ilk sürümde neyin şart olduğunu belirlemek ve gerçekçi bir yol haritası çıkarmak için iletişim sayfamızdan ücretsiz keşif görüşmesi talep edebilir ya da tüm çözümlerimizi hizmetler sayfasında inceleyebilirsiniz.

Sık Sorulan Sorular#

Mobil uygulama fiyatları neden firmadan firmaya bu kadar farklı?#

Çünkü her firma aynı fikri farklı bir kapsamla fiyatlıyor olabilir. Biri yönetim panelini, test sürecini ve yayın desteğini teklife dahil ederken, diğeri yalnızca mobil ekranları fiyatlamış olabilir. Teklifleri karşılaştırmadan önce kapsamın aynı olduğundan emin olmak gerekir.

iOS ve Android için ayrı ayrı uygulama yaptırmak gerekir mi?#

Her zaman değil. Flutter ya da React Native gibi cross-platform araçlarla tek bir kod tabanından iki platform için uygulama geliştirilebilir. Yoğun grafik işleme ya da platforma özgü donanım özellikleri gerektirmeyen çoğu iş uygulaması için bu yaklaşım yeterlidir.

Uygulama yayına girdikten sonra hangi giderler devam eder?#

Apple geliştirici hesabının yıllık ücreti, sunucu ve üçüncü taraf servis giderleri, hata düzeltmeleri, güvenlik güncellemeleri ve yeni işletim sistemi sürümlerine uyum çalışmaları devam eden başlıca kalemlerdir. Google Play hesabı ise tek seferlik bir kayıt ücretiyle açılır.

MVP nedir, neden önerilir?#

MVP, uygulamanın temel işini yapan ilk sürümüdür. Tüm özellikleri baştan geliştirmek yerine en kritik olanlarla başlamak, bütçeyi kontrol altında tutar ve sonraki adımların gerçek kullanıcı geri bildirimine göre belirlenmesini sağlar.

Kesin fiyatı ne zaman öğrenebiliriz?#

Kesin fiyat, kapsamın netleştiği keşif aşamasından sonra verilebilir. Hangi kullanıcıların uygulamayı kullanacağı, hangi özelliklerin ilk sürümde şart olduğu ve hangi sistemlerle entegrasyon gerektiği belli olduğunda, kalem kalem ayrıştırılmış bir teklif hazırlamak mümkün olur.