Mobil Uygulama Fiyatları Tekliflerinde App Store Yayını, Bakım ve Sürüm Güncellemeleri Nasıl Karşılaştırılır?

Mobil uygulama teklif fiyatları neden kapsamla okunmalı?

Mobil uygulama teklif fiyatları, geliştirme bedelinin yanında yayın, bakım ve işletim sorumluluklarıyla birlikte okunmalıdır. İlk sürüm daha düşük maliyetli görünse bile mağaza yayını, sürüm takibi veya hata müdahalesi kapsam dışındaysa proje yaşam döngüsünde beklenmeyen iş kalemleri oluşabilir. Bu nedenle teklifin “uygulamayı geliştirme” ile “uygulamayı çalışır ve güncel tutma” sorumluluklarını nasıl ayırdığı açıkça görülmelidir.

İlk fiyat ile toplam hizmet kapsamını ayırın

Teklifleri aynı satır başlıklarıyla karşılaştırmak, farklı sağlayıcıların kullandığı paket isimlerinden kaynaklanan belirsizliği azaltır. Özellikle mobil uygulama geliştirme tekliflerinde fiyatın ötesindeki kritik maddeleri ayrı incelemek; teslimat, yayın, destek ve sahiplik konularını aynı karar tablosunda görmeyi kolaylaştırır. Bir kalemin “dahil” yazması kadar, kaç sürümü, hangi platformu ve hangi müdahale türünü kapsadığı da önemlidir.

• İlk geliştirme ve ilk mağaza yayını ayrı satırlarda gösterilmeli
• Bakım başlangıç tarihi ve kapsam süresi tanımlanmalı
• Hata düzeltme ile yeni özellik geliştirme birbirinden ayrılmalı
• Üçüncü taraf servis ve lisans sorumlulukları belirtilmeli
• Mağaza incelemesi sonrası düzeltmelerin kapsamı açıklanmalı
• Yıllık işletim kalemleri ilk yatırım maliyetinden ayrıştırılmalı

An ounce of prevention is worth a pound of cure.- Benjamin Franklin

App Store ve Google Play yayını teklife nasıl yazılmalı?

App Store yayın hizmeti ve Google Play yayın hizmeti, projede mağaza dağıtımı bekleniyorsa teklifte açık bir iş paketi olarak tanımlanmalıdır; ancak her projede otomatik olarak aynı kapsamda olmak zorunda değildir. Teklif; ilk gönderimi, mağaza varlıklarının hazırlanmasını, teknik paketlemeyi, inceleme geri bildirimlerine verilecek yanıtı ve onay sonrası yayın kontrolünü hangi tarafın yürüteceğini belirtmelidir.

Yayın hizmetinin sınırlarını teslimattan önce netleştirin

Kurumsal projelerde “yayına hazır teslim” ile “mağazada canlıya alma” farklı sorumluluklar olabilir. ihtiyaç analizinden mağaza yayınına kadar mobil uygulama sürecini birlikte değerlendirmek, teklifin nerede bittiğini ve operasyonel sorumluluğun nerede başladığını gösterir. Ekran görüntüleri, mağaza açıklamaları, kategori bilgileri, gizlilik beyanları ve inceleme sonrası teknik düzeltmeler gibi teslimlerin kimin tarafından hazırlanacağı sözleşmede isimlendirilmelidir.

• iOS ve Android için ilk mağaza gönderimi
• Mağaza metinleri ve görsel varlıkların hazırlanma sorumluluğu
• Test sürümleri ile üretim sürümünün ayrımı
• İnceleme geri bildirimlerine teknik yanıt ve yeniden gönderim
• Yayın tarihi ve kademeli yayın kararının yetkili tarafı
• İlk yayın sonrası doğrulama ve kritik hata kontrolü

Mağaza hesapları ve erişimler kimin adına tutulmalı?

Mağaza hesapları mümkün olduğunda uygulamanın sahibi olan müşteri kuruluş adına açılmalı, yazılım firması ise gerekli rol ve yetkilerle davet edilmelidir. Bu yapı; uygulamanın mağaza geçmişi, kullanıcı yorumları, sürüm kayıtları ve yayın yetkisinin sağlayıcı değişse bile müşteri kontrolünde kalmasını sağlar. Kişisel veya yalnızca ajansa ait hesaplarda yayın yapmak, devir teslim sürecini gereksiz biçimde zorlaştırabilir.

Sertifika, imzalama anahtarı ve yetki modelini belgeleyin

Hesap sahipliği tek başına yeterli değildir; sertifikalar, imzalama anahtarları, ekip rolleri, iki aşamalı doğrulama sorumlulukları ve kurtarma yöntemleri de kayıt altına alınmalıdır. Geliştirici ekip günlük operasyon için gereken minimum yetkiyle çalışırken, ana sahiplik ve kritik kurtarma kanalları müşteri tarafında kalmalıdır. Personel değişikliklerinde erişimlerin kapatılması ve yeni yetkililerin eklenmesi için de basit bir yönetim prosedürü tanımlanmalıdır.

• Apple ve Google geliştirici hesaplarının kurumsal sahipliği
• Yönetici, geliştirici ve yayın rollerinin ayrımı
• Sertifika ve imzalama anahtarlarının güvenli yönetimi
• İki aşamalı doğrulama ve kurtarma bilgilerinin sorumluluğu
• Çalışan veya sağlayıcı değişiminde erişim kapatma süreci
• Mağaza hesaplarının devir teslim prosedürü

Mobil uygulama bakım kapsamı hangi işleri ayırmalı?

Mobil uygulama bakım fiyatları ancak kapsamın hangi iş türlerini içerdiği açık olduğunda anlamlı biçimde karşılaştırılabilir. Garanti kapsamındaki kusur düzeltmeleri, üretim ortamındaki hata müdahaleleri, güvenlik güncellemeleri, platform uyumluluğu ve yeni özellik talepleri aynı hizmet değildir. Teklifte bu kategorilerin birbirinden ayrılması, bakım paketinin gerçekte hangi operasyon yükünü üstlendiğini gösterir.

Bakım ile geliştirme talebini aynı havuzda eritmeyin

Uygulama bakım sözleşmesi, “küçük geliştirme” gibi yoruma açık ifadeler yerine ölçülebilir hizmet sınıfları kullanmalıdır. Bir form alanının değiştirilmesi, üçüncü taraf SDK geçişi, işletim sistemi kaynaklı uyarlama veya yeni iş akışı eklenmesi farklı efor ve risk seviyelerine sahiptir. Değişiklik talebinin bakım kotasından mı düşeceği, ayrı analiz mi gerektireceği ve üretime alma sorumluluğunun kimde olduğu baştan açıklanmalıdır.

• Garanti kapsamındaki hata düzeltmeleri
• Üretim hataları için destek ve müdahale
• Güvenlik yamaları ve bağımlılık güncellemeleri
• İşletim sistemi ve cihaz uyumluluk çalışmaları
• Küçük değişiklik talepleri için kapasite modeli
• Yeni özelliklerin ayrı geliştirme süreci

Yeni işletim sistemi sürümleri bakımda nasıl planlanır?

Yeni iOS ve Android sürümleri için bakım, yayın takvimi yaklaşmadan başlayan uyumluluk kontrolü ve gerektiğinde güncelleme geliştirmesi olarak planlanmalıdır. Mobil uygulama güncelleme maliyeti; kullanılan framework, yerel platform bağımlılıkları, üçüncü taraf SDK’lar, cihaz özellikleri ve backend sözleşmeleri gibi teknik bileşenlerden etkilenir. Bu nedenle “tüm sürüm güncellemeleri dahil” gibi sınırsız ifadeler yerine sorumluluk ve kapsam sınırları belirlenmelidir.

Teknoloji seçiminin bakım yükünü nasıl etkilediğini inceleyin

Native, cross-platform veya PWA yaklaşımı yalnızca ilk geliştirmeyi değil, sürüm uyumluluğu ve bağımlılık güncellemelerinin yönetimini de etkiler. mobil uygulama için teknoloji seçimi rehberi, teklifleri bakım perspektifiyle okurken hangi mimari bağımlılıkların takip edilmesi gerektiğini anlamaya yardımcı olur. Sağlayıcıdan desteklenen platform sürümleri, test cihazı kapsamı ve eski sürümler için destek politikasını açıklaması istenmelidir.

• Yeni işletim sistemi beta ve kararlı sürüm takibi
• Framework ve paket bağımlılıklarının uyumluluk kontrolü
• Platform SDK ve API değişikliklerinin değerlendirilmesi
• Temel kullanıcı akışlarında regresyon testleri
• Desteklenecek minimum işletim sistemi sürümünün belirlenmesi
• Uyumsuzluk durumunda düzeltme ve yeniden yayın süreci

Crash takibi ve güvenlik bakımı tekliflerde nasıl görünür?

Crash takibi, güvenlik bakımı ve üretim gözlemlenebilirliği uygulama destek hizmetinin ayrı ve görünür bileşenleri olmalıdır. Bir uygulamanın mağazada yayınlanmış olması, üretim ortamında sağlıklı çalıştığının sürekli doğrulandığı anlamına gelmez. Teklif; kritik çökme kayıtlarının izlenmesini, hata önceliklendirmesini, güvenlik güncellemelerini ve sürüm sonrası kontrolü kimin yürüteceğini tanımlamalıdır.

Sadece müdahale değil izleme sorumluluğunu da karşılaştırın

Bakım modelinde kullanılan izleme araçlarının kurulumu, bildirim alıcıları ve olay kayıtlarının saklanması da önemlidir. Sağlayıcının yalnızca müşteri hata bildirince çalışması ile proaktif crash takibi yapması aynı hizmet kapsamı değildir. Ayrıca mobil istemci, API ve üçüncü taraf servisler arasındaki hataların hangi ekip tarafından ayrıştırılacağı belirlenmeli; güvenlik açığı veya kritik hata için normal değişiklik taleplerinden farklı bir önceliklendirme mekanizması bulunmalıdır.

• Crash ve hata izleme aracının kurulumu
• Kritik olaylar için bildirim ve önceliklendirme
• Güvenlik yamalarının değerlendirme ve uygulama süreci
• Backend ve üçüncü taraf servis kaynaklı hataların ayrıştırılması
• Sürüm sonrası temel sağlık kontrolleri
• Kritik düzeltmeler için acil yayın prosedürü

Uygulama bakım sözleşmesi hangi hizmet seviyelerini içermeli?

Uygulama bakım sözleşmesi; kapsanan hizmetleri, çalışma modelini, müdahale önceliklerini ve kapsam dışı işleri tanımlamalıdır. Saat paketi, aylık ayrılmış kapasite veya olay bazlı destek gibi modellerin hiçbiri tek başına doğru ya da yanlış değildir; önemli olan uygulamanın operasyon ihtiyacıyla uyumlu olması ve tekliflerin aynı hizmet seviyesi üzerinden karşılaştırılmasıdır.

Destek modeli firma seçiminde teknik kriter olmalıdır

Bir mobil yazılım firması değerlendirilirken yalnızca geliştirme ekibinin yetkinliği değil, canlı sistem desteğinin nasıl organize edildiği de incelenmelidir. teklif ve destek kriterleriyle mobil uygulama firması seçimi bu açıdan yararlı bir karşılaştırma çerçevesi sunar. Kritik, yüksek, orta ve düşük öncelikli taleplerin nasıl sınıflandırıldığı; hangi kanaldan kayıt açıldığı ve raporlamanın nasıl yapıldığı sözleşmede yer almalıdır.

• Destek saatleri ve iletişim kanalları
• Öncelik seviyeleri ve hedef müdahale yaklaşımı
• Bakım kapasitesinin aylık veya dönemsel tanımı
• Kapsam dışı işlerin onay ve fiyatlandırma yöntemi
• Yapılan işlerin periyodik raporlanması
• Sözleşme bitiminde devir teslim sorumlulukları

Kaynak kodu ve CI/CD sahipliği neden teklif kriteridir?

Kaynak kodu, kod deposu, CI/CD süreci ve mağaza erişimlerinin müşteri kontrolünde olması, sağlayıcı değişikliği ve iş sürekliliği açısından temel teklif kriteridir. CI/CD, kodun test edilmesi, paketlenmesi ve dağıtım adımlarının tekrarlanabilir bir akışla yönetilmesidir. Bu varlıklar yalnızca geliştiricinin kişisel hesabında tutulduğunda yeni bir ekibin projeyi devralması zorlaşabilir.

Devir teslimi sözleşmenin sonuna bırakmayın

Teklifte sahiplik ve devir maddelerini ilk günden tanımlamak, proje sonunda yapılacak teknik aktarımı kolaylaştırır. mobil uygulama tekliflerinde kapsam, sözleşme ve sahiplik kontrolü yapılırken depo erişimi, ortam değişkenleri, build süreçleri, mağaza rolleri ve teknik dokümantasyon birlikte değerlendirilmelidir. Müşterinin kontrolü, geliştiricinin operasyon yapmasını engellemez; aksine yetkilerin kurumsal bir zeminde yönetilmesini sağlar.

• Kaynak kod deposunun kurumsal erişim modeli
• Build ve yayın otomasyonunun dokümantasyonu
• Gizli anahtarlar ve ortam değişkenlerinin yönetimi
• Test ve üretim ortamlarının erişim sahipliği
• Mağaza hesaplarıyla CI/CD bağlantılarının kaydı
• Sağlayıcı değişikliğinde teknik devir kontrol listesi

Teklifler toplam yıllık maliyete göre nasıl karşılaştırılır?

Mobil uygulama teklifleri, ilk geliştirme maliyeti ile ilk yıl ve devam eden işletim sorumlulukları ayrı gösterilerek karşılaştırılmalıdır. Sağlıklı bir değerlendirme; geliştirme, ilk yayın, bakım, destek kapasitesi, sürüm güncellemeleri, üçüncü taraf servisleri ve gerektiğinde bulut veya backend işletimini aynı dönemsel çerçevede toplar. Böylece daha düşük ilk teklif ile daha düşük toplam sahip olma maliyetinin aynı şey olmadığı görülebilir.

Aynı kapsam satırlarıyla karşılaştırılabilir teklif isteyin

Firmalardan tek toplam rakam yerine kapsam kalemlerini ve dönemsel sorumlulukları ayrı göstermelerini istemek daha şeffaf bir karşılaştırma sağlar. Her teklif için hangi hizmetin dahil, sınırlı veya ayrıca fiyatlandırılacağını işaretlemek; yayın ve bakım sorumluluklarını görünür kılar. Son kararda yalnızca maliyet değil, sahiplik, müdahale modeli, teknik devir kolaylığı ve uygulamanın sürdürülebilir biçimde güncel tutulması birlikte değerlendirilmelidir.

• İlk geliştirme ve kabul süreci
• App Store ve Google Play ilk yayın hizmetleri
• Yıllık veya dönemsel bakım ve destek kapsamı
• İşletim sistemi ve SDK güncelleme sorumluluğu
• Üçüncü taraf servis, altyapı ve lisans kalemleri
• Devir teslim ve sağlayıcı değişikliği hazırlığı