Mobil uygulama yaptırma maliyeti, tek satırlık bir fiyatla açıklanabilecek bir konu değildir. Aynı iş hedefi için geliştirilen iki uygulama arasında bile ciddi bütçe farkları oluşabilir. Çünkü maliyeti belirleyen tek unsur ekran sayısı değildir; iş kuralları, kullanıcı rolleri, entegrasyon yoğunluğu, güvenlik gereksinimleri, offline çalışma ihtiyacı, bildirim altyapısı ve uygulamanın kaç platformda yayınlanacağı toplam eforu doğrudan etkiler.
Bir işletme için başlangıçta basit görünen bir mobil proje, arka planda ERP verisi çeken, saha ekiplerinin çevrimdışı kayıt tuttuğu, bayi sipariş akışını yöneten bir sisteme dönüşebilir. Bu aşamada fiyat, “uygulama yapılacak mı?” sorusundan çok “hangi süreç dijitalleşecek, hangi sistemlerle konuşacak, kaç kullanıcı tipi olacak?” sorularına bağlı hale gelir. Sağlıklı bir bütçe çalışması için önce kapsamın netleşmesi gerekir.
Bu rehberde, mobil uygulama yaptırma maliyeti üzerinde en çok etkisi olan başlıkları teknik ama anlaşılır bir dille ele alacağız: özellik seti, entegrasyonlar, iOS ve Android platform seçimi, tasarım yaklaşımı, test kapsamı, bakım giderleri ve teklif alırken dikkat edilmesi gereken noktalar.
Mobil uygulama maliyetini belirleyen ana çerçeve nedir?
Bir mobil proje için maliyet hesabı çoğu zaman 4 ana blok üzerinden yapılır: ürün kapsamı, teknik mimari, entegrasyon gereksinimi ve teslim sonrası operasyon. Örneğin yalnızca 8-10 ekrandan oluşan bir saha form uygulaması ile 25 ekranlı ama çok az iş kuralı içeren bir katalog uygulaması aynı bütçede olmayabilir. Ekran sayısı önemlidir, ancak tek başına yeterli bir ölçüt değildir.
Kurumsal projelerde analiz aşaması genellikle 1 ila 3 hafta sürer. Bu süreçte kullanıcı akışları, yetkilendirme kuralları, veri modeli ve dış sistem bağlantıları netleştirilir. Bu çalışma yapılmadan verilen düşük fiyatlar, çoğu zaman sonradan değişiklik taleplerine, takvim uzamasına ya da kalite kaybına yol açar.
Maliyet hesaplamasında öne çıkan kalemler
- İş analizi ve teknik keşif
- UX/UI tasarımı ve prototipleme
- Mobil uygulama geliştirme
- Backend, yönetim paneli ve API katmanı
- ERP, CRM, ödeme, kargo veya kimlik doğrulama entegrasyonları
- Test, yayınlama ve bakım süreçleri
Pratikte MVP düzeyindeki bir iş uygulaması ile tam kapsamlı bir kurumsal mobil platform arasında aylar düzeyinde fark oluşabilir. 6 haftada çıkabilecek bir ilk sürüm ile 6 aylık bir dijital dönüşüm uygulamasını aynı fiyat bandında değerlendirmemek gerekir.
Özellik seti genişledikçe neden maliyet artar?
Uygulamanın sahip olduğu her özellik, yalnızca arayüzde görünen bir butondan ibaret değildir. Her modül; veri modeli, hata senaryosu, yetki kontrolü, test senaryosu ve bazen sunucu tarafı geliştirme gerektirir. Bu nedenle giriş ekranı, profil alanı, sipariş oluşturma, raporlama, push bildirim ve offline kayıt gibi başlıkların her biri ayrı bir efor kalemidir.
Örnek bir senaryo düşünelim. İlk talep yalnızca “müşteri ziyaretlerini kaydeden uygulama” olabilir. Ancak proje detaylandıkça konum doğrulama, fotoğraf yükleme, QR kod okutma, ziyaret planı, rota takibi, çevrimdışı veri saklama ve merkezi raporlama gibi ihtiyaçlar da eklenebilir. İlk bakışta tek uygulama gibi görünse de kapsam 2 katına çıkabilir.
Maliyeti hızla yükselten özellik örnekleri
- Offline çalışma: Yerel veritabanı, senkronizasyon kuralları ve çakışma yönetimi ister.
- Gerçek zamanlı yapı: Anlık stok, mesajlaşma veya canlı görev akışları için ek altyapı gerekir.
- Rol bazlı yetkilendirme: Yönetici, bayi, saha personeli, müşteri gibi her rol farklı ekran ve kural üretir.
- Medya işleme: Fotoğraf sıkıştırma, belge yükleme, video veya barkod işlemleri test yükünü artırır.
- Harita ve konum: Rota, geofence veya canlı lokasyon takibi pil tüketimi ve izin yönetimi açısından dikkat gerektirir.
Basit bir hesapla, yalnızca offline kayıt ve sonradan senkronizasyon eklendiğinde geliştirme ve test eforu birçok projede hissedilir biçimde artar. Çünkü artık ağ yokken, ağ geri geldiğinde ve aynı veriye iki cihazdan dokunulduğunda ne olacağı da tasarlanmalıdır.
Entegrasyonlar fiyatı neden tek başına değiştirebilir?
Mobil uygulama çoğu zaman tek başına çalışan bir ürün değildir. İşletmeler genellikle mevcut ERP, CRM, e-fatura, ödeme sistemi, kargo altyapısı, LDAP/SSO, BI aracı ya da özel bir üretim yazılımı ile bağlantı ister. Maliyeti büyüten nokta da burada başlar: entegrasyon yalnızca veri çekmekten ibaret değildir; güvenlik, hız, hata toleransı ve veri eşleştirme de gerekir.
Örneğin bir B2B sipariş uygulaması, stok ve fiyat bilgisini ERP’den alıyorsa veri güncelliği kritik hale gelir. Dakikada 1 kez senkron çalışan bir yapı bazı sektörlerde yeterli olurken, anlık fiyat değişen operasyonlarda bu model yetersiz kalabilir. Senkron ya da asenkron mimari tercihi bile eforu değiştirebilir.
Entegrasyon maliyetini etkileyen teknik sorular
- Hazır REST API var mı, yoksa eski sistem için özel servis mi yazılacak?
- Kimlik doğrulama OAuth 2.0, SAML, JWT veya kurum içi yöntemle mi yapılacak?
- Veri tek yönlü mü akacak, çift yönlü mü senkron olacak?
- Hata durumunda yeniden deneme ve loglama mekanizması isteniyor mu?
Örnek bir API çağrısı bile işin derinliğini gösterir:
GET /api/orders?customerId=481&status=pending
Authorization: Bearer {token}Bu satır basit görünebilir. Oysa arka planda token yönetimi, yetki kontrolü, zaman aşımı, hız limiti, versiyonlama ve veri dönüşümü bulunur. Özellikle eski ERP sistemlerinde dokümantasyon eksikse analiz süresi uzar. Teklif alırken “entegrasyon dahil” ifadesinin hangi sistemler ve hangi senaryolar için geçerli olduğu mutlaka yazılı olmalıdır.
iOS, Android veya çapraz platform seçimi bütçeyi nasıl etkiler?
Platform seçimi, mobil uygulama yaptırma maliyeti üzerinde en görünür başlıklardan biridir. Yalnızca iOS için geliştirilen bir uygulama ile hem iOS hem Android hedefleyen bir uygulamanın bütçesi doğal olarak aynı olmaz. Çünkü test matrisi genişler, cihaz çeşitliliği artar ve yayın süreçleri çoğalır.
Burada üç temel yaklaşım bulunur: native iOS, native Android ve çapraz platform geliştirme. React Native veya Flutter gibi çerçeveler birçok projede ortak kod tabanı avantajı sağlayabilir. Ancak bu, her proje için otomatik olarak tasarruf anlamına gelmez. Kamera, Bluetooth, arka plan servisleri, cihaz entegrasyonları veya yüksek performanslı özel modüller gerektiğinde native geliştirme ihtiyacı doğabilir.
Hangi senaryoda hangi yaklaşım mantıklıdır?
- Tek platform yeterliyse: İç kullanım uygulamalarında ilk sürüm daha kontrollü bir bütçeyle çıkabilir.
- Her iki platform şartsa: Pazar kapsaması artar, buna paralel olarak test ve bakım yükü de yükselir.
- Çapraz platform uygunsa: Ortak iş akışları olan kurumsal uygulamalarda geliştirme süresi optimize edilebilir.
Örneğin depo personeli için yalnızca kuruma ait Android el terminallerinde çalışacak bir uygulama ile App Store ve Google Play’de yayınlanacak bir müşteri uygulaması arasında kapsam farkı vardır. İlkinde cihaz standardı avantaj sağlar. İkincisinde ise farklı ekran boyutları, sürümler ve mağaza gereksinimleri devreye girer.
Tasarım, kullanıcı deneyimi ve test neden bütçenin parçasıdır?
Kurumsal projelerde bazen tasarımın yalnızca “güzel görünüm” olduğu düşünülür. Oysa iyi bir UX çalışması, saha personelinin 30 saniyede tamamlayacağı bir işlemi 2 dakikaya çıkarmamayı hedefler. Özellikle sık kullanılan ekranlarda tıklama sayısı, form sırası, hata mesajları ve boş durumlar doğrudan verimlilik üzerinde etkili olur.
Örneğin 12 alanlı bir formda otomatik tamamlama, varsayılan değerler ve kamera ile belge okuma eklenmesi kullanıcı süresini düşürebilir. Bu iyileştirmeler tasarım ve geliştirme eforu gerektirir; ancak operasyonel geri dönüşü yüksek olabilir.
Test maliyet oluşturur, ama eksikliği daha pahalıya mal olur
Mobil test yalnızca “açıldı mı?” kontrolünden ibaret değildir. En azından kritik akışlar için farklı cihaz, farklı ağ koşulu ve izin senaryoları denenmelidir. Örneğin Android 12 ve üzeri izin davranışları ile eski sürümler birebir aynı değildir. iOS tarafında da yayın öncesi mağaza kuralları dikkat gerektirir.
- Fonksiyonel test
- Cihaz ve ekran uyumluluğu
- Performans ve ağ kesintisi senaryoları
- Güvenlik kontrolleri
- Yayın öncesi son kullanıcı kabul testi
Özellikle login, ödeme, sipariş, veri gönderimi ve offline senkron gibi akışlar için test senaryoları yazılmadan ilerlemek, uygulama canlıya çıktıktan sonra maliyeti artırır.
Gizli kalemler: yayınlama, bakım ve operasyonel giderler
Birçok işletme ilk teklif aşamasında yalnızca geliştirme bedeline odaklanır. Oysa uygulama yayınlandıktan sonra da maliyet oluşturan kalemler vardır. Bunlar her projede büyük olmayabilir; ancak planlanmadığında sürpriz yaratır.
Sık atlanan gider başlıkları
- Uygulama mağazası hesapları ve yayın süreçleri
- Sunucu, veritabanı, dosya depolama ve loglama maliyetleri
- Push bildirim servisleri ve SMS/OTP kullanımı
- Bakım, hata düzeltme ve sürüm güncellemeleri
- Yeni OS sürümlerine uyumluluk çalışmaları
Bulut altyapısında maliyet, kullanıcı sayısı ve veri trafiğine göre değişir. 500 aktif kullanıcı ile 20.000 aktif kullanıcının operasyon ihtiyacı aynı değildir. Ayrıca KVKK kapsamında veri işleme, erişim kontrolü ve log saklama politikaları da mimari kararları etkileyebilir.
Sağlıklı teklif almak için kapsam nasıl yazılmalı?
Fiyatların neden dağıldığını anlamanın en pratik yolu, aynı kapsamla birden fazla teklif toplamaktır. Ancak kapsam metni zayıfsa gelen rakamları karşılaştırmak mümkün olmaz. “Bize bir mobil uygulama lazım” ifadesi, teknik açıdan teklif üretmek için yeterli değildir.
Daha doğru bir yaklaşım şudur: hedef kullanıcıyı, ana iş akışını, entegrasyon listesini, kaç platform istendiğini, yönetim paneli ihtiyacını ve ilk sürümde mutlaka bulunması gereken modülleri net biçimde yazın. Örneğin:
- 2 kullanıcı rolü: bayi ve yönetici
- Platform: iOS + Android
- Entegrasyon: mevcut ERP stok ve sipariş servisleri
- Temel modüller: login, ürün listeleme, sipariş oluşturma, sipariş geçmişi
- Opsiyonel modüller: push bildirim, kampanya alanı, offline katalog
Bu format, teklif veren ekibin varsayımlarla ilerlemesini azaltır. Proje sonunda kapsam kaymasının önüne geçer. Ayrıca MVP yaklaşımıyla ilk 8-10 haftada hangi modüllerin canlıya alınacağı daha net planlanabilir.
Sonuç: tek fiyat değil, doğru kapsam belirleyicidir
Mobil uygulama yaptırma maliyeti; özelliklerin sayısı kadar, bu özelliklerin iş kurallarıyla ve mevcut sistemlerle nasıl birleştiğine göre de değişir. Entegrasyon yoğunluğu, platform tercihi, offline çalışma ihtiyacı, güvenlik seviyesi, test kapsamı ve bakım yaklaşımı toplam bütçeyi belirler. Sağlıklı karar verebilmek için önce iş hedefini, ardından ilk sürüm kapsamını netleştirmek gerekir.
İşletmeler için en doğru yaklaşım, mümkün olan en ucuz teklifi aramak değil; kapsamı açık, teknik varsayımları yazılı, bakım ve entegrasyon sınırları net bir çözüm ortağıyla ilerlemektir. İyi kurgulanmış bir mobil proje, yalnızca bir uygulama üretmez; operasyonu hızlandırır, hata oranını azaltır ve veri görünürlüğünü artırır.
