"Bir mobil uygulama yaptırmak ne kadar tutar?" sorusu, "bir ev yaptırmak ne kadar tutar?" sorusuna benzer: cevap planınıza bağlıdır. Bu rehberde mobil uygulama maliyetini oluşturan kalemleri, Flutter gibi çapraz platform teknolojilerin bütçeye etkisini ve yayından sonra devam eden giderleri anlatıyoruz. Amacımız size bir rakam vermek değil, teklifleri doğru okuyabilmeniz için bir çerçeve sunmak.
Kısa cevap: Mobil uygulama yaptırma maliyetini ekran ve özellik sayısı, backend ve yönetim paneli, tasarım düzeyi, entegrasyonlar ve yayın sonrası bakım belirler. Flutter, tek kod tabanıyla iOS ve Android'i birlikte hedeflediği için çoğu iş uygulamasında geliştirme ve bakım yükünü azaltır; en ekonomik başlangıç ise iyi tanımlanmış bir MVP'dir.
Maliyeti belirleyen ana kalemler
1. Ekran ve özellik sayısı
Uygulamanın kaç ekrandan oluştuğu ve her ekranın ne yaptığı, iş yükünün temelidir. Giriş/kayıt, profil, liste, detay, arama, bildirimler, ayarlar gibi temel ekranlar neredeyse her uygulamada vardır. Ödeme, harita, canlı sohbet, çevrimdışı çalışma, kamera ile tarama gibi özellikler ise ayrı ayrı emek ister.
2. Backend (sunucu tarafı)
Çoğu uygulama bir sunucuya ihtiyaç duyar: kullanıcı hesapları, veriler, bildirim gönderimi ve yönetim paneli burada çalışır. Firebase gibi hazır servislerle hızlı başlanabilir; daha karmaşık iş kuralları için özel bir API geliştirmek gerekebilir. Teklifte backend'in ve yönetim panelinin dahil olup olmadığını mutlaka sorun.
3. Tasarım
Kullanıcı deneyimi (UX) çalışması ve arayüz tasarımı (UI), uygulamanın başarısında belirleyicidir. Hazır bileşenlerle sade bir tasarım ekonomiktir; markaya özel, animasyonlu bir arayüz daha fazla zaman ister.
4. Platform: iOS, Android veya ikisi
Geleneksel yaklaşımda iOS için Swift, Android için Kotlin ile iki ayrı uygulama geliştirilir. Çapraz platform yaklaşımında ise tek bir kod tabanıyla iki platform hedeflenir. Bu konuyu ayrıntılı olarak Native vs Cross-Platform yazımızda karşılaştırdık.
5. Entegrasyonlar
Ödeme kuruluşları, harita servisleri, SMS doğrulama, e-fatura, CRM veya mevcut ERP sisteminizle bağlantı; her biri test edilmesi gereken ayrı parçalardır.
Flutter bütçeye nasıl etki eder?
Flutter, Google'ın geliştirdiği açık kaynaklı bir arayüz araç setidir ve Dart diliyle tek kod tabanından iOS ve Android uygulamaları üretmeyi sağlar. Bütçe açısından etkileri şunlardır:
- Tek kod tabanı: Arayüz ve iş mantığının büyük kısmı iki platformda ortak kullanılır; bu, geliştirme ve bakım süresini genellikle kısaltır.
- Tutarlı arayüz: Flutter kendi çizim motoruyla çalıştığı için tasarım iki platformda aynı görünür; ayrı ayrı uyarlama ihtiyacı azalır.
- Platforma özel kodlar yine gerekebilir: Bluetooth, arka plan servisleri, bazı donanım özellikleri veya yeni çıkan işletim sistemi özellikleri için platforma özel kod yazmak gerekebilir.
- Uzmanlık: Ekibin Flutter deneyimi kaliteyi doğrudan etkiler; durum yönetimi, test ve performans optimizasyonu tecrübe ister.
Yayın ve sonrası: sabit giderler
| Kalem | Açıklama |
|---|---|
| Apple Developer Program | App Store'da yayın için yıllık üyelik gerekir (Apple'ın güncel ücretini kontrol edin). |
| Google Play Console | Geliştirici hesabı için tek seferlik kayıt ücreti alınır. |
| Sunucu ve servisler | Backend barındırma, veritabanı, dosya depolama, bildirim ve SMS servisleri kullanım arttıkça büyür. |
| Bakım ve güncelleme | Her yıl yeni iOS ve Android sürümleri çıkar; uygulamanın uyumlu kalması için düzenli güncelleme gerekir. |
| Mağaza gereklilikleri | Gizlilik beyanları, hesap silme özelliği gibi mağaza politikalarındaki değişikliklere uyum. |
Pratik bir kural: uygulama yayınlandıktan sonra da bir bütçe ayırın. Mağaza politikaları ve işletim sistemi sürümleri değiştikçe güncelleme yapılmayan uygulamalar zamanla sorun çıkarır.
Bütçeyi kontrol altında tutmanın yolları
MVP ile başlayın
Minimum uygulanabilir ürün (MVP), fikrinizi test etmek için gereken en küçük özellik setidir. Her şeyi ilk sürüme sığdırmaya çalışmak hem süreyi hem de riski artırır. Önce çekirdek değeri sunan özellikleri yayınlayın, kullanıcı geri bildirimine göre büyütün.
Kapsamı yazılı hâle getirin
Ekran listesi, kullanıcı akışları ve kabul kriterleri yazılı olmadan verilen teklifler, proje ilerledikçe şişer. Basit bir tel kafes (wireframe) bile belirsizliği büyük ölçüde azaltır.
Hazır servisleri akıllıca kullanın
Kimlik doğrulama, bildirim, analiz ve hata takibi için olgun hazır servisler kullanmak geliştirme süresini kısaltır. Ancak kullanım arttıkça ücretlerin nasıl değiştiğini önceden hesaplayın.
Yönetim panelini unutmayın
İçerikleri, kullanıcıları ve siparişleri kim, nereden yönetecek? Panel ihtiyacı geç fark edilirse ek maliyet çıkar.
Teklif isterken hazırlamanız gerekenler
- Uygulamanın amacı ve hedef kullanıcısı (bir paragraf yeterli)
- Olmazsa olmaz özellikler ve "sonra olabilir" özellikler listesi
- Benzer uygulama örnekleri ve beğendiğiniz/beğenmediğiniz noktalar
- Mevcut sistemler (web sitesi, ERP, CRM) ve entegrasyon ihtiyaçları
- Hedef yayın tarihi ve bütçe aralığı
Bir mobil uygulama projesinin aşamaları
Teklifteki toplam rakamın neyi kapsadığını anlamak için projenin hangi aşamalardan geçtiğini bilmek faydalıdır:
| Aşama | Çıktı | Neden önemli? |
|---|---|---|
| Keşif | Kapsam dokümanı, kullanıcı akışları, öncelik listesi | Yanlış şeyi doğru yapmayı önler |
| Tasarım | Tel kafes, arayüz tasarımı, tıklanabilir prototip | Geliştirme başlamadan önce kullanıcı deneyimi test edilir |
| Geliştirme | Uygulama, backend, yönetim paneli | Bütçenin en büyük kısmı |
| Test | Farklı cihazlarda test, hata düzeltmeleri | Mağaza onayı ve kullanıcı memnuniyeti |
| Yayın | Mağaza kayıtları, ekran görüntüleri, açıklamalar | Mağaza incelemesinden geçiş |
| Bakım | Güncellemeler, izleme, küçük geliştirmeler | Uygulamanın yaşamaya devam etmesi |
Keşif ve tasarım aşamalarını atlamak ilk bakışta tasarruf gibi görünür; ancak geliştirme sırasında ortaya çıkan belirsizlikler genellikle daha pahalıya mal olur.
Gizli maliyetlere karşı kontrol listesi
- Teklif iOS ve Android'in ikisini de kapsıyor mu?
- Backend ve yönetim paneli dahil mi, yoksa ayrı mı fiyatlanıyor?
- Sunucu ve üçüncü taraf servis ücretleri kimin hesabından ödenecek?
- Mağaza yayın süreci ve olası ret durumlarındaki düzeltmeler dahil mi?
- Yayın sonrası kaç ay hata düzeltme garantisi var?
- Tasarım revizyonu sayısı sınırlı mı?
- Uygulama içi metinlerin çevirisi gibi içerik işleri kimin sorumluluğunda?
Web uygulaması bir alternatif olabilir mi?
Her fikir için mağazada bir uygulama gerekmez. Kullanıcılarınız uygulamayı nadiren açacaksa, bildirim veya cihaz donanımına derin erişim gerekmiyorsa, mobil uyumlu bir web uygulaması daha ekonomik bir başlangıç olabilir. Tersine, sık kullanılan, bildirimle geri çağrılan, kamera, konum veya Bluetooth gibi özelliklere dayanan ürünlerde mobil uygulama daha iyi bir deneyim sunar. Flutter'ın web desteği sayesinde bazı projelerde aynı kod tabanının bir kısmını web için de kullanmak mümkündür; ancak bunun projenize uygun olup olmadığı ayrıca değerlendirilmelidir.
Uygulama türüne göre karmaşıklık örnekleri
Aşağıdaki tablo rakam vermek yerine farklı uygulama türlerinin hangi bileşenleri içerdiğini gösterir; teklif karşılaştırırken kapsamı netleştirmenize yardımcı olur.
| Uygulama türü | Tipik bileşenler | Karmaşıklık |
|---|---|---|
| Kurumsal tanıtım / katalog | İçerik ekranları, bildirim, iletişim formu | Düşük |
| Randevu ve rezervasyon | Takvim, kullanıcı hesabı, bildirim, yönetim paneli | Orta |
| E-ticaret | Ürün listesi, sepet, ödeme, sipariş takibi, panel | Orta – yüksek |
| Saha ekibi uygulaması | Çevrimdışı çalışma, form, fotoğraf, konum, senkronizasyon | Yüksek |
| IoT kontrol uygulaması | Bluetooth/Wi-Fi cihaz eşleme, canlı veri, grafik | Yüksek |
| Pazar yeri / çok taraflı platform | Birden fazla kullanıcı rolü, ödeme dağıtımı, mesajlaşma | Çok yüksek |
IoT tarafında cihaz ile uygulama arasındaki iletişim ayrı bir uzmanlık gerektirir; bu konuyu ESP32 ile IoT prototip yazımızda ele aldık.
Flutter projelerinde kaliteyi belirleyen teknik konular
- Durum yönetimi: Uygulama büyüdükçe verinin ekranlar arasında nasıl taşındığı kodun okunabilirliğini belirler. Baştan tutarlı bir yaklaşım seçilmelidir.
- Test: Birim testleri ve arayüz testleri, yeni sürümlerde eski özelliklerin bozulmasını önler.
- Hata izleme: Kullanıcı cihazlarındaki çökme ve hataların raporlanması, sorunların kullanıcı şikâyet etmeden fark edilmesini sağlar.
- Sürekli entegrasyon: Derleme ve mağazaya gönderim süreçlerinin otomatikleştirilmesi, her sürümde zaman kazandırır ve hata riskini azaltır.
- Paket seçimi: Üçüncü taraf paketlerin bakım durumu ve popülerliği kontrol edilmelidir; terk edilmiş bir pakete bağımlılık ileride sorun çıkarır.
Mağaza onayı: sık karşılaşılan ret sebepleri
App Store ve Google Play, uygulamaları yayına almadan önce inceler. Ret sebepleri arasında sık görülenler şunlardır:
- Eksik veya hatalı gizlilik politikası ve veri kullanım beyanları
- Hesap oluşturulabilen uygulamalarda hesap silme seçeneğinin olmaması
- Çalışmayan bağlantılar, boş ekranlar veya test içerikleri
- Uygulamanın bir web sitesini sadece sarmalaması ve ek değer sunmaması
- İzin isteklerinin (kamera, konum) amacının açıklanmaması
Bu maddeleri geliştirme sırasında kontrol listesine eklemek, yayın tarihinin kaymasını önler. Mağaza kuralları güncellendiği için resmî inceleme yönergelerini her büyük sürüm öncesi gözden geçirin.
Yayından sonra büyüme: uygulamanın ikinci yılı
Uygulamanın mağazada yayınlanması bir başlangıçtır. İkinci yıl için bütçe ve plan yaparken şu başlıkları düşünün:
Ölçüm ve analiz
Kullanıcıların hangi ekranlarda vakit geçirdiğini, hangi adımda uygulamayı bıraktığını ve hangi özellikleri hiç kullanmadığını bilmek, yeni sürümlerin önceliğini belirler. Analiz olaylarını baştan planlamak, sonradan eklemekten çok daha kolaydır.
Mağaza optimizasyonu (ASO)
Uygulama adı, kısa açıklama, ekran görüntüleri ve kullanıcı yorumları, mağaza aramalarında görünürlüğü ve indirme oranını etkiler. Ekran görüntülerinin uygulamanın değerini ilk bakışta anlatması önemlidir.
Geri bildirim döngüsü
Uygulama içi kısa anketler, mağaza yorumlarına verilen yanıtlar ve destek talepleri, ürün yol haritasının en değerli girdileridir. Kullanıcı şikâyetlerini kategorize edip düzenli değerlendirmek, hangi geliştirmenin gerçekten fark yaratacağını gösterir.
Sürüm planı
Küçük ama düzenli sürümler, büyük ve seyrek sürümlere göre daha az risk taşır. Her sürümde hata düzeltmelerini ve bir-iki yeni özelliği birlikte yayınlamak, kullanıcıya uygulamanın yaşadığını gösterir.
Uygulamanızı tanıtmak için web sitesi ve reklam tarafında dijital reklam hizmetimizden de destek alabilirsiniz.
Doğru geliştirme ekibini seçmek
Bütçe kadar, projeyi kimin yapacağı da sonucu belirler. Ekip seçerken şu noktalara dikkat edin:
- Yayınlanmış uygulamalar: Ekibin mağazada yayında olan ve hâlâ güncellenen uygulamalarına bakın; mümkünse indirip deneyin.
- Süreç şeffaflığı: Proje nasıl aşamalara bölünüyor, ara teslimler ne zaman yapılıyor, ilerlemeyi nasıl göreceksiniz?
- Backend yetkinliği: Mobil uygulamanın arkasındaki sunucu ve panel tarafını da aynı ekibin yapabilmesi, sorumluluk karmaşasını önler.
- İletişim: Sorularınıza teknik jargona boğmadan, anlaşılır cevaplar veriliyor mu?
- Bakım taahhüdü: Yayından sonra hangi koşullarla destek veriliyor?
- Sahiplik: Kaynak kod, tasarım dosyaları ve mağaza hesapları kimde kalacak?
En düşük fiyatı veren ekip yerine, kapsamı en iyi anlayan ve riskleri açıkça konuşan ekiple çalışmak uzun vadede genellikle daha ekonomiktir.
Terimler sözlüğü
- Cross-platform (çapraz platform): Tek kod tabanından birden fazla işletim sistemi için uygulama üretme yaklaşımı.
- Native: Her platformun kendi dili ve araçlarıyla (iOS için Swift, Android için Kotlin) geliştirme.
- Dart: Flutter uygulamalarının yazıldığı, Google tarafından geliştirilen programlama dili.
- Backend: Uygulamanın verilerini, kullanıcı hesaplarını ve iş kurallarını yöneten sunucu tarafı.
- API: Uygulama ile sunucu arasında veri alışverişini sağlayan programlama arayüzü.
- MVP: Fikri gerçek kullanıcılarla test etmek için gereken en küçük işlevsel ürün.
- ASO: Uygulamanın mağaza aramalarında daha görünür olması için yapılan optimizasyon.
Özetle: akılda kalması gerekenler
- Maliyeti ekran sayısı, backend, tasarım, entegrasyonlar ve bakım birlikte belirler.
- Flutter, tek kod tabanıyla iOS ve Android'i hedefleyerek geliştirme ve bakım yükünü azaltır.
- MVP ile başlamak bütçeyi ve riski kontrol altında tutar.
- Teklifte backend, panel, mağaza yayını ve garanti süresinin dahil olup olmadığını sorun.
- Yayından sonraki güncellemeler ve sunucu giderleri için ayrıca bütçe ayırın.
- Kaynak kod ve hesap sahipliğini sözleşmede netleştirin.
Sık Sorulan Sorular
Flutter ile yapılan uygulama native kadar hızlı mı?
Çoğu iş uygulamasında kullanıcı farkı hissetmez. Flutter derlenmiş kod üretir ve akıcı arayüzler için tasarlanmıştır. Çok yoğun grafik veya platforma özgü ileri donanım kullanımı gereken projelerde native seçenek ayrıca değerlendirilmelidir.
Uygulamayı sadece Android'de mi başlatmalıyım?
Hedef kitlenize bakın. Flutter ile iki platformu birlikte yayınlamanın ek maliyeti genellikle sınırlı olduğundan, çoğu durumda ikisini aynı anda yayınlamak mantıklıdır.
Bir uygulama ne kadar sürede tamamlanır?
Kapsama bağlıdır. İyi tanımlanmış bir MVP birkaç ayda yayınlanabilir; çok sayıda entegrasyon ve panel içeren projeler daha uzun sürer.
Kaynak kod bana mı ait olur?
Bu tamamen sözleşmeye bağlıdır. Teklif aşamasında kaynak kodun, mağaza hesaplarının ve sunucu erişimlerinin size teslim edileceğini yazılı olarak netleştirin.
Flutter ile yapılan uygulama mağazalarda sorun yaşar mı?
Hayır, Flutter uygulamaları standart iOS ve Android paketleri olarak yayınlanır ve diğer uygulamalarla aynı inceleme sürecinden geçer.
Mevcut web sitemin verilerini uygulamada kullanabilir miyim?
Web sitenizin bir API'si varsa veya geliştirilebilirse, ürünler, içerikler ve kullanıcı hesapları uygulamayla ortak kullanılabilir.
Uygulamanın bakımını başka bir firmaya devredebilir miyim?
Kaynak kod, dokümantasyon ve tüm hesap erişimleri size teslim edildiyse evet. Bu nedenle teslim maddelerini sözleşmede açıkça belirtin.
Sonuç
Mobil uygulama bütçesi; ekran sayısı, backend, tasarım, entegrasyonlar ve yayın sonrası bakımın toplamıdır. Flutter, tek kod tabanıyla iki platformu hedefleyerek bu toplamı makul tutmanın güçlü bir yoludur. Fikrinizi bir MVP'ye dönüştürmek isterseniz mobil uygulama hizmetimizi inceleyebilir ve bizimle iletişime geçebilirsiniz.
