Mobil Uygulama Yaptırma Fiyatları 2026: Gerçek Bütçe Nasıl Çıkarılır?

Aşağıdaki tablo, uygulama türüne göre örnek ilk geliştirme aralıklarını gösteriyor. Rakamlar Ekim 2026 için, KDV hariç ve yazının ortasındaki hesaplayıcının varsayılan değerleriyle üretildi: iki platform tek kod tabanı (React Native veya Flutter), standart tasarım ve ajans/yazılım firması saat ücreti. Tablo ile araç aynı varsayımları paylaşıyor. Aracı açıp saat ücretini elinizdeki teklife göre değiştirdiğinizde, bu tablonun mantığını kendi piyasanıza uyarlamış olursunuz.

Aralıkların geniş olması ilk bakışta kafa karıştırıyor. Aynı “e-ticaret uygulaması” etiketinin altında hazır bir altyapıya bağlanan beş ekranlık bir vitrin de var, kendi sipariş motoru, kampanya kuralları ve iade akışı olan bir ürün de. Alt sınırda sade tasarım ve az entegrasyon var. Üst sınırda ise markaya özel arayüz, karmaşık iş kuralları ve eski Android telefonlara kadar inen bir test matrisi.

Bir yazılım firmasının teklifi, nasıl paketlenirse paketlensin, tahmini saatin saat ücretiyle çarpımıdır. “Paket fiyat”, “sabit fiyat”, “anahtar teslim” gibi ifadeler bu çarpımın ambalajı. Teklifi okumayı öğrenmenin en kısa yolu rakamı yeniden saate çevirmek: 900 bin liralık bir teklif, saati 1.500 lira olan bir ekip için yaklaşık 600 saat demek. Bu sayıyı bildiğinizde “bu kapsam 600 saate sığar mı?” diye sorabilirsiniz. Tek bir rakamla bu soruyu soramazsınız.

Saatler yalnız mobil geliştiriciye ait değil. Bir mobil projede efor kabaca altı role dağılıyor ve müşterilerin en çok şaşırdığı şey, mobil geliştirme dışındaki payın büyüklüğü oluyor. Tasarım, test ve proje yönetimi birlikte toplam eforun üçte birine yaklaşabiliyor. Bunlar teklifte görünmüyorsa ya başka bir kaleme gömülmüştür ya da hiç yapılmayacaktır; ikincisi daha sık.

Aşağıdaki şerit, hesaplayıcıda seçtiğiniz kapsamın saatlerini rollere dağıtıyor. Oranlar örnek bir dağılım. Ödeme veya ERP entegrasyonu ağır basan projelerde backend payı, yoğun animasyonlu bir tüketici uygulamasında tasarım payı büyür.

Ekip modeline göre örnek saat ücretleri

• Freelancer600–1.100 ₺saat başınaTek kişi; tasarım, backend ve test çoğu zaman ayrı kişilerden alınır.
• Ajans / yazılım firması1.100–1.700 ₺saat başınaÜcrete proje yönetimi, test, yedek kapasite ve süreklilik dahildir.
• Şirket içi ekip (efektif)750–1.250 ₺saat başınaBrüt maaş + işveren yükleri + ekipman ÷ üretken saat; kâr marjı yoktur.

TL/saat, KDV hariç, örnek aralık. Kıdem, şehir ve ekip yapısına göre fark büyüktür; elinizde teklif varsa hesaplayıcıya kendi ücretinizi yazın.

Hangi özelliğin efora ne kadar eklendiğini ve aynı görünen iki ekranın neden çok farklı saat tuttuğunu mobil uygulama maliyetini belirleyen faktörler bölümünde anlattım. Buradaki tablo yalnız o eforun TL karşılığına odaklanıyor.

Saat ücreti en düşük olan model, toplamda en ucuz model olmayabilir. Üç modeli burada yalnız maliyet ekseninde karşılaştırıyorum. Firma seçerken bakılacak referans, keşif ve ekip yetkinliği gibi konuları yazılım firması seçerken dikkat edilmesi gerekenler rehberine bıraktım.

Pratikte en sık gördüğüm sağlıklı model hibrit. İlk sürümü deneyimli bir dış ekip çıkarıyor; şirket içinde bir ürün sorumlusu, zamanla da bir iki geliştirici yetişiyor; dış ekip bakımda ve zor modüllerde destek veriyor. Tamamen şirket içi ekip kurmak, uygulama işin çekirdeğiyse ve her ay yeni özellik çıkacaksa mantıklı. Yılda iki güncelleme alacak bir kurumsal uygulama için kadro kurmak, boş bekleyen kapasiteye maaş ödemek demek.

Geliştirme teklifi, uygulamanın kodunu yazmanın bedelidir. Uygulamanın yaşaması için ödenen kalemler ise çoğu zaman ayrı faturalarla, farklı firmalardan ve farklı para birimleriyle gelir. Bunlara “gizli” diyorum ama kimse saklamıyor. Sadece teklif masasında kimsenin aklına bunları alt alta yazmak gelmiyor.

Aşağıdaki kartlar, bir mobil uygulamanın bütçesine yayından önce ve sonra eklenen kalemleri ödeme biçimine göre ayırıyor. Hepsi her projede yok; ama hangilerinin sizde olduğunu baştan bilmek, ilk yılın sonunda “bu fatura nereden çıktı?” sorusunu önlüyor.

• Döviz bazlı
• Kullanımla büyür
• Satışa bağlı
• Tek seferlik iş

• Apple Developer ProgramYıllıkÜyelik yıllık 99 USD. Apple fiyatın bölgeye göre değişebildiğini ve kayıt sırasında yerel para biriminde listelendiğini söylüyor; yani her yenilemede TL tutarı kurla birlikte oynuyor. Şirket adına hesap için D-U-N-S numarası gerekiyor. Numarayı Dun & Bradstreet ücretsiz veriyor ama başvurunun sonuçlanması günler sürebiliyor, mağaza takviminize ekleyin.
• Google Play ConsoleTek seferlik25 USD kayıt ücreti bir kez ödeniyor. 13 Kasım 2023'ten sonra açılan kişisel hesaplarda, uygulama üretime çıkmadan önce en az 12 test kullanıcısıyla 14 gün kesintisiz kapalı test yapılması gerekiyor. Bu bir ücret değil ama takvime en az iki hafta ekliyor; hesabı şirket adına açmanın bir gerekçesi de bu.
• SMS doğrulama (OTP)Mesaj başıTürkiye'deki SMS sağlayıcıları gönderici adı (başlık) tanımlaması ve mesaj başı ücretle çalışıyor. Tek kullanımlık şifre gibi işlem mesajları ile kampanya mesajları aynı değil: tanıtım amaçlı ticari elektronik iletiler için alıcı onayı gerekiyor ve bu onaylar İleti Yönetim Sistemi (İYS) üzerinden yönetiliyor. Doğrulama SMS'ine kampanya cümlesi eklemek onu ticari iletiye çevirebilir.
• Harita ve konum servisleriKullanım başıHarita gösterimi, adres arama ve rota hesaplama, sağlayıcının ücretsiz kullanım hakkı aşıldığında istek başına faturalanıyor. Kampanya döneminde fatura sürpriz yapabilir; bütçe uyarısı ve kota sınırı baştan kurulmalı.
• Sunucu, bulut veya BaaSAylıkKullanıcı sayısıyla büyüyen en büyük süreklilik kalemi. Eğrinin şeklini sunucu bölümünde ayrıca gösteriyorum.
• E-posta, çökme raporlama, izlemeAylıkBaşlangıçta çoğu ücretsiz katmanla karşılanıyor; kullanıcı arttıkça ücretli plana geçiliyor. Push bildirimde sık kullanılan Firebase Cloud Messaging (FCM), Firebase'in fiyat sayfasında ücretsiz ürünler arasında yer alıyor.
• Ödeme kuruluşu komisyonuİşlem başıFiziksel ürün ve hizmet satışında iyzico, PayTR gibi ödeme kuruluşlarıyla çalışılıyor; işlem başına komisyon ödeniyor. Bu bedel geliştirme bütçesine değil satış maliyetine yazılır, ama iş planında yeri olmalı.
• Mağaza komisyonuİşlem başıUygulama içinde tüketilen dijital içerik ve abonelik satıyorsanız mağazanın ödeme sistemini kullanmanız gerekiyor. Apple'ın Small Business Program'ında (yıllık 1 milyon USD'ye kadar) ve Google Play'de yıllık ilk 1 milyon USD gelirde oran %15; bu eşiğin üstünde ve programa girmeyen geliştiricilerde standart oran %30. Google Play'de otomatik yenilenen aboneliklerde oran %15. Fiziksel ürün ve hizmet satışında mağaza komisyonu yok.
• Test cihazları ve MacTek seferlikiOS uygulamasını derlemek için macOS gerekiyor; ekipte Mac yoksa bulut derleme servisleri aylık ücretle çalışıyor. Gerçek cihaz testi için eski ve yeni birkaç model telefon da bütçeye girmeli.
• MDM / kurumsal dağıtımCihaz başıUygulamayı yalnız çalışanlarınıza dağıtacaksanız mobil cihaz yönetimi (MDM) lisansları genellikle cihaz başına aylık ücretleniyor.
• Hukuk metinleri ve mağaza içeriğiTek seferlikKVKK aydınlatma metni, gizlilik politikası, kullanım koşulları, mağaza ekran görüntüleri ve açıklamaları. Mağazada görünürlük (ASO) ayrı bir iş; ASO rehberimizde ayrıntılı anlatıyoruz.

Bu kalemlerin çoğu dolar veya avro bazlı. Mağaza üyeliği, bulut faturası, harita servisi ve SaaS araçlarının TL karşılığı her ay değişiyor. Bütçe yaparken kuru tek bir sayı olarak değil bir aralık olarak düşünün; hesaplayıcıda kur alanını bilerek size bıraktım.

Sektörde dolaşan kaba kural, yıllık bakımın ilk geliştirme bedelinin %15–25'i kadar olduğu. Bu bir standart değil, bir gözlem; bu bandın dışına çıkan projeler de az değil. Yine de bütçe kurarken iyi bir başlangıç noktası: 1 milyon liraya yapılan bir uygulama için yılda 150–250 bin liralık bakım bütçesini baştan konuşmak, ikinci yılın sürprizlerini büyük ölçüde önlüyor.

Mobilde bakım isteğe bağlı değil. Apple yeni iOS sürümünü genellikle her eylülde yayınlıyor. Google Play ise hedef API şartını her yıl 31 Ağustos'ta yükseltiyor: 2026'da yeni uygulamalar ve güncellemeler için Android 16 (API 36) istendi. Şartı karşılamayan uygulama güncelleme gönderemiyor, uzun süre geride kalırsa yeni Android sürümlerindeki kullanıcılara görünmez oluyor. Kullandığınız React Native veya Flutter sürümü, ödeme ve harita SDK'ları da aynı takvimle eskiyor. Bakım yapılmayan uygulama bir gecede değil, yavaş yavaş bozuluyor: önce bir kütüphane uyarısı, sonra yeni telefonlarda kayan bir ekran, sonra bir mağaza reddi.

Bakımın neyi kapsadığı sözleşmede yazılı olmalı. Hata düzeltme ile yeni özellik aynı şey değil ve anlaşmazlıkların çoğu “bu bakım mı, geliştirme mi?” sorusundan çıkıyor. Ben bakımı aylık saat paketi olarak tanımlamayı tercih ediyorum. Kapsam belli oluyor, öncelik sırasını müşteri belirliyor. Kullanılmayan saatlerin sonraki aya devredip devretmediği de sözleşmede tek cümleyle yazmalı; bu küçük ayrıntı yıl sonunda en çok tartışılan konulardan biri.

1. HaziranApple geliştirici konferansı; yeni iOS betasında uygulamanın test edilmesi.
2. 31 AğustosGoogle Play hedef API son tarihi; Android derleme ayarlarının ve SDK'ların yükseltilmesi.
3. EylülYeni iOS sürümü kullanıcılara ulaşır; uyumluluk düzeltmeleri canlıya çıkar.
4. Yıl boyuSDK güvenlik yamaları, dağıtım sertifikası ve profil yenilemeleri, mağaza kural değişiklikleri.

Bakımın teknik takvimini ve sürüm döngüsünü yayın sonrası bakım ve sürüm döngüsü bölümünde anlattım; bu bölüm yalnız bütçe tarafına bakıyor.

Sunucu faturası, mobil bütçenin en sık yanlış tahmin edilen kalemi. İlk aylarda Firebase veya Supabase gibi bir BaaS (hazır backend servisi) ücretsiz katmanla neredeyse bedavaya çalışabiliyor; bu yüzden birçok bütçede altyapı satırı hiç yok. Sorun, kullanıcı arttığında eğrinin şekli.

BaaS'ta fatura okuma, yazma, depolama ve fonksiyon çalıştırma sayısına göre büyüyor: düşük kullanıcıda ucuz, yüksekte dik. Kendi API'nizi bir bulut sunucuda çalıştırdığınızda ilk günden sabit bir taban ödüyorsunuz, ama artış daha yavaş. Aşağıdaki grafikte iki eğrinin kesiştiği bir bölge var. O bölgenin nerede olduğu uygulamanın veri erişim desenine bağlı; sohbet ve canlı konum gibi sürekli veri akan özellikler kesişmeyi öne çekiyor.

Yeşil: o kademede BaaS ile özel API arasında orta noktası daha düşük olan seçenek.

Bir de görünmeyen ikinci ürün var: yönetim paneli. İçeriği, siparişleri, kullanıcıları ve bildirimleri yönetmek için bir web paneli gerekiyor ve bu panel kendi başına bir web uygulaması. Bütçede ayrı satır değilse ya hazır bir admin şablonuyla geçiştirilecek ya da ikinci fazda karşınıza çıkacak.

Kampanya dönemlerini ayrıca düşünün. Kasım'daki Efsane Cuma haftasında, 11.11'de ya da televizyonda bir reklam döndükten sonra trafik birkaç saatte katlanabiliyor; otomatik ölçeklenen bir altyapıda bu, o ayın faturasının da katlanması demek. Bütçe uyarısı ve kota sınırı kurmak teknik bir ayrıntı değil, finansal bir kontrol.

Mimari tercihin kendisini (BaaS mı, özel API mi) mobil uygulamada backend ve API bölümünde karşılaştırdım. API tarafını API geliştirme hizmetimizde ve mobil backend için API geliştirme sayfasında anlattık. Sunucu faturasını kalem kalem görmek isterseniz bulut sunucu fiyatları yazımız ve bulut sunucu kiralama sayfası işinize yarar; sunucu türleri arasındaki farkı hosting, VPS, bulut ve dedicated karşılaştırmasında bulabilirsiniz.

Aşağıdaki araç, toplam sahip olma maliyetini (TCO: ilk geliştirme ile yayından sonra ödenen her şeyin toplamı) üç yıl için çıkarıyor ve ilk geliştirme bedelini bakım, altyapı, SMS ve mağaza giderlerinden ayrı gösteriyor. Uygulama türünü seçtiğinizde o türün tipik özellikleri kendiliğinden işaretleniyor; sonra kendi kapsamınıza göre açıp kapatın. Saat ücreti, SMS birim fiyatı ve kur alanları düzenlenebilir: elinizde bir teklif varsa onun saat ücretini, muhasebenizin kullandığı kuru yazın.

Sonucu okurken tek bir sayıya takılmayın. Önce “yayın sonrası pay” yüzdesine bakın; üç yıllık toplamın ne kadarının ilk faturadan sonra geldiğini gösteriyor. Bu oran yükseldikçe, teklif karşılaştırırken bakım koşulları ve altyapı tercihi ilk geliştirme fiyatı kadar ağırlık kazanıyor.

Saat, çarpan ve aylık altyapı değerleri örnek varsayımlardır ve W3 tarafından projenize göre kalibre edilmiş fiyat değildir. Gerçek teklif, keşif görüşmesinde ekran envanteri ve iş kuralları netleştikten sonra çıkar; projenize göre bir rakam görmek isterseniz mobil uygulama geliştirme ekibimizle bu görüşmeyi planlayabilirsiniz.

Süreç rehberimizdeki Kapsam Planlayıcı ile bu araç farklı soruları yanıtlıyor: o araç uygulamanızın karmaşıklığını ve eforunu, bu araç aynı kapsamın üç yıllık TL karşılığını gösteriyor. Özellik listeniz henüz netleşmediyse önce Uygulama Kapsam Planlayıcı ile başlamanızı öneririm.

Kısa cevap: iki platform iki kat değil, ama bedava da değil. React Native veya Flutter ile tek kod tabanından iki uygulama çıkardığınızda iş mantığı, ekranlar ve API istemcisi bir kez yazılıyor. Platforma özgü ayarlar, izin akışları, bildirim kurulumu ve mağaza hazırlığı ise iki kez yapılıyor. Hesaplayıcı bu farkı istemci tarafı eforuna %15–25 ekleyerek modelliyor.

• Yalnız iOS×1,0620 bin ₺ – 1,65 mn ₺Apple üyeliği yıllık; Mac zorunlu.
• Yalnız Android×1,0620 bin ₺ – 1,65 mn ₺Tek seferlik Play ücreti; geniş cihaz yelpazesi test yükünü artırır.
• İki platform, tek kod×1,15–1,25680 bin ₺ – 1,95 mn ₺Çoğu iş ve tüketici uygulaması için varsayılan tercih.hesaplayıcıda seçili
• İki platform + tablet×1,30–1,45750 bin ₺ – 2,15 mn ₺Ekranlar ikinci bir yerleşim düzeniyle tasarlanır.
• İki ayrı native×1,70–1,90920 bin ₺ – 2,65 mn ₺İki kod tabanı, iki bakım; yalnız cihaz yeteneği gerektiğinde.

Kartlardaki tutarlar, hesaplayıcıdaki kapsamınızın yalnız platform değiştirildiğindeki ilk geliştirme aralığıdır.

Test ve yayın tarafı neredeyse tam ikiye katlanıyor: iki mağaza, iki inceleme süreci, iki gizlilik beyanı (App Store gizlilik etiketi ve Google Play Data safety formu), iki ayrı cihaz matrisi. Bir mağazanın reddi diğer platformdaki lansmanı da bekletebiliyor; en sık red nedenlerini App Store ve Google Play red nedenleri yazımızda topluyoruz.

İki ayrı native uygulama (Swift ve Kotlin) yazdırmak, istemci tarafında eforu kabaca 1,7–1,9 katına çıkarıyor ve bakımda da iki uzmanlık demek. Bunu yalnız ileri kamera, artırılmış gerçeklik, Bluetooth veya derin sistem entegrasyonu gerektiren uygulamalarda öneriyorum. Teknik karşılaştırma native, cross-platform ve PWA farkı bölümünde.

Aynı brifle üç firmadan teklif aldınız: 400 bin, 950 bin ve 1,6 milyon lira. Çoğu zaman bu üç rakam aynı işin fiyatı değil, üç farklı işin fiyatı. Biri backend'i sizin mevcut sisteminizde varsaymış, biri yönetim panelini kapsam dışı bırakmış, biri üç ay garanti ve test raporu eklemiş. Kapsam eşitlenmeden yapılan kıyas en eksik teklifi ödüllendiriyor.

Aşağıdaki eşitleyici, her teklifte eksik olan kalemleri örnek oranlarla tutara ekleyip “kapsamı eşitlenmiş” bir aralık çıkarıyor. Oranlar kaba; amacı kesin fiyat bulmak değil, eksik kalemin büyüklüğünü görünür kılmak. Kaynak kod, mağaza hesapları ve imza anahtarı gibi sahiplik kalemleri tutara eklenmiyor, kırmızı bayrak olarak işaretleniyor. Bunları sonradan para vererek tamamlayamazsınız; eksikse tedarikçiyi değiştirmek zorlaşır.

Mobile özgü kırmızı bayraklar

1. 1İmza anahtarları tedarikçinin hesabındaYeni Android uygulamalarında asıl imza anahtarını Play App Signing ile Google saklıyor; geliştiricide kalan yükleme anahtarı kaybolursa hesap sahibi Play Console'dan sıfırlatabiliyor. iOS'ta dağıtım sertifikasını da hesap sahibi yeniden üretebiliyor. Yani anahtar sorunu aslında hesap sorunu: hesap tedarikçinizdeyse her güncelleme ona bağlı. Play App Signing'e geçmemiş eski bir uygulamada ise keystore dosyası ve şifresi mutlaka teslim listesinde olmalı.
2. 2Mağaza hesabı tedarikçi adına açılıyorUygulama, yorumlar, puanlar ve indirme geçmişi o hesaba bağlı. Transfer mümkün ama zahmetli. Hesabı en baştan şirket adına açın, tedarikçiye ekip üyesi rolüyle erişim verin.
3. 3“Bir haftada e-ticaret uygulaması”Bu hızda teslim edilen uygulama neredeyse her zaman hazır bir şablon ya da web sitenizi saran bir kabuk. App Store yönergelerinin 4.2 maddesi (asgari işlevsellik), uygulamanın “yeniden paketlenmiş bir web sitesinin” ötesine geçen özellik ve arayüz sunmasını istiyor; yalnız siteyi gösteren kabuk bu yüzden reddediliyor.
4. 4Şablon uygulama özel geliştirme diye sunuluyorApple, ticari bir şablondan veya uygulama üretme servisinden çıkan uygulamaları içeriğin sahibi kendi hesabından göndermedikçe reddediyor (4.2.6). Aynı şablondan çoğaltılmış benzer uygulamalar da spam kuralına (4.3) takılabiliyor. Şablon kullanmak kusur değil; ama teklifte yazmalı, lisansın kime ait olduğu belli olmalı.
5. 5Push, analitik ve çökme raporlama kapsam dışıTeklifte yoksa yayından sonra ayrı iş olarak geliyor. Ölçüm olmadan yapılan bir lansman, ilk haftanın en değerli verisini kaybettiriyor.
6. 6Mağaza yayını “müşteri sorumluluğunda”Gizlilik etiketi, Data safety formu, inceleme ekibi için test hesabı, ekran görüntüleri ve ret yanıtları ciddi iş. Kimin yapacağı yazılı olmalı.

Piyasanın çok altındaki fiyat veya yazılı hizmet seviyesi taahhüdü olmaması gibi genel uyarı işaretlerini firma seçimi rehberimizdeki kırmızı bayraklar bölümünde ele aldık; burada yalnız mobile özgü olanlar var. Yazılım bütçesinin web tarafını merak ediyorsanız özel yazılım fiyatları yazımız aynı saat × ücret mantığını web uygulamasına uyguluyor.

Bütçeyi düşürmenin iki yolu var: kapsamı küçültmek ya da kaliteyi düşürmek. İkincisi her zaman daha pahalıya geliyor. Birincisi ise çoğu zaman ürünü de iyileştiriyor, çünkü ilk sürüm daha odaklı çıkıyor ve gerçek kullanıcı verisiyle büyüyor.

1. 1MVP'yi tek bir akışa indirinÜrünün var olma sebebini kanıtlayan akış ilk sürüme, gerisi listeye. Bir özelliği çıkardığınızda kullanıcı uygulamayı neden indirdiğini hâlâ yaşıyorsa o özellik bekleyebilir.
   Bedeliİlk sürüm eksik görünebilir; mağaza açıklamasında ve uygulama içinde yol haritasını dürüstçe anlatın.
2. 2Hazır bileşen kütüphanesiyle tasarlayınHer ekranı sıfırdan çizmek yerine iyi bir bileşen kütüphanesi tasarım ve geliştirme saatini azaltıyor. UI/UX tasarım bütçesini ana akışa ve ilk izlenime harcayın. Tasarım kalemlerinin kendi fiyatlandırması için UI/UX tasarım fiyatları yazımıza bakabilirsiniz.
   BedeliAyırt edicilik azalır; marka hissini renk, tipografi ve mikro metinle kurmak gerekir.
3. 3BaaS ile başlayın, eşiği izleyinİlk 6–12 ayda hazır backend servisi geliştirme saatini belirgin biçimde azaltıyor. Kullanıcı sayısı büyüdüğünde özel API'ye geçiş planını baştan yazın.
   BedeliSağlayıcıya bağımlılık; veri modelini taşınabilir tutun, iş kurallarını istemciye gömmeyin.
4. 4Mevcut API'nizi kullanınWeb siteniz veya ERP'niz zaten bir API sunuyorsa mobil uygulama ona bağlanabiliyor. Webden mobile geçiş senaryosunda backend maliyeti belirgin düşüyor.
   BedeliMevcut API mobil için tasarlanmadıysa birkaç mobil odaklı uç nokta eklemek gerekebilir.
5. 5Tek dil, tek ödeme yöntemiÇoklu dil, ikinci ödeme kuruluşu ve dijital cüzdan entegrasyonları ikinci faza. Metinleri baştan çeviri dosyalarında tutmak, sonradan dil eklemeyi ucuzlatıyor.
   BedeliYurt dışı pazarı ilk günden hedefliyorsanız bu madde sizin için değil.
6. 6Ödeme yerine sipariş talebiBazı B2B ve hizmet uygulamalarında ilk sürümde ödeme almak yerine sipariş talebi toplayıp mevcut faturalama sürecinizle ilerlemek mümkün. Ödeme entegrasyonu, 3D Secure akışı ve iade senaryoları sonraya kalıyor.
   BedeliTüketici uygulamasında satın alma anını ertelemek dönüşümü düşürür.
7. 7Her girişte SMS göndermeyinİlk kayıtta SMS doğrulama, sonrasında biyometrik giriş ve oturum yenileme kullanmak SMS faturasını kullanıcı sayısından bağımsızlaştırıyor.
   BedeliOturum güvenliği ve cihaz değişikliği senaryoları ayrıca tasarlanmalı.

Bütçe aşımlarının çoğu kötü niyetten değil, belirsiz sözleşmeden çıkıyor. Fiyatı sabitleyen birkaç mekanik var ve hepsi teklif aşamasında konuşulabilir. Hukuki ayrıntıya girmeden yalnız para tarafını anlatıyorum.

Kilometre taşı bazlı ödeme

Toplamı keşif, tasarım onayı, beta ve mağaza yayını gibi aşamalara bölün; her hakedişi yazılı bir kabul kriterine bağlayın. “Tasarım onayı” bir toplantı değil, onaylanmış bir ekran listesi olmalı. Peşinatın küçük, son ödemenin garanti dönemine yakın olması iki tarafı da dengede tutar.

Değişiklik talebi birim fiyatı

Kapsam mutlaka değişecek. Değişikliklerin saat ücreti, tahmin ve onay süreci baştan yazılırsa her yeni fikir bir pazarlığa dönüşmüyor.

Kur maddesi

Sabit TL teklif uzun projelerde enflasyon riskini tedarikçiye, döviz endeksli teklif kur riskini size yüklüyor. Orta yol, TL fiyatın belirli bir tarihteki kurla sabitlenmesi ve yalnız belirli bir eşiği aşan kur hareketinde güncellenmesi. Mağaza ücreti ve bulut faturası gibi doğrudan döviz kalemlerini ayrı satırda, gerçekleşen tutar üzerinden yansıtmak en şeffaf yol.

Garanti ile bakımın ayrımı

Garanti, teslim edilen kapsamdaki hataların ücretsiz düzeltilmesi; süresi ve kapsamı yazılı olmalı. Bakım ise ayrı bir sözleşme ve ayrı bir bütçe satırı.

Sahiplik ve teslim listesi

Mağaza hesapları ve imza anahtarları şirket adına; kaynak kod, tasarım dosyaları ve dokümantasyon teslim listesinde. Fikri mülkiyet ve kaynak kod devrinin ayrıntıları için firma seçimi rehberimizin sözleşme bölümüne bakın.