Mobil Uygulama Teklifi: Fiyatlandırma ve Kapsam Yönetimi

Bir müşteri sana "mobil uygulama yapar mısın, kaç para" diye yazdığında verdiğin ilk rakam, projenin kaderini belirler. Yanlış model seçilmiş bir teklif — kapsamı yazılı tanımlamayan, varsayımları not etmeyen, mağaza yayın ve bakım kalemlerini unutan bir teklif — ne kadar iyi kodlarsan kodla seni zarara sokar. Bu yazıda mobil uygulama proje teklifini uçtan uca kuruyoruz: keşif brifinden fiyatlandırma modeline, kapsam tanımından değişiklik talebi sürecine kadar.

💡 Pro Tip: Teklifini göndermeden önce müşteriye "bu kapsamda olmayan" listesini de gönder — asıl anlaşmazlıklar çoğu zaman "dahil" listesinde değil, hiç konuşulmamış "hariç" listesinde çıkar.

İçindekiler

• Teklif öncesi keşif: 12 soruluk brief
• Platform ve hedef kitle soruları
• İş modeli ve bütçe soruları
• Kapsam ve bakım soruları
• Tahmin yöntemleri ve belirsizlik payı
• Ekran/özellik bazlı ayrıştırma
• Üç-nokta tahmin (en iyi/en olası/en kötü)
• Geçmiş projelerden referans almak
• Sabit fiyat, saatlik ve aşamalı model: hangisi hangi işte
• Sabit fiyat ne zaman işe yarar
• Saatlik ücret ne zaman işe yarar
• Aşamalı model ne zaman işe yarar
• Hibrit yaklaşım
• Kapsam tanımı: dahil olan, olmayan ve varsayımlar
• Dahil olan (in-scope)
• Hariç olan (out-of-scope)
• Varsayımlar (assumptions)
• Üç listenin birlikte çalışması
• Mağaza yayın, hesap ve bakım kalemlerinin fiyata etkisi
• Apple tarafı hesap ücretleri
• Google Play tarafı hesap ücretleri
• İnceleme öncesi bakım/uyum yükü
• Neden bu bir fiyatlandırma kalemi
• Değişiklik talebi süreci ve ek iş yazışması
• Değişiklik talebini yazılı hale getirme
• Onay öncesi çalışmama kuralı
• Küçük istekler için eşik belirleme
• Teklif şablonu iskeleti
• SSS
• Mobil uygulama projesi nasıl fiyatlandırılır?
• Sabit fiyat mı saatlik mi çalışmalıyım?
• Kapsam kaymasını nasıl önlerim?
• Müşteri App Store/Play Console hesabına kim sahip olmalı?
• Teklif şablonunda hangi bölümler olmazsa olmaz?
• Güncelleme (Eylül 2026)
• Sonuç
• Kaynaklar

Teklif öncesi keşif: 12 soruluk brief

Teklif yazmadan önce topladığın bilgi, teklifin kendisinden daha değerlidir. Aşağıdaki 12 soru, bir mobil uygulama projesinde fiyatlandırmayı doğrudan etkileyen değişkenleri yakalamak için tasarlandı — her biri eksik kalırsa sonradan "ek iş" tartışmasına dönüşür.

Platform ve hedef kitle soruları

• Hangi platform(lar)?: Yalnız iOS mu, yalnız Android mı, yoksa ikisi birden mi? Cross-platform bir framework (Flutter, React Native) mi yoksa native mi bekleniyor?
• Hedef pazar neresi?: Tek ülke mi, çok bölgeli mi? Çok dilli arayüz gerekiyor mu?
• Mevcut bir backend var mı?: Sıfırdan API mi yazılacak, yoksa var olan bir sisteme mi bağlanılacak?
• Kimlik doğrulama nasıl olacak?: E-posta/şifre mi, sosyal giriş mi, kurumsal SSO mu?

İş modeli ve bütçe soruları

• Gelir modeli ne?: Uygulama içi satın alma, abonelik, reklam, yoksa ücretsiz bir kurumsal araç mı?
• Bütçe aralığı belirlendi mi?: Müşteri bir üst sınır söylemiyorsa, sen bir aralık önererek konuşmayı başlat.
• Teslim tarihi sabit mi esnek mi?: Bir konferans/lansman tarihine bağlıysa bu, fiyatlandırma modelini doğrudan etkiler (bkz. aşağıdaki bölüm).

Kapsam ve bakım soruları

• Tasarım hazır mı?: Figma/Sketch dosyası var mı, yoksa UI da senin kapsamında mı?
• Kim App Store/Play Console hesabına sahip olacak?: Müşterinin kendi hesabı mı, senin aracılığınla mı açılacak?
• Yayın sonrası bakım kim üstlenecek?: Tek seferlik teslim mi, aylık bakım anlaşması mı?
• Test cihazları/kullanıcıları kimde?: TestFlight/Play Console dahili test grubunu kim yönetecek?
• Değişiklik talebi süreci nasıl işleyecek?: Kapsam dışı bir istek geldiğinde onay mekanizması ne olacak? (Detay: aşağıdaki "Değişiklik talebi" bölümü.)

Bu 12 soruya verilen yanıtlar, teklifinin "Kapsam" bölümünün iskeletini oluşturur — bir sonraki adım bu yanıtları sayıya çevirmek.

Tahmin yöntemleri ve belirsizlik payı

Bir mobil uygulama projesini "kaç günde biter" diye tek bir sayıyla tahmin etmek, kapsam kaymasının ilk kapısıdır. İki tamamlayıcı yöntem birlikte kullanıldığında daha güvenilir bir tahmin çıkar.

Ekran/özellik bazlı ayrıştırma

Uygulamayı ekran ve özellik listesine böl, her birine ayrı ayrı efor tahmini ver. Bir giriş ekranı bir saatte bitebilirken, bir "offline senkronizasyon" özelliği günler alabilir — tek bir toplam rakam bu farkı gizler, ayrıştırılmış liste gizlemez. Aşağıdaki tablo örnek bir ayrıştırmadır — rakamlar senin hız/stack verinle değişir:

Üç-nokta tahmin (en iyi/en olası/en kötü)

Her kalem için tek rakam yerine üç rakam ver: en iyi durum, en olası durum, en kötü durum. Bu, belirsizlik payını görünür kılar ve müşteriyle "neden bu kadar sürüyor" tartışmasını daha başlamadan önler. Aşağıdaki tablo da örnek bir ayrıştırmadır — rakamlar senin hız/stack verinle değişir:

Üç rakamı tek bir ağırlıklı ortalamaya indirmek için PERT formülünü (en iyi + 4×en olası + en kötü) / 6 kullanabilirsin — bu, "en olası"ya daha fazla ağırlık verirken uç senaryoları da hesaba katar:

1function pertEstimate(best: number, likely: number, worst: number): number {
2  return (best + 4 * likely + worst) / 6;
3}
4 
5// Ödeme entegrasyonu: (3 + 4*4 + 7) / 6
6console.log(pertEstimate(3, 4, 7)); // 4.333333333333333 (≈ 4,33 gün)
7 
8// Offline senkronizasyon: (4 + 4*5 + 9) / 6
9console.log(pertEstimate(4, 5, 9)); // 5.5 gün

Çıkan 4,33 ve 5,5 günlük rakamlar, "en olası" tahmininden (4 ve 5 gün) biraz daha yüksektir — aradaki fark, belirsizlik payının somut karşılığıdır.

En olası rakamı teklife yaz, ama iç hesaplamanda en kötü durumu da tut — belirsizlik payını (buffer) ayrı bir kalem olarak (örn. toplam eforun %15-20'si) teklife ekle, gizli bir "şişirme" olarak değil, açık bir satır olarak. Müşteri neye para ödediğini görsün: geliştirme, artı öngörülemeyen riskler için pay.

Geçmiş projelerden referans almak

Elindeki en güçlü tahmin aracı, daha önce tamamladığın benzer projelerin gerçek süreleridir. "Bu proje geçen sefer tahmin ettiğimden %30 uzun sürdü" notunu her proje sonunda tut — bu, bir sonraki tahminin buffer oranını kalibre eder. Ben genelde yeni bir müşteri/teknoloji kombinasyonunda buffer'ı yükseltirim, tekrarlayan bir müşteri/stack'te düşürürüm.

Sabit fiyat, saatlik ve aşamalı model: hangisi hangi işte

Üç model de geçerlidir — soru "hangisi daha iyi" değil, "bu proje için hangisi doğru risk dağılımını kurar" sorusudur.

Sabit fiyat ne zaman işe yarar

Kapsamı net yazılı tanımlayabildiğin, daha önce benzerini yaptığın ve süresi kısa (birkaç hafta) projelerde sabit fiyat hem sana hem müşteriye rahatlık verir. Riski sen üstlenirsin: efor tahminini aşarsan kârın erir, bu yüzden sabit fiyat verirken bir önceki bölümdeki belirsizlik payını mutlaka teklife dahil et.

Saatlik ücret ne zaman işe yarar

Kapsamın henüz netleşmediği, keşif/prototipleme ağırlıklı ya da uzun soluklu bakım işlerinde saatlik ücret daha dürüst bir modeldir — kapsamı zorla sabitlemeye çalışmak, ileride "bu da dahildi" tartışmalarına yol açar. Saatlik modelde haftalık/aylık üst sınır (cap) koymak, müşterinin bütçe kontrolünü kaybetme endişesini azaltır.

Aşamalı model ne zaman işe yarar

Orta-büyük ölçekli projelerde aşamalı (milestone) fiyatlandırma, her iki tarafın da riskini böler: her aşama sonunda somut bir teslim (örneğin "MVP: giriş + ana akış" veya "Faz 2: ödeme entegrasyonu") olur, müşteri o aşamayı onaylayıp ödedikten sonra bir sonrakine geçilir. Bu model özellikle "MVP önce, sonra genişlet" senaryolarında teklif şablonuna doğal olarak oturur.

Hibrit yaklaşım

Ben genelde keşif/tasarım aşamasını saatlik, geliştirme aşamasını (kapsam netleştikten sonra) sabit fiyatlı aşamalara böler, bakım anlaşmasını ayrı bir saatlik/aylık paket olarak sunarım — bu üçü tek bir teklif içinde üç ayrı bölüm olarak durabilir.

Kapsam tanımı: dahil olan, olmayan ve varsayımlar

Bir teklifte en çok anlaşmazlık yaratan bölüm, "kapsam" başlığının kendisidir — çünkü çoğu geliştirici yalnızca "dahil" listesini yazar, "hariç" ve "varsayım" listelerini atlar. Üç liste birlikte olmadan kapsam tanımı eksiktir.

Dahil olan (in-scope)

Bu liste, teklifte yer alan her ekranı, akışı ve entegrasyonu somut isimleriyle sayar: "Giriş/kayıt ekranı", "Ana liste + detay akışı", "Push bildirim gönderimi (tek segment)", "Ödeme entegrasyonu (tek sağlayıcı)". Genel ifadeler ("uygulama içi bildirimler") yerine somut kapsam ("günde en fazla 1 kampanya bildirimi, A/B testi hariç") yaz.

Hariç olan (out-of-scope)

Müşterinin "bu da olur sanıyordum" diyebileceği her şeyi burada açıkça listele. Örneğin bildirim gönderiminin kapsamda olduğunu ama gönderim zamanlaması ve içerik optimizasyonu deneylerinin (bkz. push izin oranı optimizasyonu) ayrı bir kalem olduğunu yazmak, ileride "neden bildirimler optimize değil" tartışmasını önler. Aynı şekilde bir A/B test altyapısı kurulumu (bkz. mobil A/B test altyapısı) veya kullanıcı elde tutma/attribution ölçümü (bkz. mobil attribution ve MMP rehberi, retention metrikleri D1/D7/D30) genellikle temel MVP kapsamının dışındadır — müşteri bunları istiyorsa ayrı bir kalem olarak fiyatlandırılmalı.

Varsayımlar (assumptions)

Teklifin dayandığı ama müşteriyle henüz teyit edilmemiş noktaları buraya yaz: "Tasarım dosyaları teklif kabul tarihinden itibaren 5 iş günü içinde teslim edilecek", "Backend API'leri müşteri tarafından sağlanacak ve dokümante edilmiş olacak", "Test cihazları müşteri tarafından temin edilecek". Bir varsayım gerçekleşmezse (örneğin tasarım geç gelirse) bu, teslim tarihini de değiştirir — varsayımlar listesi, bu bağımlılığı yazılı hale getirir.

Üç listenin birlikte çalışması

Dahil/hariç/varsayım üçlüsü, kapsam kaymasının en yaygın kaynağı olan "sözlü konuşulmuş ama yazılmamış" beklentileri ortadan kaldırır. Teklif onaylandıktan sonra bu üç liste, değişiklik talebi sürecinin (bir sonraki bölüm) referans noktası olur: bir istek "hariç" listesindeyse otomatik olarak ek iş sayılır.

Mağaza yayın, hesap ve bakım kalemlerinin fiyata etkisi

Bu bölümdeki rakamlar Apple ve Google'ın resmi program ücretleridir; teklifine "platform maliyetleri" başlığı altında ayrı bir satır olarak ekle.

Apple tarafı hesap ücretleri

Apple Developer Program'a bireysel veya organizasyon olarak kaydolabilirsin; program yıllık 99 dolardır, kurumsal iç dağıtım gerektiren Apple Developer Enterprise Program ise yıllık 299 dolardır. Sınırlı erişimli ücretsiz bir hesap seçeneği de var ama App Store'da yayın için ücretli üyelik gerekir. Bu ücret müşteriye mi ait olacak yoksa senin hesabından mı yayınlanacak — bunu teklifte netleştir, çünkü hesap sahipliği aynı zamanda uygulamanın uzun vadeli kontrolünü de belirler.

Google Play tarafı hesap ücretleri

Google Play geliştirici hesabı açmak için tek seferlik 25 dolar kayıt ücreti alınır; Kişisel (Personal) ve Kurumsal (Organization) olmak üzere iki hesap türü vardır. 13 Kasım 2023 sonrası açılan kişisel hesaplar, uygulamayı yayınlamadan önce belirli test şartlarını karşılamak zorunda; 2024 başından itibaren de yeni kişisel hesapların Play Console mobil uygulaması üzerinden bir Android cihaza erişimini doğrulaması gerekiyor. Bu adımlar teklif zaman çizelgesine "hesap doğrulama süresi" olarak eklenmeli — bkz. Google Play politika uyum rehberi.

İnceleme öncesi bakım/uyum yükü

Mağaza incelemesini geçmek, kodun bitmesinden ayrı bir iştir ve teklifte kendi satırını hak eder:

• Demo hesap zorunluluğu: Hesap tabanlı özellikleri olan uygulamalarda aktif bir demo hesap veya tam işlevli demo modu sağlanmalı, backend servisleri inceleme sırasında canlı olmalı.
• TestFlight, App Store'un yerine geçmez: Demo/beta/deneme sürümleri App Store'a değil TestFlight'a konur — müşteri "önce App Store'da test edelim" derse bu adımı düzeltmen gerekir.
• Gizli özellik yasağı: Uygulamada gizli/pasif/belgesiz özellik bulunamaz; yeni özellik ve işlevler App Store Connect'in "Notes for Review" alanında özel olarak açıklanmalı, genel ifadeler reddedilir.
• Uygulama adı sınırı: Uygulama adları en fazla 30 karakterle sınırlıdır — marka isimlendirmesini erken netleştir.
• İletişim ve gizlilik politikası: Uygulama ve Support URL'i kolay erişilebilir bir iletişim yolu içermeli; gizlilik politikası bağlantısı hem App Store Connect metadata alanında hem de uygulama içinde bulunmalıdır.
• Age rating dürüstlüğü: Yaş derecelendirme soruları App Store Connect'te dürüstçe yanıtlanmalı, ebeveyn kontrolleriyle uyumlu olmalıdır.

Neden bu bir fiyatlandırma kalemi

Bu maddelerin çoğu tek seferlik gibi görünür ama her mağaza güncellemesinde tekrar kontrol edilmesi gerekir (isim/açıklama değişikliği, yeni özellik, gizlilik politikası güncellemesi). Teklifine "ilk yayın hazırlığı" (demo hesap kurulumu, metadata, gizlilik politikası bağlantısı) ile "yayın sonrası bakım" (her güncellemede yeniden inceleme riski) için ayrı satırlar aç — bu, "neden basit bir güncelleme bu kadar sürüyor" sorusunu daha teklif aşamasında cevaplar.

Değişiklik talebi süreci ve ek iş yazışması

Kapsam ne kadar iyi yazılırsa yazılsın, her projede en az bir "bunu da ekleyebilir miyiz" anı gelir. Sorun değişiklik talebinin kendisi değil, onu yönetecek bir sürecin olmamasıdır.

Değişiklik talebini yazılı hale getirme

Sözlü ya da mesajlaşma uygulamasında gelen bir istek, resmi bir değişiklik talebine dönüşmeden çalışmaya başlanmamalı. Basit bir şablon, hem seni hem müşteriyi korur:

1{
2  "talepNo": "CR-03",
3  "tarih": "2025-04-18",
4  "istek": "Ana ekrana favori listesi eklensin",
5  "kapsamDurumu": "hariç-listede-yok",
6  "etkilenenEkranlar": ["Ana liste", "Detay ekranı"],
7  "tahminiEfor": "2 gün",
8  "teslimTarihiEtkisi": "+2 iş günü",
9  "onayDurumu": "musteri-onayi-bekleniyor"
10}

kapsamDurumu alanı, isteğin orijinal "dahil" listesinde olup olmadığını gösterir — eğer "hariç-listede-yok" ise bu otomatik olarak ek iş demektir ve ayrı ücretlendirilir. Bu şablonu bir e-posta ekinde ya da paylaşılan bir tabloda tutmak, ay sonunda "bunu da yaptık ama faturaya yansımadı" kaybını önler.

Onay öncesi çalışmama kuralı

Değişiklik talebi onaylanmadan (yazılı "evet, ek ücreti kabul ediyorum" almadan) o işe başlamama kuralını baştan teklife yaz. Aksi halde "zaten yapmışsın, şimdi neden para istiyorsun" tartışmasına düşersin — yazılı onay, bu tartışmayı daha talep aşamasında kapatır.

Küçük istekler için eşik belirleme

Her küçük metin/renk değişikliği için ayrı bir CR süreci işletmek pratik değildir. Teklife bir "küçük düzeltme eşiği" yaz: örneğin "yarım günden az süren metin/ikon değişiklikleri ek ücretsiz, proje süresince toplam 2 saate kadar dahildir; üzeri ayrı ücretlendirilir." Bu eşik, hem esneklik sağlar hem de sınırsız "ufak ricalar" birikmesini önler.

Teklif şablonu iskeleti

Yukarıdaki tüm bölümleri tek bir belgede toplayan iskelet şöyle görünür:

1Başlık: Mobil Uygulama Geliştirme Teklifi
2 
3BÖLÜM 1 — Proje Özeti
4  (Müşterinin ihtiyacının 2-3 cümlelik özeti)
5 
6BÖLÜM 2 — Kapsam
7  Alt-başlık: Dahil Olan
8  Alt-başlık: Hariç Olan
9  Alt-başlık: Varsayımlar
10 
11BÖLÜM 3 — Zaman Çizelgesi
12  (Aşama/milestone bazlı tarihler + belirsizlik payı notu)
13 
14BÖLÜM 4 — Fiyatlandırma
15  (Model: sabit/saatlik/aşamalı + platform hesap ücretleri notu)
16 
17BÖLÜM 5 — Ödeme Planı
18  (Aşama bazlı ödeme yüzdeleri)
19 
20BÖLÜM 6 — Değişiklik Talebi Süreci
21  (CR şablonu + onay kuralı + küçük düzeltme eşiği)
22 
23BÖLÜM 7 — Yayın Sonrası Bakım
24  (Dahil mi, ayrı paket mi)
25 
26BÖLÜM 8 — Kabul ve İmza

Bu iskeleti her yeni proje için kopyalayıp doldurmak, sıfırdan yazmaktan hem hızlıdır hem de hiçbir bölümü unutmanı önler.

SSS

Mobil uygulama projesi nasıl fiyatlandırılır?

Öncelikle 12 soruluk keşif brifiyle platformu, iş modelini ve bakım beklentisini netleştir, sonra bu bilgiyi ekran/özellik bazlı bir efor tahminine dönüştür. Tahmini en iyi/en olası/en kötü olarak üç rakamla çıkar, belirsizlik payını ayrı bir satır olarak ekle ve projenin risk profiline göre sabit fiyat, saatlik ücret veya aşamalı (milestone) modellerinden birini seç. Apple ve Google'ın yıllık/tek seferlik hesap ücretlerini de fiyatlandırmaya dahil etmeyi unutma.

Sabit fiyat mı saatlik mi çalışmalıyım?

Kapsamı önceden net yazılı tanımlayabildiğin, benzerini daha önce yaptığın kısa projelerde sabit fiyat işe yarar; kapsamın belirsiz olduğu, keşif ağırlıklı ya da uzun soluklu bakım işlerinde saatlik ücret daha dürüst bir modeldir. Orta-büyük projelerde ikisini aşamalı bir yapıda birleştirmek — keşfi saatlik, geliştirmeyi milestone bazlı sabit fiyatlı yapmak — riski her iki tarafa da adil dağıtır.

Kapsam kaymasını nasıl önlerim?

Kapsam tanımını üç ayrı liste olarak yaz: dahil olan, hariç olan ve varsayımlar. Her değişiklik talebini yazılı bir CR (change request) belgesine dönüştür, hangi kalemin "hariç" listesinde olduğunu ve ek ücret gerektirdiğini açıkça belirt, ve müşteriden yazılı onay almadan o işe başlama. Küçük düzeltmeler için önceden bir eşik (örneğin toplam 2 saate kadar ücretsiz) belirlemek, hem esneklik sağlar hem de sınırsız "ufak ricalar" birikmesini önler.

Müşteri App Store/Play Console hesabına kim sahip olmalı?

Bunu teklif aşamasında netleştir: müşterinin kendi hesabından mı yayın yapılacak yoksa senin hesabından mı? Hesap sahipliği, uygulamanın uzun vadeli kontrolünü belirler — müşteri kendi hesabına sahipse ilişki bittiğinde uygulamaya erişimi devam eder, senin hesabından yayınlanmışsa bu bir bağımlılık yaratır ve teklifte açıkça yazılmalıdır.

Teklif şablonunda hangi bölümler olmazsa olmaz?

Proje özeti, kapsam (dahil/hariç/varsayım üçlüsü), zaman çizelgesi, fiyatlandırma modeli, ödeme planı, değişiklik talebi süreci, yayın sonrası bakım durumu ve kabul/imza bölümü — bu sekiz bölüm birlikte, teklifi hem satış belgesi hem de anlaşmazlık önleyici bir sözleşme taslağı haline getirir.

Güncelleme (Eylül 2026)

2025 Nisan'dan bu yana teklif/fiyatlandırma pratiğini doğrudan etkileyen değişiklikler, tek bir büyük reform değil, Apple ve Google tarafında paralel ilerleyen iki uyum yükü şeklinde geldi — ve hepsi "teslimattan sonraki bakım borcu"nu büyütüyor, bu da yukarıdaki "mağaza yayın ve bakım kalemleri" tezini daha da güçlendiriyor.

Apple tarafında yeni bir yaş derecelendirme sistemi (4+/9+/13+/16+/18+/Unrated) geldi ve geliştiricilerin App Store Connect'teki yeni sorulara 31 Ocak 2026'ya kadar yanıt vermesi zorunlu kılındı; 28 Nisan 2026'dan itibaren gönderimler Xcode 26/iOS 26 SDK'sı ile derlenmiş olmalı, 9 Eylül 2026'dan itibaren de minimum hedef iOS 13 şartı getirildi. AB'de ise 17 Şubat 2025'ten beri "trader" (tacir) statüsü doğrulamayan geliştiricilerin uygulamaları AB App Store'dan kaldırılıyor, ve 1 Ekim 2026'da güncel Geliştirici Programı Lisans Sözleşmesi'ni (DPLA) imzalayan geliştiriciler için Core Technology Fee kalkıyor — bu, AB'li müşteriler için hazırlanan tekliflerde artık "hangi sözleşme rejimi seçilecek" sorusunun da maliyet tablosuna girmesi gerektiği anlamına geliyor.

Google tarafında en somut değişiklik Android Developer Verification programı: 30 Eylül 2026 tarihli bölgesel adım Brezilya, Endonezya, Singapur ve Tayland'daki katılımcı uygulama mağazalarından yapılan kurulumları kapsıyor; sertifikalı cihazlardaki tüm uygulamalara genişleme 2027'de küresel olarak planlanıyor — mağaza dışı dağıtım öneren teklif modelleri için risk asıl bu ikinci aşamada doğuyor (Google güçlü kullanıcılar için ayrı bir "Advanced Flow" öngörüyor).

Bu değişikliklerin hiçbiri "nasıl kod yazılır"ı değiştirmiyor; hepsi teslim sonrası uyum/bakım yükünü büyütüyor — ki bu tam olarak yazının başındaki tezi (kapsamı yazılı tanımla, bakım kalemlerini ayrı fiyatlandır) 2025 Nisan'dakinden daha güçlü kanıtlarla destekliyor.

Sonuç

Bir mobil uygulama teklifi, ne kadar iyi kod yazdığından bağımsız olarak, ne kadar iyi yazıldığıyla ölçülür. 12 soruluk keşif brifini atlamadan başla, tahminini tek rakam yerine üç rakamla ver, kapsamını dahil/hariç/varsayım üçlüsüyle yaz ve mağaza hesap/bakım kalemlerini (bkz. Google Play politika uyum rehberi) ayrı bir satır olarak fiyatlandır. Analitik/ölçüm altyapısı gibi ek kapsamları (mobil A/B test altyapısı, attribution ve MMP rehberi, retention metrikleri D1/D7/D30, push izin oranı optimizasyonu) MVP'den ayrı tut. Değişiklik talebi sürecini yazılı hale getir ve teklifi göndermeden önce en kötümser anlaşmazlık senaryosuyla test et — bu disiplin, projeyi bitirdikten sonra da müşteriyle çalışmaya devam edebilmenin en garanti yoludur.

Kaynaklar

• Apple Developer Program — Bireysel/organizasyon kaydı ve yıllık $99/$299 program ücretleri.
• App Store Review Guidelines — Demo hesap, TestFlight, gizli özellik yasağı, isim limiti ve gizlilik politikası kuralları.
• Google Play Developer Hesabı Yardım Sayfası — Tek seferlik $25 kayıt ücreti, Kişisel/Kurumsal hesap türleri ve test şartları.
• Apple Upcoming Requirements — Yaş derecelendirme, SDK/iOS minimum sürüm ve AB trader statüsü tarihleri.
• Apple Core Technology Fee — AB alternatif şartlar ve DPLA imzası sonrası CTF muafiyeti.
• Android Developer Verification — Google'ın geliştirici kimlik doğrulama programı ve bölgesel uygulama takvimi.