"Mobil uygulama yaptırmak istiyorum" diyen çoğu işletme ilk olarak fiyat sorar. Fiyatı belirleyen şey ise kapsam: uygulama hangi işi yapacak, kim kullanacak, arkasında hangi sistem duracak. Bu rehber sırayı, karar noktalarını ve gerçek maliyet aralıklarını anlatıyor.
Önce şu soru: gerçekten uygulama mı gerekiyor?
Dürüst olalım — gelen taleplerin bir kısmında uygulama yanlış çözüm. Şu üç durumda mobil uygulama parayı boşa harcatıyor:
- Kullanıcı yılda 2–3 kez giriyorsa. İnsanlar yılda üç kez kullanacakları bir şeyi telefonlarına kurmuyor. Mobil uyumlu bir web sitesi aynı işi görür.
- Uygulama, web sitesinin birebir kopyasıysa. Ek değer yoksa mağazadan indirilmesi için sebep de yok.
- Trafik ve müşteri tabanı henüz yoksa. Uygulama var olan müşteriyi elde tutmakta iyidir, yeni müşteri bulmakta değil.
Buna karşılık şu durumlarda uygulama net kazandırıyor: sık tekrarlanan kullanım (sipariş, rezervasyon, takip), bildirim gerektiren süreçler, çevrimdışı çalışma ihtiyacı, kamera/konum/NFC gibi cihaz özelliklerinin kullanımı ve saha ekibi operasyonu.
1. Adım: Kullanım senaryosunu yazmak
Ekran tasarımından önce tek bir cümle yazın: "[Kim], [hangi durumda], [ne yapmak için] uygulamayı açacak."
Örnek: "Bayi temsilcisi, müşteri ziyaretindeyken, stok görüp sipariş girmek için açacak." Bu cümle netleştiğinde hangi ekranların gerekli olduğu kendiliğinden çıkıyor — ve daha önemlisi, hangilerinin gereksiz olduğu.
Cevaplanması gereken diğer sorular:
- Uygulama müşteriye mi, personele mi, bayiye mi hizmet edecek?
- Üyelik, ödeme, bildirim veya harita gerekiyor mu?
- İçerikleri yönetecek bir panel olacak mı?
- iOS ve Android aynı anda mı yayınlanacak?
- Kullanıcı uygulamayı ikinci kez neden açacak?
Son soru en kritik olanı. Cevabı yoksa proje teknik olarak başarılı olup ticari olarak başarısız oluyor.
2. Adım: Native mi, cross-platform mı?
| Native (Swift / Kotlin) | Cross-platform (React Native / Flutter) | |
|---|---|---|
| Maliyet | İki ayrı kod tabanı, ~%60–80 daha pahalı | Tek kod tabanı |
| Performans | En yüksek | Çoğu iş uygulaması için yeterli |
| Cihaz özellikleri | Tam erişim | Çoğu özellik hazır, bazıları köprü ister |
| Güncelleme | İki ekip, iki süreç | Tek geliştirme |
| Ne zaman gerekli | Ağır grafik, oyun, yoğun kamera/sensör işleme | Sipariş, rezervasyon, katalog, saha, içerik |
Pratikte iş uygulamalarının büyük çoğunluğu için cross-platform doğru cevap. React Native ve Flutter, standart iş akışlarında native'den ayırt edilemeyen bir deneyim veriyor ve bütçeyi neredeyse yarıya indiriyor. Native'i, cihaz donanımını sınırda kullanan projeler için saklamak gerekiyor.
3. Adım: MVP kapsamını çizmek
MVP, uygulamanın en küçük ama gerçekten kullanılabilir ilk sürümü. Amacı özellik kısmak değil, ana değeri bir an önce gerçek kullanıcının eline vermek.
MVP'ye giren: ana akışı tamamlayan ekranlar, giriş, temel yönetim paneli.
MVP'ye girmeyen: sosyal medya paylaşımı, rozet/puan sistemi, çoklu dil, gelişmiş raporlama, tema seçimi.
Bu ayrımı yapmayan projelerde iki şey oluyor: yayın tarihi 3 aydan 9 aya kayıyor ve sonunda yayınlanan özelliklerin yarısı hiç kullanılmıyor. MVP mantığının detayını MVP mobil uygulama rehberi yazısında açtık.
4. Adım: Panel ve API — görünmeyen yarısı
Çoğu mobil uygulamanın arkasında bir web paneli ve API duruyor. Bütçenin genelde %40–50'si burada. Baştan planlanması gerekenler:
- Kullanıcı ve yetki yönetimi
- İçerik/ürün/hizmet yönetimi
- Sipariş veya talep akışı
- Bildirim gönderme ekranı
- Temel raporlama
Panel düşünülmeden yapılan uygulamalarda her içerik değişikliği geliştiriciye dönüyor, mağaza güncellemesi bekleniyor ve operasyon tıkanıyor. "Uygulama yaptıralım, panel sonra" kararı, sonradan en pahalıya mal olan karar.
Mevcut sisteminiz varsa (ERP, muhasebe, e-ticaret) uygulamanın onunla konuşması gerekir; bu da ayrı bir API entegrasyonu kalemi.
5. Adım: Mağaza yayını
App Store ve Google Play yayını, "kodu yükleyip bitirmek" değil. Hazırlanması gerekenler:
- Uygulama adı ve mağaza açıklaması (ASO çalışması)
- Her cihaz boyutu için ekran görüntüleri
- Gizlilik politikası bağlantısı ve veri kullanım beyanı
- İzin açıklamaları (kamera, konum, bildirim — her biri gerekçeli)
- Apple için test hesabı ve inceleme notları
- Geliştirici hesapları: Apple yılda 99 USD, Google tek seferlik 25 USD
Apple'ın inceleme süreci ilk gönderimde reddetme oranı yüksek; gerekçesiz izin istemek ve eksik gizlilik beyanı en sık redlerin sebebi. Bu hazırlıklar sona bırakıldığında yayın 2–3 hafta gecikiyor.
Maliyet ve süre
| Kapsam | Süre | Bütçe |
|---|---|---|
| MVP (5–8 ekran, panel, tek akış) | 8–12 hafta | 100.000–200.000 TL |
| Orta ölçek (ödeme, bildirim, entegrasyon) | 3–5 ay | 200.000–450.000 TL |
| Kapsamlı (çok rollü, ERP bağlı, çevrimdışı) | 6 ay+ | 450.000 TL üzeri |
Bizim mobil uygulama geliştirme paketimiz 100.000 TL + KDV'den başlıyor. Fiyatı neyin nasıl değiştirdiğini mobil uygulama fiyatları yazısında kalem kalem açıkladık.
Bütçeye eklenmesi gerekenler: yıllık geliştirici hesapları, sunucu maliyeti, ve en önemlisi bakım. iOS ve Android yılda birer büyük sürüm çıkarıyor; güncellenmeyen uygulamalar 18–24 ay içinde mağazadan düşme riskiyle karşılaşıyor. Yıllık bakım için proje bedelinin %15–20'sini ayırmak gerçekçi.
Sağlıklı bir teklif neleri içermeli?
Teklif alırken şu başlıkların yazılı olmasını isteyin:
- Ekran listesi ve kullanıcı akışı diyagramı
- iOS ve Android kapsamının ayrı ayrı belirtilmesi
- Yönetim paneli ve API kapsamı
- Bildirim, ödeme, harita, abonelik gibi özel modüller
- Test süreci ve kabul kriterleri
- Mağaza yayın desteği (hesap açma, gönderim, red yönetimi)
- Yayın sonrası destek süresi ve kapsamı
- Kaynak kodun ve mağaza hesaplarının kime ait olacağı
Son madde çoğu zaman atlanıyor ve sonradan sorun oluyor: mağaza hesabı geliştiricinin adına açılmışsa uygulamanız üzerinde tam kontrolünüz yok demektir. Hesaplar her zaman sizin şirketinizin adına açılmalı.
Sık sorulan sorular
Uygulama kaç ayda biter?
MVP için 8–12 hafta gerçekçi. Bunun 2 haftası tasarım, 6–8 haftası geliştirme, 1–2 haftası test ve mağaza süreci.
Önce hangi platform?
Türkiye'de kullanıcı sayısı Android'de daha yüksek, harcama Apple tarafında daha yüksek. Cross-platform seçtiğinizde bu karar zaten ortadan kalkıyor.
Uygulamayı sonradan başka bir ekip devralabilir mi?
Kaynak kod size teslim edilmişse ve kod dökümante edilmişse evet. Sözleşmede bu maddenin bulunması, bağımlılığı ortadan kaldırıyor.
Web sitem varken uygulama gerekir mi?
Yukarıdaki üç maddeye bakın. Kullanım sıklığı düşükse mobil uyumlu site daha akıllı bir yatırım.
Nasıl başlayalım
Kullanım senaryonuzu bir paragrafla yazıp gönderin; hangi kapsamın MVP'ye gireceğini ve tahmini süreyi ücretsiz çıkarıyoruz.
Telefon / WhatsApp: +90 536 628 0007
E-posta: info@enextware.com