Mobil Uygulama Bakım ve Güncelleme Maliyeti Nasıl Hesaplanır

Geliştirme maliyeti bir teklif belgesinde net bir sayı olarak durur; bakım maliyeti ise çoğu zaman hiç konuşulmaz, ta ki ilk yıl sonunda müşteri "neden hâlâ para ödüyorum" diye sorana kadar. Bu yazı o soruya baştan cevap vermek için.

İşletim Sistemi Güncellemeleri: Yıllık Kaçınılmaz Bir Kalem

Apple her yıl Eylül-Ekim döneminde yeni iOS sürümü çıkarıyor, Google da benzer bir takvimle Android güncellemesi yayınlıyor. Bu güncellemeler bazen küçük görsel uyumsuzluklara (buton konumu kayması gibi) bazen de doğrudan kod kırılmasına (deprecated API kullanımı, izin sisteminde değişiklik) yol açıyor. Bir uygulamayı yayınladıktan sonra hiç dokunmamak, iki yıl içinde "App Store'da yeni sürümlere destek vermiyor" uyarısı almak anlamına gelebiliyor.

Gerçekçi bir beklenti: yılda en az 2 kez (bir büyük OS güncellemesi sonrası, bir de rutin kontrol amaçlı) uygulamanın yeni cihaz ve OS sürümleriyle test edilmesi gerekiyor. Bu test-düzelt döngüsü, uygulamanın karmaşıklığına göre birkaç günden birkaç haftaya kadar sürebiliyor.

Sunucu Maliyeti: Kullanıcı Sayısıyla Doğrusal Artmıyor

Küçük bir uygulama için aylık sunucu maliyeti başlangıçta düşük görünüyor ama kullanıcı sayısı, veri hacmi ve özellikle bildirim/medya trafiği arttıkça bu kalem katlanarak büyüyebiliyor. Örneğin bin kullanıcılı bir uygulamada sunucu maliyeti aylık düşük bir tutarken, 50 bin kullanıcıya çıkıldığında veritabanı sorgu yükü, dosya depolama ve CDN maliyeti orantısız şekilde artabiliyor — bunun sebebi genelde kötü tasarlanmış veritabanı sorguları veya optimize edilmemiş medya dosyalarıdır.

Bu kalemi baştan bütçelemek için "kullanıcı başına aylık maliyet" değil, "beklenen trafik senaryosu başına maliyet" hesaplamak daha isabetli. Push bildirim servisi, harita API çağrıları, SMS doğrulama gibi üçüncü parti servislerin kullanım bazlı fiyatlandırması da bu hesaba dahil edilmeli, çoğu proje bu kalemleri unutup sadece sunucu barındırma maliyetini hesaplıyor.

Yıllık Bakım Bütçesi: Yüzde Üzerinden Kaba Bir Kural

Sektörde yaygın kullanılan bir kaba kural, ilk geliştirme maliyetinin yüzde 15-20'sinin yıllık bakım için ayrılmasıdır. Bu oran; hata düzeltmeleri, küçük özellik iyileştirmeleri, OS uyumu ve güvenlik yamalarını kapsar, yeni büyük özellik geliştirmeyi kapsamaz. Yeni özellik talepleri ayrı bir kalem olarak ele alınmalı, aksi halde bakım bütçesi hızla tükenip acil hata düzeltmeleri için kaynak kalmıyor.

Bu bütçeyi hiç ayırmayan firmalarda genelde şu döngü yaşanıyor: uygulama bir süre sorunsuz çalışır, sonra bir OS güncellemesiyle birlikte çöker, acil bir bakım talebi doğar ve bu talep planlanmadığı için normalden daha pahalıya, daha stresli bir süreçte çözülür. Önceden ayrılmış bir bütçe ve düzenli bakım anlaşması bu senaryoyu büyük ölçüde önlüyor.

Platform Bazlı Fark

Android Uygulama Geliştirme tarafında cihaz çeşitliliği (farklı ekran boyutu, üretici arayüz katmanları) test yükünü artırırken, iOS Uygulama Geliştirme tarafında Apple'ın daha sıkı inceleme süreci güncelleme onay süresini uzatabiliyor. İki platformu birlikte yürüten projelerde Android + iOS Çift Platform Paketi bakım sürecini tek bir kod tabanında tutarak maliyeti azaltabiliyor. Başlangıç ve bakım maliyeti kalemlerinin kırılımı için Mobil Uygulama Fiyatları Rehberi sayfasına göz atabilirsiniz.

Bakım Maliyeti Bütçe Planlama Güncelleme Stratejisi Mobil Uygulama Sunucu Maliyeti