Uygulama Bütçesi Nasıl Hesaplanır? Beş Adım
Uygulama bütçesi çoğu işletmede tek bir soruyla kurulur: “Bu uygulama kaça yapılır?” Bu soru eksiktir çünkü yapım bedeli toplamın yalnızca bir parçasıdır. Bakım, sunucu ve mağaza kalemleri hesaba katılmazsa bütçe ikinci yılda şaşar. 🧮
Bu yazı bütçeyi beş adımda kuruyor ve üç yıllık toplama ulaştırıyor. Kalem yapısını kalemler yazısında, bantları fiyat rehberinde verdik.
Adım 1: Kapsamı Daraltın
Bütçe, rakam belirlemekle değil kapsam kesmekle başlar. ✂️
Tek İşi Belirleyin
Uygulamanın çözdüğü asıl işlem ne? Bu netleşmezse kapsam sürekli büyür.
İlk Sürümü Küçültün
“Olsa iyi olur” özellikleri ikinci sürüme bırakın. Bu tek karar en büyük tasarrufu sağlar.
Platform Kararı
Tek platformla başlamak meşru bir tercihtir; teknoloji seçimini türler yazısında ayrıştırdık.
Adım 2: Ekranları Sayın
Bütçenin iskeleti buradan çıkar. 📊
Ekran Listesi Çıkarın
Giriş, liste, detay, form, profil, ayarlar. Her ekran hem tasarım hem geliştirme demektir.
Standart mı, Özel mi?
Liste ve form ekranları öngörülebilirdir. Harita, kamera ve çevrimdışı çalışma ayrı ayrı fiyatlanır.
Yönetim Panelini Unutmayın
İçeriği yöneteceğiniz web arayüzü ayrı bir yazılımdır ve ayrı ekranları vardır.
Adım 3: Backend’i Hesaplayın
Toplamın dörtte birine yaklaşabilen görünmez kalem. 🗄️
| Soru | Etkisi |
|---|---|
| Kullanıcı hesabı var mı? | Backend zorunlu |
| İçerik güncellenecek mi? | Panel gerekli |
| Ödeme alınacak mı? | Entegrasyon ve güvenlik |
| Bildirim gönderilecek mi? | Ek servis ve altyapı |
Veri Listesi Yapın
Ne saklanacak: kullanıcı, sipariş, içerik, mesaj? Bu liste maliyeti doğrudan belirler.
Hazır Servisler
Kimlik doğrulama ve bildirim için hazır servisler, sıfırdan geliştirmekten ucuzdur.
Mevcut Sistem Var mı?
Bir siteniz ya da yönetim sisteminiz varsa uygulamanın ona bağlanması maliyeti düşürebilir.
Adım 4: Yıllık Kalemleri Ekleyin
Bu adım atlanırsa hesap eksik çıkar. 🔧
Bakım
İşletim sistemi uyumu ve hata düzeltmeleri. Genellikle yapım bedelinin bir oranı olarak yıllık hesaplanır.
Sunucu
Aylık gider ve kullanıcı sayısıyla ölçeklenir.
Mağaza Hesapları
Geliştirici hesapları yıllık ücretlidir ve sizin adınıza olmalıdır.
Üçüncü Taraf Servisler
Bildirim, harita ve analiz servisleri kullanım arttıkça ücretlenir; kurgusunu bakım yazısında anlattık.
Adım 5: Üç Yıllık Toplama Ulaşın
Formül tek satırdır: yapım + (yıllık kalemler × 3). 📐
Neden Üç Yıl?
Uygulama bir proje değil ürün. Üç yıl, gerçek maliyeti görünür kılan en kısa süredir.
Şaşırtan Sonuç
Üç yıllık toplam, yapım bedelinin belirgin biçimde üstüne çıkar. Bu tabloyu görmeden alınan karar eksik bilgiye dayanır.
Karşılaştırma Ölçütü
Çıkan rakamı aynı bütçeyle yapılabilecek işlerle kıyaslayın: site yenileme, reklam, içerik.
İkinci Sürüm Payı
İlk sürümden sonra gelecek geliştirmeler için de bir pay ayrılmalıdır.
Bütçeyi Kim Onaylayacak?
Yazılım projelerinde en pahalı gecikme sebebi teknik değil, karar süreçleridir. 👥
Üç madde baştan netleşmelidir.
Tek Karar Verici
Onayı kim verecek? Çok başlı onay, geliştirme sırasında çelişkili talep üretir.
Değişiklik Bütçesi
Kapsam dışı istekler için ayrı bir pay ayrılmalı. Bu pay her projede kullanılır.
Onay Süresi
Tasarım ve test aşamalarında kaç günde dönüş yapılacak? Bu süre takvimi doğrudan belirler; denetimini teklif yazısında yaptık.
Bütçe Yetmezse Ne Yapılır?
Kısıntı rastgele değil, bir sırayla yapılır. 📉
1. Ekran Sayısını Azaltın
İlk sürümde asıl işi yapan ekranlar kalsın. En büyük tasarruf buradadır.
2. Tek Platformla Başlayın
Kitlenizin ağırlıklı olduğu platform yeter. İkincisi sonra eklenir.
3. PWA’yı Değerlendirin
Cihaz özelliği gerekmiyorsa mağazasız bir çözüm çok daha ucuzdur.
Kısılmayacaklar
Test ve bakım. Bu ikisi kısıldığında bedelini kullanıcı ve siz ödersiniz.
Aşamalı Yatırım
Bütçe darsa projeyi parçalara bölmek en akıllı yoldur. 🧩
Aşama 1: Talep Testi
Mobil site ya da PWA ile başlayın. Amaç, kullanıcının bu işlemi gerçekten yapıp yapmadığını görmek.
Aşama 2: Dar Uygulama
Talep kanıtlandıysa yalnızca asıl işi yapan uygulama yazılır.
Aşama 3: Genişleme
Kullanım verisiyle özellik eklenir. Bu sıra israfı önler; zamanlamayı geçiş yazısında ele aldık.
Sık Yapılan Dört Hesap Hatası
Uygulama bütçeleri genellikle aynı dört yerde şaşar. 🚧
Sadece Yapıma Bakmak
Bakım, sunucu ve hesap ücretleri katılmazsa üç yıllık toplam ciddi biçimde eksik çıkar.
Backend’i Unutmak
Veri saklayan her uygulamada sunucu tarafı vardır ve ayrı bir kalemdir.
İkinci Sürümü Planlamamak
İlk sürüm bir tahmindir; geliştirme kaçınılmazdır.
Kendi Zamanınızı Saymamak
İçerik hazırlama, onay ve test sizin saatinizi tüketir; denetimini teklif yazısında yaptık.
Sık Sorulan Sorular
Uygulama bütçesi nasıl hesaplanır?
Beş adımda: kapsamı daraltın ve ilk sürümü küçültün, ekranları sayın, backend ihtiyacını hesaplayın, yıllık kalemleri ekleyin ve üç yıllık toplama ulaşın. Formül şudur: yapım bedeli artı yıllık kalemlerin üç katı. Yalnızca yapım bedeline bakmak, gerçek maliyeti ciddi biçimde eksik gösterir çünkü bakım, sunucu ve mağaza ücretleri her yıl tekrar eder.
Neden üç yıllık hesap yapmalıyım?
Çünkü uygulama bir proje değil üründür. Yapım bedeli tek seferliktir ama bakım, sunucu ve geliştirici hesapları her yıl tekrar eder; ayrıca ikinci sürüm geliştirmeleri kaçınılmazdır. Üç yıllık toplam, yapım bedelinin belirgin biçimde üstüne çıkar. Bu tabloyu görmeden verilen karar eksik bilgiye dayanır.
Bütçe yetmezse neyi kısmalıyım?
Sırayla: ekran sayısını azaltın, tek platformla başlayın ve cihaz özelliği gerekmiyorsa PWA seçeneğini değerlendirin. Kısılmaması gereken iki şey test ve bakımdır; test kısılırsa hatalar kullanıcıya kalır, bakım kısılırsa uygulama zamanla çalışmaz hale gelir. En etkili tasarruf, ilk sürümü yalnızca asıl işi yapan ekranlarla sınırlamaktır.