Mobil Uygulama Maliyeti İçin Özellik Bazlı Bütçe Tablosu

Mobil uygulama maliyeti için tek bir ortalama rakam aramak anlaşılırdır; ancak çoğu projede güvenilir bir bütçe üretmez. Aynı sayıda ekrana sahip iki uygulamadan biri yalnızca içerik gösterebilirken diğeri kullanıcı yetkilerini, çevrimdışı işlemleri, ödeme akışlarını ve ERP bağlantısını yönetebilir. Görünürde benzer olan bu ürünlerin analiz, tasarım, geliştirme, test ve işletim yükleri farklıdır.

Daha sağlıklı yaklaşım, uygulamayı özellik paketlerine ayırmak ve her paketin kapsamını, bağımlılıklarını ve kabul ölçütlerini ayrı değerlendirmektir. Bu rehberdeki özellik bazlı bütçe tablosu kesin fiyat listesi değildir. Girişimlerin, KOBİ’lerin, kurumsal karar vericilerin ve ürün ekiplerinin teklif öncesinde hangi iş kalemlerini görünür hâle getirmesi gerektiğini gösteren bir planlama aracıdır.

Mobil uygulama maliyeti neden tek rakamla açıklanamaz?

Bir mobil ürünün maliyeti yalnızca kod yazma süresinden oluşmaz. Kullanıcı ihtiyacının araştırılması, iş kurallarının tanımlanması, arayüz tasarımı, iOS ve Android davranışlarının doğrulanması, sunucu tarafı yazılımı, yönetim paneli, entegrasyonlar, güvenlik kontrolleri ve yayın hazırlığı aynı bütçenin parçalarıdır. Belirsiz bırakılan her karar, geliştirme sırasında yeniden çalışma ihtimalini artırır.

Örneğin “kullanıcı girişi olacak” ifadesi bütçe çıkarmaya yetmez. E-posta ve parola mı kullanılacak, kurumsal tek oturum açma mı gerekecek, çok faktörlü doğrulama olacak mı, hesaplar yönetici onayıyla mı açılacak? Benzer biçimde “bildirim gönderilecek” talebi; hedefleme, zamanlama, tercih yönetimi, derin bağlantı ve teslimat takibi gibi alt gereksinimler içerebilir.

Bu nedenle maliyet görüşmesinin temel birimi ekran değil, test edilebilir kullanıcı akışıdır. Kapsamı yazılı hâle getirmek için yazılım ihtiyaç dokümanı hazırlama rehberi de kullanılabilir. Her akışın başlangıcı, başarı durumu, hata durumu, yetkili rolü ve veri kaynağı belirlendiğinde teklifler daha karşılaştırılabilir olur.

Özellik bazlı mobil uygulama bütçesi nasıl hazırlanır?

Bütçe çalışması iş hedefinden başlamalı, teknik çözümden önce kullanıcıların tamamlayacağı görevleri açıklamalıdır. Ardından ilk sürüm için gerekli akışlar seçilir ve her akışın veri, cihaz özelliği, entegrasyon ve güvenlik bağımlılıkları kaydedilir. Son aşamada geliştirme kalemlerine test, mağaza yayını ve canlı kullanım sorumlulukları eklenir.

1. İş hedefini ve başarı ölçütünü tanımlayın

Uygulamanın hangi sorunu çözeceğini tek cümlede belirtin. Sipariş süresini azaltmak, saha kayıtlarını aynı gün ERP’ye aktarmak veya müşterinin randevusunu kendi yönetmesini sağlamak gibi ölçülebilir bir hedef, gereksiz özellikleri ayıklamaya yardım eder. İndirme sayısı tek başına yeterli bir hedef değildir; tamamlanan görev, hatasız işlem, tekrar kullanım veya operasyon süresi gibi sonuçlar daha açıklayıcıdır.

2. Kullanıcı rollerini ve akışları çıkarın

Müşteri, çalışan, saha personeli, bayi ve yönetici gibi rollerin gördüğü veriler ile yapabildiği işlemler ayrılmalıdır. Her yeni rol yalnızca birkaç ekran değil; yetkilendirme, veri filtreleme, bildirim, test senaryosu ve yönetim ihtiyacı doğurabilir. Rol sayısı kadar roller arasındaki onay ve devir ilişkileri de bütçeyi etkiler.

3. Teknik bağımlılıkları işaretleyin

Kamera, barkod okuyucu, konum, biyometri, Bluetooth, dosya sistemi ve arka plan işlemleri cihazla özel etkileşim gerektirir. Ödeme kuruluşu, harita servisi, CRM veya ERP ise dış sistem bağımlılığı oluşturur. API belgelerinin kalitesi, test ortamının varlığı, veri eşleme kuralları ve hata yönetimi entegrasyon eforunu doğrudan değiştirir.

4. İlk sürüm ile sonraki fazları ayırın

Her istek ilk yayına girmek zorunda değildir. Temel kullanıcı değerini ve güvenli işletimi sağlayan özellikler ilk sürüme; doğrulanmamış kolaylıklar sonraki fazlara alınabilir. MVP kararı yalnızca bütçe küçültmek değil, varsayımları daha erken sınamak için verilmelidir. İlk sürüm seçimini sistematikleştirmek için MVP kapsamı karar tablosundan yararlanılabilir.

5. Test, yayın ve işletimi bütçeye ekleyin

Fonksiyonun geliştirilmiş olması, yayına hazır olduğu anlamına gelmez. Desteklenen cihazlar, ekran boyutları, işletim sistemi sürümleri, zayıf ağ, izin reddi ve uygulamanın arka plandan dönmesi gibi durumlar test edilmelidir. Google’ın temel uygulama kalite rehberi; kullanıcı deneyimi, işlevsellik, erişilebilirlik ve farklı cihaz koşullarının birlikte ele alınması gerektiğini gösterir.

Özellik bazlı mobil uygulama bütçe tablosu

Aşağıdaki gruplar teklif talebinde ayrı satırlar olarak kullanılabilir. Her satıra “ilk sürüm”, “sonraki faz” veya “kapsam dışı” kararı; sorumlu veri kaynağı; kabul ölçütü ve bilinen bağımlılıklar eklenmelidir. Düşük, orta veya yüksek etki ifadeleri fiyat değil, özelliğin proje kapsamına getirebileceği göreli iş yükünü anlatır.

Ürün keşfi, UX ve arayüz tasarımı — temel bütçe

• İhtiyaç analizi, kullanıcı görüşmeleri ve iş kurallarının çıkarılması
• Kullanıcı yolculukları, bilgi mimarisi ve tıklanabilir prototip
• Markaya özel arayüz sistemi, erişilebilirlik ve farklı ekran durumları
• Boş, yükleniyor, başarılı, hatalı ve izin reddedilmiş durumların tasarımı

Hazır bir görsel şablon ekran üretimini hızlandırabilir; fakat karmaşık görevleri veya marka deneyimini tek başına çözmez. Özgün akış sayısı, revizyon yöntemi ve prototip testlerinin kapsamı tasarım bütçesini belirler.

Üyelik, kullanıcı rolleri ve yetkilendirme — düşükten yükseğe

• Basit üyelik, parola yenileme ve profil yönetimi
• Sosyal giriş, kurumsal SSO veya çok faktörlü doğrulama
• Müşteri, bayi, çalışan ve yönetici gibi çoklu roller
• Rol, işlem ve veri alanı seviyesinde ayrıntılı yetki kuralları

Tek rol ve standart üyelik görece sınırlı kalabilir. Kurumsal kimlik sistemi, onay zincirleri ve hassas işlem doğrulaması eklendiğinde hem sunucu tarafı geliştirme hem de güvenlik testi büyür.

Ekranlar ve iş akışları — orta etki

• Listeleme, arama, filtreleme ve detay ekranları
• Çok adımlı form, taslak kaydetme ve belge yükleme
• Onay, iptal, iade veya görev devri gibi durum geçişleri
• Hata düzeltme, tekrar deneme ve işlem geçmişi

Yalnızca ekran adedini saymak yanıltıcıdır. Sabit içerik ekranı ile fiyat, stok ve yetkiye göre davranışı değişen sipariş ekranı aynı büyüklükte değildir. Her akış için iş kuralları ve istisnalar ayrıca yazılmalıdır.

Bildirim, mesajlaşma ve zamanlama — düşükten yükseğe

• Temel anlık bildirim ve uygulama içi bildirim kutusu
• Kullanıcı segmenti, tercih merkezi ve gönderim zamanlaması
• Bildirime dokununca ilgili kayda giden derin bağlantı
• İki yönlü mesajlaşma, okunma bilgisi ve medya gönderimi

Tek yönlü işlem bildirimi ile gerçek zamanlı sohbet aynı kalem değildir. Mesaj saklama, moderasyon, çevrimdışı teslim ve okunma durumları ayrı veri ve altyapı gerektirir.

Ödeme ve abonelik — orta ile yüksek etki

• Ödeme kuruluşu entegrasyonu ve güvenli ödeme akışı
• İade, iptal, başarısız işlem ve mutabakat senaryoları
• Tekrarlayan ödeme, abonelik veya uygulama içi satın alma
• Fatura, kampanya, kupon ve çoklu para birimi kuralları

Dijital içerik veya uygulama içi işlev satışı, mağaza kurallarına tabi olabilir. Apple’ın App Review Guidelines belgesi güvenlik, performans, iş modeli, tasarım ve hukuki gereklilikleri ayrı başlıklarda ele alır. Ürün tipi ve dağıtım modeli tekliften önce değerlendirilmelidir.

Harita, konum, kamera ve barkod — orta etki

• Adres gösterimi ile canlı konum takibinin ayrıştırılması
• Rota, bölge sınırı ve konum geçmişi ihtiyaçları
• Fotoğraf çekme, sıkıştırma, yükleme ve kalite kontrolü
• Barkod türleri, seri-lot doğrulaması ve harici okuyucu desteği

Bu özelliklerde cihaz izinleri, pil tüketimi, düşük ışık, hatalı kod ve bağlantı kesintisi gibi gerçek kullanım koşulları test kapsamını büyütür. Depo senaryolarında ayrıntılı örnekler için barkod ve çevrimdışı işlemler rehberi incelenebilir.

Çevrimdışı çalışma ve veri eşitleme — yüksek etki

• Çevrimdışıyken görüntülenecek ve değiştirilecek veriler
• Yerel veri saklama, işlem kuyruğu ve tekrar deneme
• Aynı kaydı iki kullanıcının değiştirmesinde çakışma kuralı
• Eksik senkronizasyonun kullanıcıya ve yöneticilere gösterimi

“İnternet yokken çalışsın” tek bir özellik değildir. Hangi işlemlerin çevrimdışı tamamlanacağı, verinin ne kadar saklanacağı ve bağlantı döndüğünde hangi sistemin öncelikli olacağı tanımlanmalıdır. Bu kararlar mimariyi ve test senaryolarını önemli ölçüde etkiler.

Yönetim paneli, API ve ERP entegrasyonları — orta ile yüksek etki

• İçerik, kullanıcı, rol, kayıt ve işlem yönetimi
• Raporlama, dışa aktarma ve denetim kayıtları
• Mobil uygulama için güvenli API ve sunucu tarafı iş kuralları
• ERP, CRM, ödeme, harita ve diğer üçüncü taraf bağlantıları

Mobil arayüz çoğu zaman daha büyük bir sistemin görünen bölümüdür. Veri girişi, onay ve raporlama için projeye özel bir mobil uygulama geliştirme yaklaşımı; API, yönetim paneli ve işletim ihtiyaçlarıyla birlikte ele alınmalıdır. Entegrasyon bütçesinde alan eşleme, kimlik doğrulama, hız sınırı, kesinti, tekrar deneme ve test verisi açıkça yer almalıdır.

Güvenlik, test ve yayın — zorunlu temel kapsam

• Güvenli veri saklama, aktarım şifrelemesi ve oturum yönetimi
• Yetki kontrolleri, hassas kayıtların maskelenmesi ve loglama
• Fonksiyon, entegrasyon, cihaz, performans ve regresyon testleri
• Mağaza varlıkları, gizlilik beyanları, sürümleme ve yayın takibi

Güvenlik yalnızca proje sonunda yapılan bir sızma testi değildir. OWASP’ın Mobil Uygulama Güvenliği Doğrulama Standardı; depolama, kriptografi, kimlik doğrulama, ağ iletişimi, platform etkileşimi, kod kalitesi, dayanıklılık ve gizlilik gibi alanları ayrı doğrulama başlıkları olarak tanımlar. Risk seviyesine uygun kontroller analizden itibaren bütçelenmelidir.

Yayın sonrası destek ve sürdürülebilir işletim — tekrarlayan bütçe

• Hata izleme, çökme raporları ve performans takibi
• İşletim sistemi, cihaz ve bağımlılık güncellemeleri
• Güvenlik yamaları, yedekleme ve olay müdahalesi
• Küçük geliştirmeler, kullanıcı geri bildirimi ve yeni sürümler

İlk yayın projenin bitişi değil, canlı ürün döneminin başlangıcıdır. Destek paketinde ilk yanıt süresi, öncelik sınıfları, kapsam içi işler, sürüm sıklığı ve üçüncü taraf servis sorumlulukları tanımlanmalıdır. Barındırma, harita kullanımı, mesaj gönderimi, mağaza üyeliği ve benzeri değişken giderler geliştirme teklifinden ayrı gösterilmelidir.

React Native bütçeyi nasıl etkiler?

React Native, iOS ve Android için önemli ölçüde ortak bir kod tabanı kurulmasını sağlayabilir. Bu yaklaşım iki bağımsız uygulamadaki tekrarları azaltabilir; ortak iş kuralları, ekran bileşenleri ve ekip organizasyonu açısından avantaj yaratabilir. Ancak “tek kod, yarı maliyet” şeklinde otomatik bir sonuç çıkarılamaz.

Kamera, Bluetooth, arka plan konumu, ödeme, bildirim veya üreticiye özgü cihaz bağlantıları platforma özel çalışma gerektirebilir. Her iki mağazanın yayın süreçleri, cihaz testleri ve işletim sistemi davranışları da ayrı doğrulanır. Teknoloji kararı; özelliklerin niteliği, performans hedefi, ekip yetkinliği ve uzun vadeli bakım planına göre verilmelidir. Ayrıntılı değerlendirme için native ve cross-platform seçim rehberi kullanılabilir.

Teklifleri karşılaştırırken hangi sorular sorulmalı?

İki teklifin toplam rakamını karşılaştırmadan önce aynı kapsamı içerip içermediği kontrol edilmelidir. Biri yalnızca mobil arayüzü, diğeri API, yönetim paneli, test ve yayın desteğini kapsıyorsa fiyat farkı ekip verimliliğini değil kapsam farkını gösterebilir.

• Analiz, UX/UI tasarımı, geliştirme ve proje yönetimi dahil mi?
• iOS ve Android sürümleri ile desteklenen cihazlar açıkça belirtilmiş mi?
• API ve yönetim panelini kim geliştirecek; kaynak kodun sahipliği nasıl olacak?
• Entegrasyonların test ortamı, veri eşleme ve hata senaryoları tanımlı mı?
• Güvenlik ve kalite kontrolleri hangi teslim kanıtlarıyla doğrulanacak?
• Mağaza başvurusu, olası ret düzeltmeleri ve hesap sorumlulukları kimde?
• Garanti, bakım, destek ve yeni özellik geliştirme birbirinden ayrılmış mı?
• Üçüncü taraf lisansları ve kullanıma bağlı giderler kimin bütçesinde?

Bütçe belirsizliğini azaltan kapsam belgesi

İyi bir teklif dosyasında her özellik için kullanıcı rolü, tetikleyici, ana akış, hata durumları, veri kaynağı, entegrasyon, tasarım durumu ve kabul ölçütü bulunur. Ayrıca “kapsam dışı” maddeler de açıkça yazılır. Böylece sonradan ortaya çıkan talebin hata düzeltmesi mi, eksik teslim mi yoksa yeni özellik mi olduğu daha nesnel değerlendirilebilir.

Riskli kalemler için kısa keşif veya teknik doğrulama çalışması planlanabilir. Belgesiz eski ERP, özel donanım, yoğun çevrimdışı kullanım veya yüksek işlem hacmi gibi konularda küçük bir prototip, varsayıma dayalı sabit fiyat vermekten daha sağlıklı sonuç üretir. Keşif sonunda kapsam, mimari seçenekler, riskler ve faz planı güncellenir.

Projenize özel mobil uygulama bütçesi oluşturun

Mobil uygulama maliyetini açıklanabilir hâle getirmenin yolu, tek bir piyasa ortalamasından değil; kullanıcı rollerini, görevleri, iş kurallarını ve teknik bağımlılıkları görünür kılmaktan geçer. Özellik bazlı tablo, zorunlu ihtiyaçlarla sonraki fazları ayırmayı, teklifler arasındaki gerçek kapsam farklarını görmeyi ve yayın sonrası giderleri baştan planlamayı sağlar.

Kumsal Ajans; iş fikrini, kullanıcı ihtiyaçlarını ve teknik gereksinimleri birlikte değerlendirerek React Native ile iOS ve Android için hibrit mobil ürünler geliştirir. Markaya özel kullanıcı deneyimini; projeye özel web yazılımı, yönetim paneli, ERP/API entegrasyonları, veri güvenliği, test ve sürdürülebilir işletim planıyla birlikte ele alır.

İhtiyaç duyduğunuz özellikleri, kullanıcı rollerini ve entegrasyonları Kumsal Ajans ile paylaşın. Kapsamı birlikte netleştirerek projenize özel, hangi kalemin neden bütçede yer aldığını gösteren açıklanabilir bir mobil uygulama bütçesi oluşturun.