Mobil uygulama geliştirme fiyatları, kapsam netleşmeden sorumlu bir şekilde tek bir rakamla söylenemez; aynı "uygulama" tanımının arkasında birkaç ekranlık bir tanıtım uygulaması da, ödeme alan, çevrimdışı çalışan ve yönetim paneli olan bir platform da olabilir. Maliyeti belirleyen şey ekran sayısından çok platform seçimi, özellik kapsamı, backend ve entegrasyonlar, mağaza süreci ve yayından sonraki bakımdır. Güvenilir bir tahmin için bu kalemleri yazılı bir kapsama dökmek ve teklifi o kapsam üzerinden istemek gerekir.
Bu yazıda "mobil uygulama yaptırmak ne kadar tutar" sorusunun neden rakamla değil kapsamla cevaplandığını, maliyeti hangi kararların büyüttüğünü, teklif istemeden önce neleri hazırlamanız gerektiğini ve bütçe planlarken en sık unutulan gizli kalemleri anlatıyoruz.
Mobil uygulama maliyeti neden tek bir rakamla söylenemez?
İnternette gördüğünüz hazır fiyat aralıkları genellikle kapsamı tanımlanmamış bir "ortalama uygulama" varsayar. Oysa iki uygulama aynı sayıda ekrana sahip olup tamamen farklı iş yükleri taşıyabilir: biri yalnızca içerik gösterir, diğeri kullanıcı rollerine göre yetki yönetir, ödeme alır, konum takibi yapar ve bağlantı yokken veri kaydeder. Kapsam belli olmadan verilen bir rakam ya gereksiz yüksek bir güvenlik payı içerir ya da projenin ortasında "bu kapsam dışıydı" konuşmasına dönüşür.
Mobilde ayrıca web projelerinde olmayan bir maliyet katmanı vardır: dağıtım. Yayınladığınız sürüm kullanıcının telefonunda aylarca kalır, geri alınamaz ve her güncelleme mağaza incelemesinden geçer. Bu yüzden mobil projenin asıl maliyeti çoğu zaman ekranlarda değil; eski sürümlerle uyumlu bir backend, zorunlu güncelleme mekanizması ve yayın sonrası bakım gibi görünmeyen kalemlerdedir.
Mobil uygulama maliyetini hangi faktörler belirler?
Aşağıdaki tablo, bir teklifin büyüklüğünü en çok etkileyen kararları, bunların maliyeti neden değiştirdiğini ve kontrol altında tutmak için ne yapılabileceğini özetliyor.
| Faktör | Maliyeti neden değiştirir? | Nasıl kontrol altında tutulur? |
|---|---|---|
| Platform (iOS, Android, ikisi birden) | Her platform ayrı test, ayrı mağaza süreci ve ayrı cihaz çeşitliliği demektir. | Hedef kitlenizin hangi platformda yoğunlaştığını baştan netleştirin; gerekiyorsa tek kod tabanlı bir yaklaşım seçin. |
| Native veya cross-platform (Flutter, React Native) | Native geliştirmede iki ayrı kod tabanı ve genellikle iki ayrı uzmanlık gerekir. | Cihaz özelliklerine derin erişim gerekmiyorsa tek kod tabanıyla iki platformu birlikte çıkarın. |
| Özellik kapsamı, ekran ve rol sayısı | Her yeni rol (müşteri, kurye, yönetici gibi) kendi akışını, yetkisini ve test senaryosunu getirir. | İlk sürüm için olmazsa olmaz akışları ayırın, geri kalanı yol haritasına yazın. |
| Backend ve yönetim paneli | Veriyi yöneten sunucu, API ve admin paneli çoğu zaman uygulamanın kendisi kadar iş çıkarır. | Panelde gerçekten günlük kullanılacak işlemleri belirleyin; hazır altyapı kullanılabilecek yerleri değerlendirin. |
| Entegrasyonlar (ödeme, harita, kimlik doğrulama, üçüncü taraf API'ler) | Her entegrasyon dış bir sistemin kuralına, test ortamına ve hata senaryosuna bağlıdır. | Entegrasyonları önceliklendirin, dokümantasyonu ve test erişimi olan servisleri seçin. |
| Tasarım derinliği | Özel animasyonlar, özgün bileşenler ve markaya özel etkileşimler tasarım ve geliştirme süresini artırır. | Platformun standart bileşenlerinden başlayın, özel tasarımı değer ürettiği ekranlara saklayın. |
| Çevrimdışı çalışma | Yerel veritabanı, senkronizasyon katmanı ve çakışma kuralları gerektirir; veri modelini baştan değiştirir. | Hangi ekranların bağlantısız açılacağını ve çakışmada hangi tarafın kazanacağını kapsamda yazılı karara bağlayın. |
| Mağaza gönderimi ve inceleme | Red gerekçeleri (gizlilik beyanı, hesap silme yolu, test hesabı) her seferinde yeni bir inceleme turu demektir. | Gönderimden önce bir kontrol listesiyle bilinen red nedenlerini kapatın. |
| Güvenlik ve KVKK | Kişisel veri işleyen uygulamalar açık rıza, veri minimizasyonu, şifreleme ve erişim kaydı gerektirir. | Hangi kişisel veriyi neden topladığınızı baştan listeleyin; gerekmeyen veriyi hiç toplamayın. |
| Yayın sonrası bakım ve işletim sistemi güncellemeleri | Kod değişmese bile yıllık işletim sistemi sürümleri, mağaza kuralları ve sertifikalar uygulamayı etkiler. | Bakımı proje bütçesinin ayrı bir kalemi olarak planlayın, sürekli gelen bir iş olarak görün. |
| Zorunlu güncelleme ve sürüm uyumluluğu | Sahadaki eski sürümlerle uyumlu kalmak her backend değişikliğinde ek test demektir. | Minimum desteklenen sürüm mekanizmasını ilk sürüme koyun, desteklenen sürüm aralığını yazılı bir politikaya bağlayın. |
| Ekip ve sözleşme modeli | Sabit kapsamlı işler risk payı içerir; zaman ve malzeme (T&M) modelinde maliyet yapılan işe göre oluşur. | Kapsamı net işlerde sabit kapsam, belirsizliği yüksek işlerde kısa sprintlerle T&M tercih edin. |
iOS mu, Android mi, ikisi birden mi?
Platform kararı bütçeyi doğrudan etkiler, çünkü her platform kendi test cihazlarını, kendi mağaza sürecini ve kendi davranış farklarını getirir. Kullanıcılarınızın büyük çoğunluğu tek bir platformdaysa ilk sürümü oradan başlatmak mantıklı olabilir. Ancak iki platformu birlikte hedefliyorsanız, iki ayrı native uygulama yerine tek kod tabanlı bir yaklaşım toplam maliyeti ve özellikle bakım yükünü belirgin şekilde düşürür.
Native mi, Flutter veya React Native mi?
Flutter ve React Native, iOS ve Android'i tek bir kod tabanından üretir; Swift ve Kotlin ise her platformu ayrı yazar. Karar üç soruyla verilir: uygulama cihaz yeteneklerine (kamera, Bluetooth, arka planda konum) ne kadar derin erişiyor, arayüzde platforma özgü his ne kadar önemli ve teslimden sonra uygulamayı kim bakımını yapacak. Kamera, QR okuma, bildirim ve form tabanlı akışlar cross-platform çözümlerde rahatça çalışır. Bu kararın ayrıntılarını Flutter ile mobil uygulama geliştirmenin ne zaman doğru seçim olduğunu anlatan yazımızda ele alıyoruz.
Backend ve yönetim paneli neden bütçenin büyük kısmını oluşturabilir?
Kullanıcının gördüğü ekranlar buzdağının görünen kısmıdır. Siparişleri, kullanıcıları, içerikleri ve bildirimleri yöneten bir sunucu, bu sunucuya bağlanan bir API ve operasyon ekibinizin kullandığı bir yönetim paneli çoğu projede ayrı bir iş kalemidir. Mobilde API bir sözleşmedir: karşı tarafta güncelleyemediğiniz eski istemciler vardır, bu yüzden alan silmek veya yeniden adlandırmak yerine yeni alan eklemek ve eskisini bir süre beslemek gerekir. Bu disiplin baştan kurulmazsa sonradan daha yüksek bir bedelle kurulur.
Çevrimdışı çalışma sonradan eklenebilir mi?
Pratikte hayır, en azından ucuza değil. Çevrimdışı destek veri modelini baştan değiştiren bir karardır: yerel veritabanı, senkronizasyon katmanı ve aynı kaydı iki cihaz değiştirdiğinde hangi tarafın kazanacağına dair yazılı bir kural gerekir. Depo, bodrum kat veya araç içinde kullanılan saha uygulamalarında bu kalem vazgeçilmezdir; ofis içinde kullanılan bir uygulamada ise gereksiz bir karmaşıklık olabilir. Karar varsayılana göre değil, ihtiyaca göre verilmelidir.
Mobil uygulama bütçesinde en sık unutulan gizli maliyetler nelerdir?
Teklifler genellikle geliştirme işine odaklanır. Uygulamanın yaşaması için gereken ama çoğu zaman bütçeye yazılmayan kalemler şunlardır:
- Mağaza hesapları: Apple Developer Program yıllık üyelik ücretine, Google Play geliştirici hesabı tek seferlik kayıt ücretine tabidir. Hesaplar şirketinizin adına açılmalıdır, çünkü mağaza sayfası, yorumlar ve indirme geçmişi hesaba bağlıdır.
- Sunucu ve altyapı: Backend, veritabanı, dosya depolama ve yedekleme kullanıcı sayısı arttıkça büyüyen düzenli bir gider kalemidir.
- Bildirim, e-posta ve SMS servisleri: Doğrulama kodları, işlem bildirimleri ve pazarlama mesajları çoğunlukla kullanım bazlı ücretlendirilen üçüncü taraf servislerden geçer.
- Harita, ödeme ve diğer üçüncü taraf API'ler: Belirli kullanım eşiğinden sonra ücretlendirme başlayan ya da işlem başına komisyon alan servisler bütçeyi zamanla değiştirir.
- Analitik ve hata takibi: Sahadaki hataları uzaktan görmek için crash raporlama ve kullanım analitiği gerekir; kullanıcılar hata bildirmez, uygulamayı siler.
- Bakım ve işletim sistemi güncellemeleri: Her yıl gelen büyük iOS ve Android sürümleri, mağazaların hedef SDK ve gizlilik kuralları, kütüphane güncellemeleri düzenli iş çıkarır.
- İmzalama sertifikaları ve anahtarlar: Süresi dolan sertifika uygulamayı durdurmaz ama yeni sürüm yayınlayamazsınız; kaybolan bir imzalama anahtarı aynı mağaza sayfasının güncellenmesini imkansız hale getirir.
- Mağaza görselleri ve ASO: Ekran görüntüleri, açıklamalar ve anahtar kelimeler teslim paketinin parçasıdır; dil sayısı arttıkça bu iş de büyür.
Mobil uygulama maliyeti nasıl düşürülür?
Maliyeti düşürmenin en etkili yolu fiyat pazarlığı değil, kapsam kararıdır. Talebi henüz doğrulanmamış bir fikir için tam kapsamlı bir uygulama yaptırmak, en pahalı riski en başta almak demektir. Bunun yerine önce doğrulanması gereken soruyu belirleyip o soruyu cevaplayacak en küçük ürünü çıkarmak, hem ilk bütçeyi küçültür hem de sonraki yatırımı veriyle yönlendirir. Bu yaklaşımı MVP geliştirme hizmetimizde ve daha ayrıntılı olarak MVP geliştirme rehberimizde anlatıyoruz.
Bazı durumlarda en ucuz mobil uygulama, hiç yapılmayan mobil uygulamadır. İhtiyaç içerik göstermek, form toplamak veya rapor sunmaksa mobil uyumlu bir web uygulaması daha hızlı çıkar ve mağaza incelemesi beklemez. Uygulama yapmanın tek gerekçesi bildirimse, önce e-posta, SMS ve web push seçenekleri değerlendirilmelidir.
Sözleşme modeli de maliyetin nasıl oluşacağını belirler. Kapsamı net ve değişmesi beklenmeyen işlerde sabit kapsamlı (anahtar teslim) model bütçe öngörülebilirliği sağlar, ancak teklif belirsizlik için bir risk payı içerir. Kapsamın öğrenerek netleşeceği işlerde zaman ve malzeme (T&M) modeli, kısa sprintler ve düzenli önceliklendirme ile yapılan işe göre ödeme yapmanızı sağlar.
Teklif istemeden önce neleri hazırlamalısınız?
Aşağıdaki kontrol listesi, alacağınız tekliflerin hem daha isabetli hem de birbiriyle karşılaştırılabilir olmasını sağlar:
- Problem ve hedef: Uygulama hangi problemi, kimin için çözüyor ve başarıyı neyle ölçeceksiniz?
- Kullanıcı rolleri: Uygulamayı kimler kullanacak (müşteri, çalışan, yönetici) ve her rol neler yapabilecek?
- Temel akışlar: İlk sürümde mutlaka olması gereken üç ila beş ana akışı adım adım yazın.
- Platform tercihi: iOS, Android veya ikisi birden; varsa tablet ve web ihtiyacı.
- Entegrasyonlar: Ödeme, harita, kimlik doğrulama, ERP/CRM veya mevcut sistemlerinizle bağlantılar.
- Yönetim paneli ihtiyacı: Operasyon ekibiniz panelde günlük olarak neleri yönetecek?
- Çevrimdışı senaryolar: Uygulama bağlantısız ortamlarda kullanılacak mı?
- Kişisel veri ve KVKK: Hangi kişisel verileri topluyorsunuz, nerede saklanacak?
- Tasarım durumu: Hazır bir tasarım, kurumsal kimlik veya referans aldığınız uygulamalar var mı?
- Mevcut varlıklar: Mevcut bir backend, API, web sitesi veya yayında olan eski bir uygulama var mı?
- Zaman kısıtı: Bir lansman, kampanya veya yatırım turu gibi sabit bir tarih var mı?
- Yayın sonrası plan: Bakımı kim yapacak, iç ekibiniz mi, dış bir ekip mi?
Bu listenin tamamını doldurmanız şart değil. Ama ne kadarını netleştirirseniz, tahmin o kadar dar ve güvenilir olur; boş kalan her madde teklifte ya bir varsayım ya da bir risk payı olarak geri döner.
Detartech'te mobil proje tahminini nasıl yapıyoruz?
Detartech olarak her mobil projeye ekranlardan değil, dağıtım sorusundan başlıyoruz: altı ay sonra sahada kaç sürüm çalışıyor olacak ve sunucu bunların hepsine nasıl cevap verecek? Kapsamı yazılı hale getirirken platform ve teknoloji kararını, çevrimdışı davranışı, mağaza gönderim kontrol listesini ve minimum sürüm politikasını birlikte ele alıyoruz. Geliştirmeyi iki haftalık sprintlerle, tam şeffaflıkla, kod incelemesi ve otomatik CI/CD ile yürütüyoruz; yayından sonraki 30 günlük destek teslimatın parçası. Mağaza hesapları, imzalama anahtarları ve kaynak kod sizin adınıza kalıyor. Yaklaşımımızın ayrıntıları mobil uygulama geliştirme hizmeti sayfamızda yer alıyor.
Aklınızdaki uygulama için kapsamı birlikte netleştirmek isterseniz, hızlı teklif formunu doldurabilirsiniz. Ücretsiz ön görüşme sunuyoruz ve 24 saat içinde dönüş yapıyoruz.
Sıkça Sorulan Sorular
Mobil uygulama geliştirme fiyatları ne kadar tutar?
Kapsam tanımlanmadan sorumlu bir rakam verilemez. Fiyatı belirleyen; platform seçimi, kullanıcı rolü ve akış sayısı, backend ve yönetim paneli, entegrasyonlar, çevrimdışı çalışma, güvenlik gereksinimleri ve yayın sonrası bakımdır. Bu kalemleri yazılı bir kapsama döküp teklifi o kapsam üzerinden istemek, karşılaştırılabilir ve güvenilir bir tahmin almanın tek yoludur.
Flutter ile geliştirmek maliyeti düşürür mü?
İki platformu birlikte hedefliyorsanız çoğu iş uygulamasında düşürür, çünkü iki ayrı kod tabanı yerine tek bir kod tabanı geliştirilir ve bakımı yapılır. Ancak uygulama sürekli arka plan konumu, yoğun grafik veya platforma özgü derin sistem entegrasyonu gerektiriyorsa native geliştirme daha doğru olabilir. Karar teknik gereksinime ve teslim sonrası bakımı kimin yapacağına göre verilmelidir.
Yayından sonra bakım gerçekten zorunlu mu?
Evet. Kodu kimse değiştirmese bile işletim sistemleri her yıl büyük sürüm çıkarır, mağazalar hedef SDK ve gizlilik kurallarını günceller, imzalama sertifikalarının süresi dolar. Bakım yapılmayan bir uygulama zamanla bozulur ve bir noktada yeni sürüm yayınlama imkanı da kaybolur.
Sabit fiyat mı, zaman ve malzeme (T&M) modeli mi daha uygun?
Kapsamı net ve değişmesi beklenmeyen projelerde sabit kapsamlı model bütçe öngörülebilirliği sağlar. Gereksinimlerin kullanıcı geri bildirimiyle netleşeceği projelerde T&M modeli, kısa sprintler ve düzenli önceliklendirme ile daha esnek ve genellikle daha verimli bir yoldur.
Maliyeti düşürmek için önce MVP mi yapmalıyım?
Talebi henüz doğrulanmamış bir fikir için çoğu zaman evet. MVP daha küçük bir ürün değil, belirli bir sorunun cevabıdır: doğru kurgulandığında ilk yatırımı küçültür ve sonraki geliştirmeyi gerçek kullanıcı verisiyle yönlendirir. Mağazada yer almak tek başına talebin kanıtı değildir.
Teklif alırken hangi bilgileri paylaşmalıyım?
Çözülecek problem, kullanıcı rolleri, ilk sürümdeki ana akışlar, platform tercihi, entegrasyonlar, yönetim paneli ihtiyacı, çevrimdışı senaryolar ve kişisel veri kapsamı en önemli başlıklardır. Ne kadar çok başlık netleşirse, tahmin o kadar dar ve güvenilir olur.
