Bir mobil uygulama için teklif alıyorsunuz, rakam da fena durmuyor. Sonra proje başlıyor ve bir bakıyorsunuz — tasarım revizyonu, test cihazları, bulut faturası, mağaza ücretleri, güvenlik kontrolü derken bütçe yavaş yavaş değil, bildiğiniz sızarak büyüyor. İşin can sıkıcı tarafı şu: çoğu zaman tek bir büyük hata yok ortada. Küçük kaçaklar var, hepsi birleşince gemi su almaya başlıyor.
Eh, Ben bu tabloyu ilk kez 2014’te İstanbul’da küçük bir e-ticaret girişiminde görmüştüm. “Sadece basit bir iOS uygulaması yapacağız” demiştik — hani kulağa çok temiz geliyor ya. Üçüncü ayda backend işi ayrı bir kalem oldu, dördüncü ayda QA için ekstra cihaz aldık, beşinci ayda App Store süreci uzadı. O zaman anladım: ekran çizmek işin sadece vitriniymiş (ki bu çoğu kişinin gözünden kaçıyor). Gerisi? Görünmez bir buz dağı.
Yani, İşin aslı şu ki mobil uygulama maliyeti dediğimiz şey sadece kod yazmak değil; planlama, entegrasyon, güvenlik, yayınlama. Bakım gibi görünmeyen parçaların toplamı. Açık konuşayım, bütçeyi bozan şey genelde devasa tek seferlik masraf olmuyor (bu beni çok şaşırttı). Üst üste binen ufak kalemler oluyor. Hep öyle.
Nerede Başlıyor Bu Gizli Fatura?
Çoğu ekip işe iyi niyetle giriyor. Ama başlangıç tahmini ile gerçek proje arasında bazen uçurum oluyor,. Teklif aşamasında henüz netleşmemiş şeyler çok fazla — kullanıcı akışı tam belli değil, edge case’ler düşünülmemiş, üçüncü parti servislerin sınırları hesaplanmamış. E peki, sonuç ne oldu? Bakın şimdi, tam burada işler kayıyor.
Geçen yıl Ankara’da bir SaaS ekibiyle konuşurken aynı senaryoyu duydum. “MVP olsun yeter” demişlerdi. MVP’nin içine ödeme sistemi de girmişti, canlı destek de girmişti, raporlama paneli de (ciddiyim). E tabi her yeni istek biraz daha saat demekti. Saat arttıkça maliyet artıyor. Bu kadar basit.
Bir de şu var. Bazı ajanslar veya ekipler düşük başlangıç fiyatı verip sonradan değişikliklerle açığı kapatıyor — kötü niyetli olmak zorunda değiller, bazen gerçekten kapsamı eksik okuyorlar, ama müşterinin cebinden çıkan para açısından sonuç aynı oluyor: beklenenden çok daha pahalı bir iş.
En Çok Kaçırılan Kalemler Hangileri?
Bir şey dikkatimi çekti: Lafı gevelemeden söyleyeyim: gizli maliyetlerin çoğu teknik olduğu kadar operasyonel de. Yani sadece geliştirici maaşı değil mesele — tasarımın tekrar yapılması da var içinde, ürün yöneticisinin toplantısı da var, hatta bazen hukuki taraf bile çıkıyor karşınıza (ki bu çoğu kişinin gözünden kaçıyor). Beklenmedik bir yerde, tam da en kötü zamanda.
Kapsam Net Değilse Tasarım da Şaşar
Tasarım süreci kağıt üstünde hızlı görünür. Pratikte? Öyle değil. Bir ekran iki kere çizildi mi maliyet artar, kullanıcı yolculuğu değişti mi bir tür daha wireframe gerekir — özellikle startup’larda “önce yapalım sonra düzeltiriz” yaklaşımı bayağı pahalıya patlayabiliyor (yanlış duymadınız)
Bunu 2023’te Kadıköy’de çalışan küçük bir ürün ekibinde birebir gördüm. İlk taslak üç haftada bitti sanmışlardı; sonra yönetim “bir de kurumsal mod ekleyelim” deyince her şey yeniden ele alındı, haliyle tasarımcı yoruldu, geliştirici bekledi. Beklemek bedava sanılıyor. Değil. Bu konuyla ilgili PC Workman 1.7.1: Temiz Kod, Temiz Sabah yazımıza da göz atmanızı tavsiye ederim.
Backend ve Entegrasyon Masrafı Sessizce Büyür
Mobil uygulamanın ön yüzü güzel olabilir, ama arkada API yoksa o ekranlar dekor olur gider. Ödeme sistemi mi bağlayacaksınız? Kimlik doğrulama mı? CRM entegrasyonu mu? Bunların her biri hem geliştirme saati hem test yükü getiriyor —. Bu yük başta hiç görünmüyor.
| Kalem | Başta Görülen | Sonradan Gelen |
|---|---|---|
| Tasarım revizyonu | Az | Orta-yüksek |
| API entegrasyonu | Yok gibi | Yüksek |
| Test cihazları | Yok sayılır | Belli olur |
| Bulut kullanımı | Düşük görünür | Sürpriz fatura çıkarır |
Test Etmeden Yayına Çıkmak Pahalıya Mal Olur
Hani, Ama durun — burada en çok ihmal edilen yerlerden biri test bütçesi. Ben 2022’de İzmir’deki bir perakende uygulamasında bunu yaşadım; Android’in orta segment birkaç cihazında gayet çalışan ekranlar eski iPhone modellerinde kayıyordu. Evet, aynen böyle saçma bir ayrıntı yüzünden. E peki, sonuç ne oldu? Sonra düzeltme döngüsü başladı ve iki haftalık iş dört haftaya uzadı. Daha fazla bilgi için Invincible Neden Sarsılıyor: İsim Değil, Kare Zamanı yazımıza bakabilirsiniz.
Bi saniye — Eğer QA’yı yalnızca finalde yapılan kısa kontrol gibi düşünürseniz hayal kırıklığı büyük olur, çünkü gerçek dünya testi sadece “açılıyor mu?” sorusu değil — ağ kesilince ne oluyor, ekran dönünce ne bozuluyor, bildirim gecikince kullanıcı ne görüyor… Bunların hepsi para demek. Düz para. Bu konuyla ilgili Modem Nereye Konulmalı? Çekimi Artıran Akıllı Yerleşim Rehberi yazımıza da göz atmanızı tavsiye ederim.
Peki Ya Yayın Sonrası?
Araya gireyim: Burası çoğu sunumda romantize edilir. Aslında en kritik bölüm budur — uygulamayı mağazaya yüklediniz diye iş bitmiyor, tam tersine orası başlıyor bile denebilir. Güncelleme gelecek mi? Çökme raporları izlenecek mi? Kullanıcı şikayetleri kimde toplanacak?
Bir mobil proje için asıl maliyet bazen ilk sürümde değil, ilk altı ayda ortaya çıkar.
Yayın sonrası destek yoksa ucuz görünen teklif hızla pahalılaşır.
Apple App Store ve Google Play tarafındaki kurallar da ayrı hikaye zaten. Bir güncelleme reddedilirse neredeyse tüm plan kayar gider — bu süreci yaşayan bilir, gerçekten öyle hissettiriyor. Bilhassa de enterprise projelerde onay zinciri uzun olduğu için küçük değişiklik bile takvimi etkileyebiliyor.
Küçük startup ile kurumsal yapı arasındaki fark burada netleşiyor:
- Küçük startup’ta para azdır ama karar hızlı alınır.
- Kurumsalda para vardır ama onay almak zaman ister.
- Küçük ekipte tek kişi birçok rol üstlenir.
- Büyük şirkette roller ayrıdır ama koordinasyon masrafı yükselir.
Neden İlk Tahmin Bu Kadar Yanlış Çıkıyor?
Anlık cevap şu: çünkü tahmin çoğu zaman varsayımla yapılıyor. Gereksinimler tam oturmadan verilen sayı sadece kaba bir resim. Ürün sahibi daha detay istemeden maliyeti aşağı çekmek ister, satıcı da kazanmak için iyimser davranır — ortada herkesin memnun olduğu sanılan ama sonradan çatlayan bir anlaşma doğuyor (ki bu çoğu kişinin gözünden kaçıyor)
Yani, Bence buradaki en büyük sorun psikolojik. İnsan düşük rakam duyunca rahatlıyor, hatta biraz fazla rahatlıyor. Gelecek haftanın sorunlarını bugünün fırsatı sanıyoruz. Halbuki bütçe defteri acımıyor.
Bir arkadaşım Londra’da fintech projesinde çalışırken bana şöyle demişti: “Teklif güzel görünüyordu, ta ki compliance ekibi devreye girene kadar.” O cümleyi hala hatırlarım. Çünkü regülasyon, güvenlik, loglama, veri saklama gibi kalemler geç gelir — geldiklerinde de sessiz gelmez.
Daha Sağlıklı Bir Bütçe İçin Ne Yapmalı?
Şimdi gelelim pratik tarafa. Eğer yeni bir mobil uygulama planlıyorsanız, önce MVP ile “gerçekten gerekli” olan şeyi ayırın. İkinci adım olarak discovery aşamasını atlamayın — evet, o kısım sıkıcı görünebilir,. Çoğu bütçe kurtarma hamlesi tam orada başlıyor.
Ha bu arada, vendor seçerken yalnızca saatlik ücrete bakmayın (en azından benim deneyimim böyle). Test stratejisini sorun, destek modelini sorun, güncelleme sonrası SLA’yı sorun. Açıkçası bunları sormuyorsanız teklifte eksik kalan kısmın faturasını sonradan siz ödüyorsunuz. Kaçınılmaz olarak.
Kendi not defterimde kullandığım mini kontrol listesi şöyle: Hong Kong’da Stablecoin Hamlesi: Bankalar Sahneye Çıkıyor yazımızda da bu konuya değinmiştik. 2026’da Hangi LMS’yi Önce Desteklemeli? Akıllı Seçim Rehberi yazımızda da bu konuya değinmiştik.
- Kapsam net mi?
- Backend bağımlılıkları yazıldı mı?
- QA hangi cihazlarda yapılacak?
- Mağaza süreçleri kimde?
- Yayın sonrası destek kaç hafta?
- Güvenlik / KVKK / loglama gereksinimi var mı?Kimin İçin Ne Kadar Risk Var?
Küçük startup’larda risk genelde nakit akışıyla ilgili. Tek yanlış tahmin bütün sprint’i daraltabiliyor (evet, doğru duydunuz). Mesela ürün-hazırlık aşamasında üç aylık plan yaptınız diyelim — bir ekstra entegrasyon geldiğinde roadmap hemen esniyor, ve o esneme sessizce bütçeyi yiyor.
Enterprise seviyede ise olay farklı. Burada bütçe belki vardır. Katman çoktur: satın alma süreci, hukuk incelemesi, bilgi güvenliği değerlendirmesi, iç onay mekanizmaları… Bunlardan biri aksarsa süre uzar, süre uzarsa dolaylı maliyet çıkar. Kaçınılmaz döngü.
Bu yüzden ben mobil projeleri hep iki gözlükle değerlendiriyorum: “kaç liraya yapılır?” ve “kaç liraya tamamlanır?” İkincisi sorulmuyorsa ilk cevap pek anlam taşımıyor doğrusu.
Sıkça Sorulan Sorular
Mobil app development cost neden başlangıçta düşük görünür?
Çünkü teklif aşamasında tüm detaylar henüz belli olmaz. Tasarım revizyonu, test yükü, entegrasyonlar ve yayın sonrası destek genelde sona bırakılır. Bu da toplam faturayı büyütür.
MVP yapmak gizli maliyetleri azaltır mı?
Evet, doğru kurgulanmış MVP riski düşürür. Ama MVP adı altında yarım yamalak kapsam çıkarmak başka, odaklı ürün çıkarmak başka şeydir.
Tesƫn payını nasıl hesaplamalıyız？
Basit projelerde bile ciddi bir test zamanı ayırmak gerekir. Cihaz çeşitliliği arttıkça bu pay büyür. En azından ana platformlara göre ayrı senaryo yazılmalı.
Kod teslim edildikten sonra neden yine ödeme çıkar?
Çünkü uygulama yaşayan bir üründür. Güncellemeler mağaza uyumluluğu, hata düzeltmeleri ve sunucu giderleri devam eder. Teslim = bitiş değildir.
Kaynaklar ve İleri Okuma
Apple App Store Review Guidelines }
Google Play Developer Policy Center }
Microsoft Azure Architecture Center }
20+ yıl deneyimli Azure Solutions Architect. Microsoft sertifikalı bulut mimari ve DevOps danışmanı. Azure, yapay zekâ ve bulut teknolojileri üzerine Türkçe teknik içerikler üretiyor.
İlgili Yazılar
Bu içerik işinize yaradı mı?
Benzer içerikleri kaçırmamak için beni sosyal medyada takip edin.
