“Basit bir uygulama istiyoruz, ne kadar tutar?” Bu soruyu soran işletmelerin aldığı cevaplar arasında bazen on kata varan fark oluyor. Bunun sebebi çoğu zaman ajansların farklı fiyat politikası değil, “basit uygulama” ifadesinin her iki tarafta farklı bir şeyi anlatması. Bu yazıda mobil uygulama yaptırma fiyatı hangi kalemlerden oluşuyor, teknoloji seçimi maliyeti nasıl etkiliyor ve yayın sonrasında hangi giderler devam ediyor, tek tek açıklıyoruz.
Kısa cevap: Mobil uygulama maliyetini; ekran sayısı ve özellik listesi, iOS ve Android için ayrı mı tek kod tabanıyla mı geliştirileceği, arka planda bir yönetim paneli ve sunucu gerekip gerekmediği, üçüncü taraf entegrasyonlar ve yayın sonrası bakım belirler. Net bir kapsam dokümanı olmadan verilen her fiyat tahminden ibarettir. En sağlıklı yol, temel özelliklerle bir ilk sürüm (MVP) planlamaktır.
Mobil uygulama yaptırma fiyatı neden bu kadar değişken?
Bir uygulamanın kullanıcının gördüğü ekranları, buzdağının yalnızca üstüdür. Aynı görünen iki uygulamadan biri verileri telefonda tutarken, diğeri kullanıcı hesapları, ödeme altyapısı, bildirim sistemi ve yönetim paneliyle çalışan bütün bir sistem olabilir.
Fiyat farkının ikinci kaynağı tasarım yaklaşımıdır. Hazır arayüz bileşenleriyle hızlıca kurulan bir uygulama ile markaya özel tasarlanmış, her ekranı kullanıcı testinden geçmiş bir uygulamanın emeği aynı değildir.
Üçüncü kaynak ise belirsizliktir. Kapsam net değilse geliştirici riski fiyata ekler ya da düşük fiyat verip sonradan “bu kapsam dışında” demeye başlar. İkisi de işletme için istenmeyen bir durumdur.
Uygulamanın görünmeyen kısmı: Panel, sunucu ve API
Çoğu işletme uygulamasında üç parça vardır:
- Mobil uygulama: Kullanıcının telefonuna indirdiği kısım.
- Arka uç (backend) ve API: Kullanıcı hesaplarını, siparişleri, randevuları ve içerikleri tutan, uygulamayla sürekli konuşan sunucu tarafı.
- Yönetim paneli: İşletmenin ürün eklediği, siparişleri gördüğü, bildirim gönderdiği web tabanlı ekran.
Teklif alırken bu üç parçanın ayrı ayrı yazılmasını isteyin. Bazı tekliflerde yalnızca mobil uygulama fiyatlandırılır; panel ve sunucu daha sonra ek iş olarak çıkar. Mevcut bir web siteniz veya ERP sisteminiz varsa, uygulamanın bu sistemlerle mi konuşacağı, yoksa ayrı bir veri yapısı mı kurulacağı da baştan netleşmelidir.
Native, cross-platform ve PWA: Hangisi, ne zaman?
Teknoloji seçimi, hem ilk geliştirme maliyetini hem de sonraki yılların bakım yükünü belirler.
| Yaklaşım | Ne demek? | Maliyete etkisi | Uygun olduğu durum |
|---|---|---|---|
| Native | iOS ve Android için ayrı kod tabanı | En yüksek; iki ayrı geliştirme ve bakım | Yoğun cihaz özelliği, yüksek performans gerektiren uygulamalar |
| Cross-platform | Flutter veya React Native ile tek kod tabanı | Orta; tek kodla iki platform | İşletme uygulamalarının büyük çoğunluğu |
| PWA (web uygulaması) | Tarayıcıda çalışan, ana ekrana eklenebilen web uygulaması | En düşük; mağaza süreci gerekmeyebilir | İç kullanım, basit sipariş ve rezervasyon akışları |
Randevu, sipariş, sadakat programı veya bayi uygulaması gibi işletme odaklı projelerin önemli kısmı cross-platform yaklaşımla verimli şekilde geliştirilebilir. Karar, teknik bir tercih olmaktan önce işletmenin ihtiyacına göre verilmelidir.
Hangi özellikler mobil uygulama yaptırma fiyatını artırır?
Aşağıdaki tablo, sık istenen özelliklerin geliştirme emeğini kabaca karşılaştırıyor. Kesin süre değil, göreceli bir fikir vermesi amaçlanıyor.
| Özellik | Göreceli emek | Not |
|---|---|---|
| Statik bilgi ekranları | Düşük | Hakkımızda, iletişim, katalog görüntüleme |
| Üyelik ve giriş | Orta | Şifre sıfırlama, sosyal giriş, hesap silme dahil |
| Bildirimler | Orta | Hedefli bildirim için panel tarafı da gerekir |
| Uygulama içi ödeme | Orta-yüksek | Ödeme kuruluşu entegrasyonu, iade senaryoları |
| Harita ve konum | Orta-yüksek | Canlı konum takibi en yüksek emek kalemlerindendir |
| Anlık mesajlaşma | Yüksek | Sunucu altyapısı ve moderasyon gerektirir |
| Çevrimdışı çalışma | Yüksek | Veri senkronizasyonu karmaşıklığı artırır |
| ERP, CRM veya kargo entegrasyonu | Değişken | Karşı sistemin API kalitesine bağlıdır |
Mağaza süreçleri ve yayın sonrası giderler
Uygulamanın yayınlanması, işin bitişi değil yeni bir dönemin başlangıcıdır. Bütçede şu kalemlerin de yer alması gerekir:
- Mağaza hesapları: App Store için Apple Developer Program üyeliği, Google Play için Play Console kaydı gerekir. Apple üyeliği ücretlidir; Google Play ise kayıt sırasında bir defaya mahsus kayıt ücreti alır. Güncel tutarları resmi sayfalardan kontrol edin ve hesapları işletme adına açtırın.
- Mağaza incelemesi: Apple ve Google, uygulamaları yayına almadan önce kendi kurallarına göre inceler. Apple’ın inceleme kuralları özellikle gizlilik, hesap silme ve ödeme konularında ayrıntılıdır; ret durumunda düzeltme süreci takvime eklenmelidir.
- Sunucu ve servisler: Barındırma, veritabanı, bildirim ve harita servisleri kullanım arttıkça maliyet üretir.
- İşletim sistemi güncellemeleri: iOS ve Android her yıl yeni sürüm çıkarır; uygulamanın uyumlu kalması için düzenli güncelleme gerekir.
- Hata düzeltme ve küçük geliştirmeler: Kullanıcı geri bildirimleri ilk aylarda yoğun gelir.
Bu nedenle geliştirme teklifiyle birlikte aylık veya yıllık bakım kapsamını da yazılı olarak isteyin.
Önce mobil uyumlu site mi, önce uygulama mı?
Her işletmenin mobil uygulamaya ihtiyacı yoktur. Müşteri sizi yılda bir iki kez ziyaret ediyorsa, telefonuna uygulama indirmesi beklenmez; iyi çalışan bir mobil site çok daha mantıklıdır. Bu konuyu mobil uyumlu web sitesinin neden şart olduğunu anlattığımız yazıda ele aldık.
Uygulama ise tekrar eden kullanım olduğunda anlam kazanır: düzenli sipariş veren bayiler, sadakat programı kullanan müşteriler, randevusunu sık yenileyen danışanlar veya sahada çalışan ekipler gibi. Örneğin bayileriniz için web tabanlı bir sipariş portalı zaten varsa, uygulama ikinci aşamada düşünülebilir; bu yapıyı B2B sipariş sistemi yazımızda anlattık.
İlk sürümü (MVP) doğru planlamak
- Tek bir ana kullanım senaryosu seçin: “Müşteri randevu alabilsin” veya “bayi sipariş verebilsin” gibi.
- Bu senaryo için zorunlu ekranları listeleyin: Gerisini ikinci sürüme bırakın.
- Yönetim panelini sade tutun: İlk aşamada işletmenin gerçekten kullanacağı işlevlerle sınırlayın.
- Ölçümü baştan kurun: Hangi ekranların kullanıldığını ve nerede bırakıldığını görmeden ikinci sürümü planlamak tahmine dayanır.
- Geri bildirimle genişletin: Gerçek kullanıcı verisi, özellik listesini çoğu zaman beklenmedik şekilde değiştirir.
Bütçeyi bu şekilde aşamalara bölmenin bir faydası daha var: Her aşamanın sonunda somut, kullanılabilir bir ürün olur. İkinci aşamaya geçip geçmeme kararını, ilk sürümün gerçek kullanım verisine bakarak verirsiniz. Tek seferde bütün özellik listesini geliştirmeye çalışan projeler ise hem daha uzun sürer hem de kullanılmayan özelliklere bütçe harcama riski taşır.
Teklif istemeden önce hazırlanacak bilgiler
- Uygulamanın kim tarafından, hangi amaçla kullanılacağı
- Ana ekranların ve akışların kabaca listesi (elle çizilmiş taslak bile işe yarar)
- Gerekli entegrasyonlar: ödeme, kargo, ERP, mevcut web sitesi
- Yönetim panelinde yapılması gereken işler
- Platformlar: iOS, Android veya ikisi birden
- Hedef yayın tarihi ve bütçe aralığı
- Yayın sonrası bakımın kimde olacağı
Darıca merkezli ekibimiz Türkiye genelindeki işletmeler için kapsamı netleştirilmiş, panel ve sunucu tarafıyla birlikte planlanan uygulamalar geliştiriyor. Süreç ve teknoloji yaklaşımımızı mobil uygulama geliştirme sayfamızda, bölgedeki işletmelere yönelik çalışmalarımızı da Darıca ve Gebze mobil uygulama sayfamızda bulabilirsiniz.
Sık Sorulan Sorular
Mobil uygulama yaptırma fiyatı neden net bir rakamla söylenmiyor?
Çünkü maliyet, ekran sayısı, özellikler, entegrasyonlar ve panel ihtiyacına göre katlanarak değişir. Kapsam dokümanı hazırlandıktan sonra verilen teklif gerçekçi olur; öncesinde verilen rakamlar yalnızca kaba tahmindir.
iOS ve Android için ayrı ayrı mı ödeme yaparım?
Native geliştirmede iki ayrı kod tabanı olduğu için maliyet belirgin şekilde artar. Cross-platform geliştirmede tek kodla iki platform hedeflenir; yine de her iki mağazanın test ve yayın süreçleri ayrı ayrı yürütülür.
Uygulamanın kaynak kodu kime ait olur?
Bu, sözleşmede açıkça yazılması gereken bir konudur. Kaynak kodun, mağaza hesaplarının ve sunucu erişimlerinin işletmeye devredilip devredilmeyeceği teklif aşamasında netleştirilmelidir.
Uygulama yayınlandıktan sonra ek maliyet olur mu?
Evet. Mağaza üyelikleri, sunucu ve servis ücretleri, işletim sistemi güncellemelerine uyum ve hata düzeltmeleri düzenli giderlerdir. Bunları baştan bütçelemek, uygulamanın birkaç yıl sağlıklı çalışmasını sağlar.
