Mobil uygulama geliştirme maliyeti, tek satırlık bir fiyatla açıklanabilecek bir konu değildir. Aynı sektörde faaliyet gösteren iki şirket, benzer görünen iki uygulama için çok farklı bütçeler ayırabilir. Bu farkı çoğu zaman ekran sayısı değil; iş akışları, entegrasyonlar, güvenlik gereksinimleri, bakım beklentisi ve uygulamanın ne kadar süre kullanılacağı belirler.

KOBİ’ler genellikle hızlı devreye alma, temel özellik seti ve dengeli bir bakım bütçesiyle ilerlemek ister. Kurumsal firmalarda ise tablo değişir. ERP, CRM, SSO, loglama, yetkilendirme, denetim izi, yüksek kullanıcı hacmi ve birden fazla ekiple çalışma gibi başlıklar maliyeti doğrudan etkiler. Sağlıklı bir bütçe planı oluşturmak için “uygulama yapalım” demek yeterli değildir; kapsamın operasyonel detaylarının yazılı hale getirilmesi gerekir.

Bu yazıda mobil uygulama geliştirme maliyeti üzerinde etkili olan ana kalemleri ele alacağız. KOBİ ve kurumsal yapıların ihtiyaç farkını, entegrasyon yükünü, bakım giderlerini ve teklif toplarken dikkat edilmesi gereken teknik noktaları somut örneklerle açıklayacağız.

Mobil uygulama geliştirme maliyeti neden değişken?

Bir mobil projenin maliyetini belirleyen ilk unsur, kapsamın ne kadar net olduğudur. Örneğin 8 ekranlı bir müşteri sadakat uygulaması ile 8 ekranlı bir saha operasyon uygulaması kağıt üzerinde benzer görünebilir. Ancak ikincisinde çevrimdışı çalışma, konum doğrulama, fotoğraf yükleme, rol bazlı erişim ve merkez sistemle senkronizasyon gerekebilir. Aynı ekran sayısı, çok farklı bir mühendislik yükü doğurur.

Maliyeti etkileyen başlıca teknik alanlar şunlardır:

  • Platform seçimi: Sadece iOS, sadece Android ya da her ikisi
  • Native veya cross-platform yaklaşımı
  • Backend ihtiyacı: Hazır servis mi, özel API mi
  • Veri modeli ve kullanıcı rolleri
  • Harici sistem entegrasyonları
  • Yasal ve güvenlik gereksinimleri
  • Yayın sonrası destek süresi

Birçok projede asıl sapma, ilk tahminde görünmeyen iş kurallarından kaynaklanır. “Sipariş oluştur” ifadesi ilk bakışta basit durur. Ancak siparişin kampanya kontrolü, stok doğrulaması, fiyat listesi seçimi, bayi yetkisi, iade akışı ve ERP’ye aktarımı devreye girdiğinde tablo büyür. Bu nedenle maliyet, yalnızca arayüz tasarımından ibaret düşünülmemelidir.

Kapsam maliyeti en çok nasıl etkiler?

Kapsam, bütçenin omurgasıdır. İyi tanımlanmış bir MVP ile 12 haftada yayına çıkabilecek bir ürün, belirsiz gereksinimler nedeniyle 24 haftaya uzayabilir. Süre uzadıkça sadece geliştirme maliyeti artmaz; analiz, test, proje yönetimi ve revizyon yükü de yükselir.

MVP ile tam kapsam arasındaki fark

KOBİ’ler için çoğu zaman en sağlıklı yöntem, ilk fazda çekirdek akışları üretime almaktır. Örneğin bir servis randevu uygulamasında ilk sürüm şu işlevlerle başlayabilir: kullanıcı girişi, takvim seçimi, randevu oluşturma, bildirim ve temel yönetim paneli. İkinci fazda ise kampanya, puan sistemi, çoklu lokasyon ve çağrı merkezi ekranları eklenir.

Kurumsal firmalarda da MVP kavramı vardır, ancak beklenti farklıdır. İlk sürüm bile çoğu zaman kurum içi güvenlik politikalarına, loglama standartlarına ve entegrasyon kurallarına uymak zorundadır. Bu da “minimum” kapsamın gerçekte daha geniş olmasına neden olur.

Ekran sayısı tek başına yeterli ölçü değildir

20 ekranlı bir uygulama her zaman 10 ekranlı bir uygulamadan daha pahalı olmaz. Çünkü bazı ekranlar statiktir, bazıları ise yoğun iş mantığı taşır. Örneğin bir raporlama ekranında filtreleme, yetki bazlı veri görünürlüğü, dışa aktarma ve performans optimizasyonu varsa geliştirme süresi ciddi biçimde artar. Tek bir ekran için 2 gün de gerekebilir, 8 gün de.

Teklif isterken şu detayların yazılması faydalıdır:

  • Kullanıcı tipi sayısı: örneğin müşteri, bayi, yönetici, saha personeli
  • Ana iş akışları: en az 5-10 temel senaryo
  • Çevrimdışı kullanım ihtiyacı
  • Bildirim, ödeme, konum, kamera gibi cihaz özellikleri
  • Yönetim paneli gerekip gerekmediği

Entegrasyonlar bütçeyi neden büyütür?

Mobil uygulama çoğu zaman tek başına yaşamaz. CRM, ERP, e-fatura, ödeme altyapısı, kargo sistemi, kimlik doğrulama servisi veya kurumsal veri ambarı ile iletişim kurar. Her entegrasyon yalnızca bir bağlantıdan ibaret değildir; veri eşleme, hata yönetimi, zamanlama, güvenlik ve versiyon uyumu gerektirir.

Örneğin bir B2B sipariş uygulamasında SAP ya da Logo benzeri bir ERP ile entegrasyon yapılacaksa şu sorular gündeme gelir: Stok anlık mı çekilecek, 15 dakikada bir mi senkron olacak? Fiyat listeleri hangi müşteri grubuna göre hesaplanacak? Hatalı sipariş kaydı geri alınabilecek mi? Bu kararların tamamı iş yükünü etkiler.

API hazırsa iş biter mi?

Hayır. Dokümante edilmiş bir REST API olması önemli bir avantajdır, ancak tek başına yeterli değildir. Uygulamanın ihtiyaç duyduğu veri modeli ile mevcut API’nin sunduğu yapı birebir örtüşmeyebilir. Sık görülen bir senaryo şudur: mobil ekip 12 uç nokta bekler, mevcut sistem 4 genel uç nokta sunar. Kalan veri işleme, filtreleme ve hata mantığı için ek bir backend katmanı gerekir.

Entegrasyon maliyetini artıran somut başlıklar:

  • Eski sistemlerle çalışma: SOAP, FTP, CSV tabanlı aktarım
  • SSO ve kurumsal kimlik yönetimi
  • Webhook, kuyruk yapıları, asenkron işlem akışları
  • Ortam ayrımı: test, staging, production
  • API limitleri ve performans darboğazları

KOBİ ölçeğinde tek ödeme altyapısı ve temel muhasebe entegrasyonu yeterli olabilir. Kurumsal tarafta ise 4-6 ayrı iç sistemle veri alışverişi oldukça yaygındır. Teklifte her entegrasyonun bağımsız bir iş paketi olarak ele alınması daha sağlıklıdır.

Tasarım, kullanıcı deneyimi ve platform seçimi maliyeti nasıl etkiler?

Tasarım kalemi bazen küçümsenir, ardından proje ortasında en fazla revizyon alan başlıklardan biri haline gelir. Hazır tasarım sistemleri kullanılarak geliştirilen sade bir uygulama ile sıfırdan marka dili oluşturulan, mikro etkileşimler içeren bir uygulama arasında ciddi efor farkı vardır.

Platform tarafında üç ana yaklaşım öne çıkar: sadece iOS, sadece Android veya iki platform birden. Bunun yanında teknoloji kararı da vardır: native ya da cross-platform. React Native ve Flutter gibi seçenekler belirli senaryolarda verimli olabilir. Yine de yoğun cihaz entegrasyonu, yüksek performans gereksinimi veya platforma özel deneyim beklentisi varsa native geliştirme tercih edilebilir.

Native mi cross-platform mu?

Tek bir doğru yoktur. İç kullanım odaklı, iş akışı ağırlıklı bir KOBİ uygulamasında cross-platform yaklaşım zaman ve bütçe avantajı sunabilir. Buna karşılık banka, sigorta, üretim veya saha operasyonu gibi kritik senaryolarda platform bazlı optimizasyon ve güvenilirlik daha fazla öne çıkabilir.

Maliyeti etkileyen örnekler nettir:

  • Push bildirim kurulumları ve cihaz testi
  • Kamera, Bluetooth, barkod, NFC kullanımı
  • Erişilebilirlik gereksinimleri
  • Tablet uyumu ve farklı ekran kırılımları

Burada önemli olan, teknoloji modasına göre karar vermemektir. İş gereksinimi, ekip yetkinliği ve bakım planı birlikte değerlendirilmelidir.

Bakım ve operasyon giderleri neden baştan planlanmalı?

Mobil uygulama yayına alındığında maliyet sona ermez. Aslında yeni bir faz başlar. İşletim sistemi güncellemeleri, güvenlik yamaları, mağaza politikaları, performans izleme, hata düzeltmeleri ve küçük iyileştirmeler düzenli bütçe gerektirir. Uygulama mağazalarındaki değişiklikler bile yılda birkaç kez teknik güncelleme ihtiyacı doğurabilir.

Bakım bütçesi planlanırken tek bir kalem yerine alt başlıklarla ilerlemek daha gerçekçidir:

  • Düzeltici bakım: hata çözümü, çökme kayıtlarının analizi
  • Uyum güncellemeleri: iOS/Android sürüm değişimleri
  • Bulut maliyetleri: API, veritabanı, dosya depolama, log
  • İzleme araçları: hata takibi, performans gözlemi
  • Küçük geliştirmeler: kullanıcı geri bildirimleri sonrası iyileştirme

Örneğin 5.000 aktif kullanıcısı olan bir uygulama ile 50.000 aktif kullanıcısı olan bir uygulamanın operasyon yükü aynı olmaz. API yanıt süreleri, veritabanı optimizasyonu ve log hacmi doğrudan değişir. Kurumsal firmalarda ayrıca SLA beklentisi, yedekleme politikası ve erişim kayıtlarının saklanma süresi de maliyeti artırabilir.

KOBİ ve kurumsal firmalar bütçeyi nasıl farklı planlamalı?

KOBİ’lerin önceliği genellikle yatırımın geri dönüşünü erken görmek olur. Bu nedenle modüler kapsam, kısa fazlar ve ölçülebilir hedefler daha uygundur. İlk 90 günde hangi iş yükü azalacak, kaç manuel adım ortadan kalkacak, hangi kanal dijitalleşecek gibi sorular önem taşır.

Kurumsal yapılarda ise uygulama tek başına bir ürün değil, dijital ekosistemin bir parçasıdır. Bütçede yalnızca geliştirme değil; bilgi güvenliği incelemeleri, mimari onaylar, test ortamları, kullanıcı kabul süreçleri ve tedarikçi koordinasyonu da hesaba katılmalıdır. Bir projede 6 haftalık entegrasyon geliştirmesi, kurum içi onay süreçleri nedeniyle 10 haftaya yayılabilir.

Örnek bütçe yaklaşımı

Fiyat vermeden de bir çerçeve kurulabilir. KOBİ tarafında bütçe genellikle şu sırayla ele alınmalıdır: analiz ve kapsam netleştirme, MVP geliştirme, temel entegrasyon, yayın, 3-6 aylık bakım. Kurumsal tarafta ise buna ek olarak güvenlik testleri, yük testi, rol matrisi, denetim kayıtları, SSO, çoklu ortam yönetimi ve kapsamlı kabul testleri eklenir.

Sağlıklı teklif karşılaştırması yapabilmek için her tedarikçiden benzer bir kırılım istemek gerekir. Aksi halde bir teklif yalnızca mobil arayüzü kapsarken, diğer teklif backend, panel ve 6 aylık bakımı da içeriyor olabilir. Bu nedenle en ucuz teklif her zaman en ekonomik teklif değildir.

Teklif alırken hangi sorular sorulmalı?

İyi bir bütçe planı, doğru sorularla başlar. Teknik netlik arttıkça sonradan çıkacak ek iş kalemi azalır. Aşağıdaki sorular karar sürecini daha belirgin hale getirir:

  • Proje kapsamında backend ve yönetim paneli var mı?
  • UI/UX tasarım kaç revizyon turu içeriyor?
  • Test kapsamı nedir: manuel test, otomasyon, cihaz çeşitliliği?
  • Entegrasyonlar teklif içine dahil mi, varsayım olarak mı yazıldı?
  • Yayın sonrası destek süresi kaç ay?
  • Kaynak kod, dokümantasyon ve teslim modeli nasıl olacak?

İmkân varsa 1-2 haftalık bir keşif çalışması yapılması çok değerlidir. Bu aşamada kullanıcı senaryoları yazılır, ekran ağacı çıkarılır, entegrasyon riskleri belirlenir ve öncelik matrisi oluşturulur. Erken aşamada harcanan bu süre, proje ortasında yaşanacak bütçe sapmasını ciddi ölçüde azaltır.

Özetle mobil uygulama geliştirme maliyeti; kapsamın derinliği, entegrasyon seviyesi, platform kararı, güvenlik beklentisi ve bakım yaklaşımıyla şekillenir. KOBİ’ler için kontrollü ve fazlı ilerlemek çoğu zaman en doğru yöntemdir. Kurumsal firmalarda ise mimari ve operasyonel gereksinimler, en az kullanıcı arayüzü kadar belirleyicidir. Bütçe planı yapılırken yalnızca ilk sürüm değil, uygulamanın 12 ay sonraki işletim yükü de hesaba katılmalıdır. Net kapsam, şeffaf iş kırılımı ve gerçekçi bakım planı; sağlıklı yatırım kararının temelini oluşturur.