Mobil uygulama yapmak altı aşamalı bir süreçtir ve bu aşamaların hiçbiri atlanabilir değil. Atlanan aşama kaybolmaz — projenin ilerleyen haftalarında, genellikle iki katı maliyetle geri gelir. Aşağıdaki akış, bir brief'i değerlendirirken içeriden kullandığımız akışın kendisi.
Altı aşama
| Aşama | Ne üretir | Tipik süre |
|---|---|---|
| 1. Keşif | Kapsam, teknik risk listesi, backlog | 1-2 hafta |
| 2. Tasarım | Akışlar, tasarım sistemi, uç durumlar | 2-4 hafta |
| 3. Backend | API, veri modeli, yetkilendirme | 3-8 hafta |
| 4. Uygulama | Ekranlar, entegrasyonlar | 4-12 hafta |
| 5. Test | Gerçek cihazlar, regresyon, performans | süreç boyunca |
| 6. Mağaza | Store Connect, Play Console, ret turları | 1-2 hafta |
Aşamalar birbirini bekler ama tamamen sıralı değildir: tasarım ve backend paralel yürür, test ilk günden başlar.
1. Keşif — burada kesilen bütçe en pahalıya gelen bütçedir
Keşif aşamasının çıktısı bir belge değil, karar listesidir: uygulama neyi yapacak, neyi bilinçli olarak yapmayacak, hangi sistemlere bağlanacak, başarı neyle ölçülecek.
Bir haftalık keşfin somut çıktısı şunlar olmalı:
- kabul kriterleriyle yazılmış backlog
- teknik risk listesi (hangi entegrasyon belirsiz, hangi veri eksik)
- ekran envanteri ve öncelik sırası
- sabitlenmiş kapsam üzerinden fiyat
Neyi kaybedersiniz: ilk üç-dört hafta boyunca gözle görülür bir ekran çıkmaz. Bu aşamayı atlayan projelerde ekran hızlı çıkar, sonra altıncı haftada "bir de şunu ekleyelim" başlar ve zaman çizelgesi anlamını yitirir.
2. Tasarım — ekran değil, uç durum tasarlayın
Deneyimsiz projelerde tasarım "ekranların güzel görünmesi" sanılır. Gerçek iş şurada:
- yükleniyor, boş, hata ve çevrimdışı durumları
- form doğrulama ve hata mesajlarının dili
- izin istekleri (konum, bildirim, kamera) hangi anda çıkacak
- erişilebilirlik: kontrast, dokunma alanı, ekran okuyucu
Bunlar tasarlanmazsa geliştirme sırasında geliştirici tarafından "uyduruluyor" — ve sonuç tutarsız oluyor.
3. Backend — asıl karar burada
En sık hafife alınan kalem budur. Backend'i olmayan bir uygulama arayüzdür. Şunlardan biri varsa arkada ikinci bir proje doğar:
- kullanıcı hesabı ve oturum yönetimi
- cihazlar arası senkronizasyon
- ödeme veya abonelik
- yönetim paneli / içerik girişi
- bildirim segmentasyonu
Mevcut sistemlerinize bağlanacaksanız (ERP, CRM, stok) her bağlantı kendi hata yönetimi, kendi test ortamı ve kendi bakım yüküyle gelir — ayrıntılar API entegrasyonu sayfasında.
Kural: API'yi uygulama geliştirmeden önce sabitleyin ve sürümleyin. Sabitlenmemiş API, mobil tarafı kalıcı bir regresyon makinesine çevirir.
4. Teknoloji seçimi: tek platform mu, iki platform mu?
Bu karar bütçeyi %20-40 değiştirir.
Native (Swift + Kotlin) şu durumlarda doğru: yoğun animasyon, özel kamera veya AR var; platforma özel özellikler gerekiyor (Live Activities, widget'lar); uygulamanın kendisi üründür.
Cross-platform (React Native, Flutter) şu durumlarda doğru: iki platformda aynı anda çıkacaksınız; ekibiniz tek yığını iki yığından iyi destekliyor; deneyimin %95'i iki platformda aynı.
2026'da çoğu tüketici uygulaması için performans farkı son kullanıcı için görünmez hale geldi. Ayrıntılı karşılaştırma cross-platform geliştirme sayfasında.
Aritmetik: iki ayrı native uygulama, tek platformun neredeyse iki katıdır. Cross-platform, tek native uygulamadan %15-30 pahalıdır ve ikisini birden karşılar.
5. Test — gerçek cihazda, ilk günden
Simülatör gerçek cihaz değildir. Test planınızda en az şunlar olmalı: düşük bellekli bir Android cihaz, iki OS sürüm gerisi bir iPhone, zayıf ağ senaryosu ve düşük pil durumu. Çökme raporlaması ve analitik ilk sürümden itibaren açık olmalı — ilk gerçek kullanıcılar en değerli hata kaynağıdır.
6. Mağaza yayını
App Store incelemesi tipik olarak 24-48 saat, Google Play daha hızlı. Asıl maliyet inceleme süresi değil, ret turlarıdır. En sık üç ret sebebi:
- gizlilik metni ile uygulamanın topladığı veri uyuşmuyor
- izleme izni (App Tracking Transparency) doğru uygulanmamış
- dijital içerik satışı uygulama içi satın alma dışında yapılmış
Her ret turu birkaç gün demektir. Bunlar önceden kontrol edilebilir kalemler.
Maliyet bantları
| Bant | Fiyat | Süre |
|---|---|---|
| No-code / doğrulama | 0-150.000 ₺ | 1-3 hafta |
| MVP | 750.000-1.800.000 ₺ | 4-8 hafta |
| Üretime hazır | 1.800.000-4.500.000 ₺ | 8-16 hafta |
| Platform ölçeği | 4.500.000 ₺ ve üzeri | 16-28 hafta |
Bantlar kıdemli ekip varsayar. Junior ekip saat başına ucuzdur ama tipik olarak 1,5-2 kat uzun sürer ve daha fazla teknik borç bırakır; toplam sahip olma maliyeti nadiren düşük çıkar.
Süre kırılımının ayrıntısı mobil uygulama geliştirme gerçekte ne kadar sürüyor yazısında.
Yayından sonrası
Yıllık olarak geliştirme maliyetinin %15-20'si. Bu bir tercih değil: iOS ve Android her yıl SDK ve politika değişikliği dayatıyor. Bakımsız bir uygulama iki işletim sistemi sürümü sonra mağazadan düşer.
Yayından sonraki ilk 90 gün
Uygulamayı mağazaya koymak bitiş değil başlangıçtır. İlk üç ayda ölçülmesi gereken dört şey var ve bunların hiçbiri indirme sayısı değil:
- Aktivasyon — indirenlerin yüzde kaçı ilk anlamlı eylemi tamamlıyor? Düşükse sorun üründe değil, ilk açılış akışındadır.
- 1. gün / 7. gün / 30. gün tutundurma — sektör ortalamalarıyla değil, kendi ilk haftanızla kıyaslayın. Eğilim mutlak değerden önemli.
- Çökme oranı — oturum başına %1'in üzerindeyse yeni özellik geliştirmeyi durdurun.
- Mağaza sayfası dönüşümü — sayfayı görenlerin yüzde kaçı indiriyor? Ekran görüntüleri ve ilk iki satır, uygulamanın kendisinden önce satar.
Bu dördü ilk sürümden itibaren ölçülmüyorsa, ikinci sürümde neyi düzelteceğinize dair veri yerine tahmin kullanırsınız.
En sık yapılan beş hata
- Keşfi atlamak. En hızlı görünen başlangıç, en pahalı bitişi üretir.
- Backend'i sonraya bırakmak. Mobil, API'nin aşağısındadır.
- Her şeyi ilk sürüme sokmak. MVP'nin amacı eksiksiz olmak değil, bir soruyu cevaplamak. Hiçbir soruyu cevaplamayan MVP, sadece yarım üründür.
- Tasarımı ekranla sınırlamak. Uç durumlar tasarlanmazsa geliştirme sırasında uydurulur.
- Kullanılabilirlik testini sona bırakmak. Test için doğru zaman ikinci hafta, onuncu hafta değil.
Nasıl başlıyoruz
Fiyat vermeden önce dört cevaba ihtiyacımız var:
- Uygulama, onsuz yapılamayan neyi yapacak?
- Hangi sistemlere bağlanacak — bu sistemlerin arayüzleri hazır mı?
- Tek platform mu iki platform mu, gerekçesi ne?
- Yayından sonra kim işletecek?
Bunlardan dayandığı varsayımlarla birlikte bir aralık çıkar — varsayımsız rakam vermiyoruz. Süreci nasıl kurduğumuz mobil uygulama geliştirme sayfasında, İstanbul ekibimizin çalışma biçimi İstanbul sayfasında.
Elinizde bir teklif varsa ve kapsamının eksiksiz olup olmadığını merak ediyorsanız bize gönderin — 48 saat içinde, teklifte eksik kalan kalemleri listeleyen ikinci bir görüş yolluyoruz.