Mobil uygulama maliyeti; hedef platformlara (iOS, Android), uygulamanın konuşacağı arka uç ve entegrasyonlara, çevrimdışı çalışma ve cihaz donanımı ihtiyacına, test edilecek cihaz yelpazesine, güvenlik gereksinimlerine ve mağaza yayını sonrası zorunlu bakıma göre belirlenir. Bu yüzden sağlıklı bütçe, ekran sayısından değil, bu kalemlerin yazılı kapsamından çıkar.
Aşağıda mobil uygulamaya özgü 10 maliyet kalemini, ilk sürümden sonra her yıl ödenen giderleri ve teklifleri yan yana koymanızı sağlayan bir kontrol tablosunu anlatıyoruz. Genel yazılım bütçelemesi için yazılım projesi maliyeti yazımız daha geniş bir çerçeve sunuyor; burada yalnızca mobil tarafı büyüten ve küçülten etkenlere odaklanıyoruz.
"Kaç ekran?" sorusu neden yanıltır?
Mobil uygulama teklifi isteyen işletmelerin çoğu ilk toplantıya bir ekran listesiyle gelir: giriş, sipariş, müşteri listesi, rapor. Oysa kullanıcının gördüğü ekranlar işin yalnızca görünen yüzüdür. Aynı "sipariş ekranı", internetsiz depoda da çalışacaksa, ERP'den anlık stok çekecekse ve kamerayla barkod okuyacaksa bambaşka bir iş hâline gelir.
Mobil projeyi web projesinden ayıran üç durum vardır. Birincisi, uygulama sizin kontrol etmediğiniz çok sayıda farklı cihazda çalışır. İkincisi, yayın ve güncelleme Apple ile Google'ın kurallarına bağlıdır. Üçüncüsü, telefon sık sık bağlantı kaybeder; verinin kaybolmaması tasarım gerektirir.
Bu üç durum teklif aşamasında konuşulmazsa ya proje sırasında ek bedel olarak geri döner ya da uygulama sahada güvenilmez çalışır. İkincisi daha pahalıdır: kullanıcı bir kez güvenini kaybettiğinde kâğıda ve telefona geri döner.
Yanlış bütçelemenin gerçek maliyeti
Yazılım projelerinde bütçeyi aşan kalem çoğu zaman başta görülmeyen teknik ihtiyaçtır. Bunu düzenli ölçen kaynaklardan biri ERP projeleri üzerine yapılan araştırmalardır:
Panorama Consulting Group'un 2026 ERP Raporu'na göre katılımcıların dörtte birinden fazlası projesinin bütçeyi aştığını bildirdi; bütçe aşımının en yaygın nedeni beklenmedik ek teknoloji ihtiyacıydı.
Mobil tarafta bu "beklenmedik ihtiyaç" çoğunlukla yayından sonra gelir, çünkü mağazalar eski uygulamaları bekletmez. Google Play'in hedef API düzeyi gereksinimlerine göre 31 Ağustos 2026'dan itibaren yeni uygulamalar ve güncellemeler en az Android 16'yı (API 36) hedeflemek zorunda. Aynı tarihten itibaren en az Android 15'i (API 35) hedeflemeyen mevcut uygulamalar, daha yeni Android sürümü kullanan yeni kullanıcılara sunulmuyor.
Apple tarafında da benzer bir kural var: Apple'ın yaklaşan gereksinimler duyurusuna göre 28 Nisan 2026'dan bu yana App Store Connect'e yüklenen uygulamaların Xcode 26 ve iOS 26 SDK'sı ile derlenmesi gerekiyor. Yani bakımı bütçelenmemiş bir uygulama, küçük bir hata düzeltmesini bile yayınlayamayacak duruma düşebilir.
Bakımı içeride çözmek de her zaman kolay değil. TÜİK Girişimlerde Bilişim Teknolojileri Kullanım Araştırması 2026 verisine göre girişimlerin yalnızca %15,2'si BİT uzmanı istihdam ediyor; BİT uzmanı arayanların %31,7'si ise 2025'te işe alımda güçlük yaşadığını bildirdi. Tek bir mobil geliştiriciye bağlı kalan uygulama, o kişi ayrıldığında sahipsiz kalır.
Mobil uygulama maliyetini belirleyen 10 kalem
- Platform ve teknoloji yaklaşımı. Yalnızca Android el terminalleri mi, yoksa iOS ve Android birlikte mi? Native, cross-platform ve mobil web arasındaki seçimin ölçütlerini native mi cross-platform mu yazımızda ayrıntılı anlattık.
- Arka uç ve API. Uygulama bir veritabanıyla ve iş kurallarıyla konuşur. Mevcut ERP'nizin kullanılabilir bir API'si varsa iş küçülür; yoksa arada bir katman kurmak gerekir. Bu katmanın mantığını API entegrasyonu nedir yazısında açıkladık.
- Çevrimdışı çalışma ve eşitleme. Kaydı cihazda güvenle tutmak, bağlantı gelince göndermek ve iki kişinin aynı kaydı değiştirdiği çakışmaları çözmek, mobil projelerin en çok hafife alınan kalemidir.
- Cihaz donanımı. Kamera ile barkod okuma, NFC, Bluetooth yazıcı, arka planda konum ve biyometrik giriş her biri ayrı geliştirme ve test demektir.
- Kullanıcı rolleri ve kimlik doğrulama. Tek tip kullanıcı ile bölge, bayi ve yönetici rollerine göre değişen yetkiler arasında ciddi fark vardır; kurumsal oturum açma (SSO) da ayrı bir iş kalemidir.
- Arayüz tasarımı. Standart form ve listelerle kurulan bir iç uygulama ile markaya özel, müşteriye açık bir uygulamanın tasarım emeği aynı değildir.
- Test ve cihaz yelpazesi. Kaç farklı telefon, tablet ve işletim sistemi sürümünde denenecek? Sahada kullanılan el terminalleri listeye mutlaka girmelidir.
- Güvenlik. Cihazda saklanan verinin şifrelenmesi, oturum süresi ve kaybolan cihazda verinin korunması tasarım konusudur; müşteriye açık uygulamalarda yayından önce sızma testi yaptırmak da bütçeye girmelidir.
- Dağıtım ve yayın. Mağaza hesapları, inceleme süreçleri, gizlilik beyanları ve iç kullanım uygulamalarında kurumsal dağıtım yöntemi bu kalemin parçasıdır.
- Bakım, barındırma ve izleme. İşletim sistemi uyumu, sunucu gideri, anlık bildirim altyapısı ve hata izleme, ilk bedelden ayrı ama kalıcı giderlerdir.
Mobil uygulama fiyatları nasıl karşılaştırılır? Teklif kontrol tablosu
Teklifler geldiğinde toplam rakamdan önce kalemlere bakın. Aşağıdaki tablo her kalem için maliyeti düşük tutan ve artıran durumu, teklifte sormanız gereken soruyla birlikte gösteriyor:
| Kalem | Maliyeti düşük tutan durum | Maliyeti artıran durum | Teklifte sorun |
|---|---|---|---|
| Platform | Tek platform, şirket cihazları | iOS + Android, kişisel telefonlar | Hangi işletim sistemi sürümleri destekleniyor? |
| Arka uç | Hazır ve belgelenmiş API | API yok, ara katman gerekiyor | Arka uç teklifte ayrı kalem mi? |
| Çevrimdışı | Her zaman bağlı kullanım | Tam çevrimdışı giriş ve çakışma çözümü | Çakışan kayıtlar nasıl çözülüyor? |
| Donanım | Yalnızca kamera | NFC, Bluetooth yazıcı, arka plan konum | Hangi cihazlarla test edilecek? |
| Güvenlik | Kişisel veri yok | Kişisel veri, ödeme, müşteriye açık erişim | Güvenlik testi dahil mi? |
| Yayın | Kurumsal dağıtım, az kullanıcı | Mağaza yayını, sık sürüm | Mağaza hesapları kimin adına açılıyor? |
| Bakım | Kısa ömürlü kampanya uygulaması | Çok yıllık kurumsal kullanım | Yıllık uyum çalışmasını kim yapıyor? |
Boş kalan her hücre, projenin ortasında ek teklif olarak dönebilecek bir belirsizliktir. Kapsamı teklif istemeden önce yazıya dökmenin adımlarını yazılım ihtiyaç analizi yazımızda anlattık. Kaynak kodun ve mağaza hesaplarının kime ait olacağını ise sözleşmede netleştirin; bu konuyu yazılım sözleşmesi ve kaynak kodu yazımızda ele aldık.
Mobil uygulama bakım maliyeti: ilk sürümden sonra her yıl ne ödersiniz?
Mobil uygulamanın toplam sahip olma maliyeti ilk geliştirme bedeliyle bitmez. Yukarıda anlattığımız mağaza kuralları nedeniyle her yıl en az bir uyum çalışması yapılması gerekir: yeni işletim sistemi sürümünde test, hedef sürümün yükseltilmesi ve değişen izin kurallarına uyum.
Buna arka ucun barındırma gideri, anlık bildirim ve hata izleme servisleri, yeni cihazlara uyum ve kullanıcılardan gelen küçük geliştirme talepleri eklenir. Barındırmanın bulutta mı kendi sunucunuzda mı olacağı yıllık gideri doğrudan etkiler; bu hesabı bulut geçişi maliyeti yazımızda anlattık. Teklifte bakım kapsamının, yanıt süresinin ve bedelinin ayrı yazıldığından emin olun.
Bütçeyi küçültmenin meşru yolları
Maliyeti düşürmenin yolu kaliteden kısmak değil, kapsamı doğru sıralamaktır. Aşağıdaki adımlar çoğu projede ilk bütçeyi belirgin biçimde küçültür:
- Uygulama gerçekten gerekli mi, sorun. Yalnızca rapor görüntüleyen yöneticiler için mobil uyumlu bir web paneli çoğu zaman yeterlidir. Hazır bir paketin mobil uygulaması işinizi görüyorsa ayrı geliştirmeye gerek olmayabilir; bu ayrımın ölçütleri özel yazılım mı hazır paket mi rehberimizde.
- İlk sürümü tek iş akışıyla sınırlayın. Günlük işi doğrudan etkileyen akışı (örneğin sahada iş emri kapatma) önce yayına alın; raporlama ve ikincil özellikler ikinci aşamaya kalsın. Sahadaki form alanlarını seçmek için mobil servis formu yazımıza bakabilirsiniz.
- Pilotla başlayın. Uygulamayı önce küçük bir ekiple, gerçek sahada deneyin; hatalar ve eksik alanlar tüm şirkete yayılmadan düzelir.
- Arka ucu yeniden kullanın. Web paneli ile mobil uygulama aynı API'yi kullanırsa iş kuralları bir kez yazılır.
Mobil uygulama yalnızca iş akışı için değil, fiziksel erişim için de kullanılabilir; telefonun kart yerine geçtiği senaryoları telefonla kapı açma sistemi yazısında anlattık. Diğer yazılım satın alma rehberleri Yazılım Geliştirme yazılarımızda bir arada.
Digital Bridge'de mobil uygulama bütçesini nasıl netleştiriyoruz?
Maliyet sürprizlerinin çoğu belirsiz kapsamdan doğduğu için süreci kapsamı netleştirmek üzerine kuruyoruz:
- Keşif ve ihtiyaç analizi. Kullanıcıları, cihazları, çevrimdışı senaryoları ve bağlanılacak sistemleri birlikte çıkarıyoruz. Hazır paket satmadığımız için analiz, sizi bir ürüne yönlendirmek için değil, gerçekten neyin geliştirileceğini bulmak için yapılır.
- Yazılı teklif: kapsam, aşamalar, bedel. Mobil uygulama geliştirme teklifimizde her aşamanın kapsamı ve bedeli ayrı yer alır; kapsam dışında kalanlar da açıkça yazılır. iOS için Swift, Android için Kotlin ile native geliştiriyor, mağaza yayınını ve sürüm güncellemelerini de yürütüyoruz.
- Pilot ve aşamalı yayın. İlk sürümü küçük bir kullanıcı grubuyla sahada deniyor, geri bildirime göre sonraki aşamayı planlıyoruz. Saha ekipleri için bu kurgunun tamamını saha servis yönetimi çözümümüzde sunuyoruz.
- Arka uç ve entegrasyon aynı ekipte. Uygulamanın ERP ve diğer sistemlerinizle konuşması için API entegrasyonu katmanını ve gerekiyorsa yönetim tarafındaki özel web yazılımını aynı projede kuruyoruz.
- Güvenlik baştan tasarlanır. Cihazda saklanan veri, oturum yönetimi ve yetkilendirmeyi siber güvenlik ilkeleriyle planlıyoruz. Yayından sonra teknik destek 7/24 erişilebilir; bakım kapsamı teklifte ayrıca tanımlanır.
Sonraki adım
Teklif istemeden önce kısa bir not hazırlayın: uygulamayı kimlerin kullanacağı, hangi cihazlarda ve ortamlarda (ofis, saha, depo) çalışacağı, internet olmadan ne yapılması gerektiği ve hangi sistemlere bağlanacağı. Bu dört cevap, teklifler arasındaki farkı büyük ölçüde kapatır. Notunuzla bizimle iletişime geçin; kapsamı birlikte netleştirip aşamalara bölünmüş, yazılı bir teklif hazırlayalım.