"Aklımda bir uygulama fikri var" cümlesiyle başlayan görüşmelerin çoğunda aynı iki soru gelir: ne kadar sürer, kaça mal olur? İkisinin de dürüst cevabı sürece bağlıdır — ve süreci bilen müşteri, hem bütçesini hem beklentisini doğru kurar. İşte bir mobil uygulamanın fikirden mağaza vitrinine uzanan 7 aşaması, her aşamanın süresi ve kritik kararlarıyla.
Aşama 1: Fikir Doğrulama (1-2 hafta)
En pahalı hata, kimsenin istemediği uygulamayı kusursuz geliştirmektir. Kod yazılmadan önce üç soru cevaplanmalı:
- Kimin, hangi derdini çözüyor? "Herkes için" cevabı, "hiç kimse için" demektir.
- Bu dert bugün nasıl çözülüyor? Rakip uygulamaları indirin, yorumlarını okuyun. 1 yıldızlı yorumlar sizin ürün fırsat listenizdir.
- Kullanıcı bunun için ödeme yapar mı / reklam-komisyon modeli işler mi? Gelir modeli baştan düşünülmeli; sonradan yapıştırılan modeller sırıtır.
Aşama 2: Kapsam ve Yol Haritası (1 hafta)
Tüm hayal listesi yazılır, sonra acımasızca ikiye bölünür: v1 (MVP) ve sonrası. MVP'de yalnızca ürünün ana vaadini gerçekleştiren akış kalır. Örnek: yemek tarifi uygulamasında v1 = tarif arama + görüntüleme + favorileme. Yorumlar, sosyal paylaşım, haftalık menü planlayıcı → v2. Bu disiplin, SaaS rehberimizde anlattığımız MVP mantığının birebir aynısıdır.
Aşama 3: UI/UX Tasarım (2-4 hafta)
Mobilde tasarım, estetikten önce parmak ergonomisidir: tek elle erişim, büyük dokunma alanları, akıcı geçişler. Süreç şöyle işler:
- Akış şeması: Kullanıcı hangi ekrandan hangisine, hangi amaçla geçiyor?
- Wireframe: Renk yok, süs yok; sadece yerleşim ve akış. Ucuz revizyon burada yapılır.
- Görsel tasarım: Marka kimliği ekranlara giyer. iOS ve Android'in kendi tasarım dillerine (Human Interface / Material) saygılı ama markanıza özgü.
- Tıklanabilir prototip: Kod yazılmadan uygulamayı "kullanırsınız". Yatırımcıya/ekibe gösterilecek ilk somut ürün de budur.
Aşama 4: Teknoloji Kararı
Üç yol var:
- Native (Swift + Kotlin): Her platforma ayrı kod. En yüksek performans, en yüksek maliyet — iki ayrı kod tabanı, iki ayrı bakım.
- Çapraz platform (React Native, Flutter): Tek kod tabanı, iki platform. Bugün uygulamaların büyük bölümü için doğru denge; Instagram'dan Discord'a dev ürünler bu yaklaşımla çalışıyor.
- PWA (web uygulaması): Mağazasız, tarayıcı üzerinden. Mağaza görünürlüğü ve bildirim gücü sınırlı; ama bazı iç araçlar için yeterli.
EagleAsh Studio olarak çoğu projede React Native kullanıyoruz: tek kod tabanıyla iki mağazaya da çıkış, native'e yakın performans ve web ekibiyle ortak teknoloji dili.
Aşama 5: Geliştirme (6-16 hafta)
Geliştirme iki katmanda yürür: uygulama (kullanıcının gördüğü) ve backend (veri tabanı, API, bildirim altyapısı). Sağlıklı bir süreçte:
- İş 1-2 haftalık sprintlere bölünür; her sprint sonunda çalışan bir sürüm görürsünüz.
- Test dağıtımları (TestFlight / Internal Testing) ile uygulamayı kendi telefonunuzda deneyimlersiniz.
- "Sürpriz yok" kuralı işler: kapsam değişiklikleri konuşulur, takvime etkisi yazılı netleşir.
Aşama 6: Test (2-3 hafta, geliştirmeyle paralel)
Mobilde test, masaüstünden zordur: yüzlerce cihaz, üç işletim sistemi sürümü, zayıf internet, düşük pil... Asgari test kapsamı:
- Farklı ekran boyutlarında görsel bütünlük
- Zayıf/kesik bağlantıda davranış (çökme değil, zarif hata mesajı)
- İzin akışları (kamera, konum, bildirim) — reddedilirse ne oluyor?
- Performans: soğuk açılış süresi, liste kaydırma akıcılığı, pil tüketimi
Testte kolay atlanır bir başlık daha: eski cihazlar. Ekibin son model telefonlarında akıcı görünen uygulama, kitlenizin 4-5 yaşındaki cihazlarında bambaşka davranabilir. Test havuzunuzda en az bir düşük segment Android bulunsun; kullanıcı tabanınızın önemli bir bölümü orada yaşıyor. Emülatör hız kazandırır ama asla gerçek cihazın yerini tutmaz: dokunma gecikmesi, ısınma ve gerçek şebeke davranışı yalnızca elde hissedilir. İkinci el bir test cihazı, bu iş için yapacağınız en ucuz ve en geri dönüşlü yatırımdır.
Aşama 7: Mağaza Yayını ve Sonrası
Yayın; ekran görüntüleri, açıklama metinleri, gizlilik politikası ve yaş derecelendirmesiyle başlı başına bir iştir. Apple'ın inceleme kriterleri özellikle titizdir — ödeme akışları ve içerik kuralları ilk başvuruda en sık takılan noktalar. Deneyimli ekip, reddi öngörüp baştan önler.
Yayın sonrası ise asıl oyun başlar: çökme raporlarını izlemek, kullanıcı yorumlarına yanıt vermek, işletim sistemi güncellemelerine uyum ve v2 yol haritası. Uygulama canlı bir üründür; "yayınla ve unut" yaklaşımı, bir yıl içinde puanı düşen ve silinen uygulamalar üretir.
Görünmeyen Yarı: Backend ve API Katmanı
Uygulama görüşmelerinde herkes ekranları konuşur; ama projelerin emek dağılımında backend çoğu zaman yarıyı geçer. Uygulamanız şunlardan birini yapıyorsa bir sunucu katmanına ihtiyacınız var demektir: kullanıcı hesabı, cihazlar arası senkron, bildirim, içerik güncelleme, ödeme.
Backend tarafında verilecek kararlar:
- Hazır BaaS mi (Firebase, Supabase), özel API mi? BaaS hızlı başlatır; karmaşık iş kuralları ve maliyet kontrolü büyüdükçe özel API'yi haklı çıkarır. Orta yol: MVP'de BaaS, ölçekte kademeli geçiş.
- Bildirim mimarisi: Push bildirimleri (FCM/APNs) baştan kurgulanmalı — kullanıcıyı geri getiren bir numaralı araçtır ama izin isteme zamanlaması kötüyse kalıcı olarak reddedilir. Doğru an: değer gösterildikten sonra, ilk açılışta değil.
- Çevrimdışı davranış: Metro'da açılan uygulama ne gösterecek? En azından son veriyi önbellekten göstermek, boş ekrandan her zaman iyidir.
Önce Cevaplanması Gereken Soru: Uygulama mı, Mobil Site mi?
Her mobil ihtiyaç uygulama gerektirmez; yanlış cevap on binlerce liralık gereksiz yatırım demektir. Basit ayrım:
- Mobil uyumlu site yeter, eğer: Kullanıcı size ayda bir uğruyorsa (bilgi almak, form doldurmak), cihaz özelliklerine (kamera, konum, bildirim) ihtiyaç yoksa ve mağaza görünürlüğü hedef değilse. Restoran menüsü, kurumsal tanıtım, randevu formu — bunlar için uygulama yaptırmak, sinek için balyoz almaktır.
- Uygulama gerekir, eğer: Günlük/haftalık tekrar kullanım hedefliyorsanız, bildirimle geri çağırma modelin parçasıysa, çevrimdışı çalışma veya cihaz donanımı (kamera, GPS, sensör) işin özüyse. Sadakat programı, saha ekibi aracı, sosyal ürün — bunlar uygulama işidir.
- Orta yol PWA: Tarayıcıdan kurulabilen web uygulaması; bildirim ve çevrimdışı desteği sınırlı ama maliyeti düşük. İç araçlar ve pilot denemeler için akıllı başlangıçtır.
Güvenlik ve İzinler: Baştan Doğru Kurulmalı
Mobil uygulama, kullanıcının en mahrem cihazında yaşar; güvenlik özensizliği hem mağaza reddi hem itibar kaybıdır. Asgari standartlar: tüm trafik şifreli (HTTPS/TLS), hassas veriler cihazda güvenli depoda (Keychain/Keystore), oturum token'ları süreli, ve minimum izin ilkesi — kullanmadığınız hiçbir izni istemeyin. Rehber erişimi isteyen fatura uygulaması, hem kullanıcıyı hem Apple denetçisini alarma geçirir. KVKK tarafında ise: hangi verinin neden toplandığını açıklayan bir gizlilik politikası, her iki mağazada da yayın şartıdır.
ASO: Mağazanın Kendi SEO'su
Uygulamanızı mağazada bulunur kılmak ayrı bir disiplindir — App Store Optimization. Web SEO'su gibi birikimli çalışır ve şu kalemlerden oluşur:
- Başlık ve alt başlık: Marka + ne yaptığı ("Fatura Takip — Gider Yönetimi" gibi). Anahtar kelime buraya doğal biçimde girmeli.
- Ekran görüntüleri: İlk iki görsel indirme kararını verdirir. Ham ekran yerine, üstüne fayda cümlesi yazılmış kompozisyonlar kullanın.
- Puan ve yorumlar: 4,0 altı puan indirme oranını sert düşürür. Doğru anda (başarılı bir işlem sonrası) yorum istemek, rastgele pencere açmaktan kat kat etkilidir.
- Güncelleme sıklığı: Aylarca güncellenmeyen uygulama hem algoritma hem kullanıcı gözünde "terk edilmiş" sinyali verir.
Yayın Sonrası Hangi Metriklere Bakmalı?
İndirme sayısı gösteriştir; ürünün sağlığını şu üçlü anlatır:
- Tutundurma (retention): 1. gün / 7. gün / 30. gün geri dönüş oranları. 30. günde kullanıcıların büyük çoğunluğu gittiyse sorun pazarlamada değil, üründedir.
- Çökme oranı (crash-free rate): %99'un altına düşen oturum başarısı, yorumlara "sürekli kapanıyor" olarak yansır. Crashlytics benzeri araçlarla ilk günden izleyin.
- Aktivasyon: İndiren kullanıcının "değer anına" ulaşma oranı (ilk kayıt, ilk işlem). Bu oran düşükse onboarding akışınızı sadeleştirin.
Bütçe Gerçekleri
Maliyeti belirleyen üç ana kalem: ekran/özellik sayısı, backend karmaşıklığı ve entegrasyonlar (ödeme, harita, bildirim). Çapraz platform tercihi toplam maliyeti native'e göre belirgin düşürür. En sağlıklı yaklaşım, MVP kapsamıyla fiyat alıp v2'yi ürünün ilk verisiyle şekillendirmektir — böylece bütçenizi varsayımlara değil gerçek kullanıcı davranışına harcarsınız.
Bir kalem daha çoğu bütçede unutulur: pazarlama. Mağazaya koymak, görünür olmak değildir. Toplam bütçenin en az dörtte birini lansman sonrası tanıtıma (ASO görselleri, tanıtım videosu, ilk reklam denemeleri) ayırın; yoksa harika bir uygulama, kimsenin girmediği bir rafta bekler.
Sık Yapılan 6 Hata
- Mağaza hesaplarını ajansa açtırmak: Apple/Google geliştirici hesapları sizin adınıza olmalı; yoksa uygulamanız başkasının vitrininde yaşar, yollar ayrılınca taşıma eziyeti başlar.
- Backend'i "sonra düşünürüz" demek: Ekranlar bitince "veriler nerede duracak?" sorusu projeyi aylarca uzatır. Backend kararı, tasarımla aynı hafta verilmeli.
- Her platform özelliğini istemek: Widget, watch uygulaması, tablet düzeni... v1'de bunlar kapsam şişkinliğidir; telefonda kusursuz çalışan çekirdek her zaman önce gelir.
- Test dağıtımını atlamak: "Bitince görürüz" diyen müşteri, 3. ayda sürprizle karşılaşır. TestFlight/Internal Testing linki haftalık ritüel olmalı.
- Yorumları cevapsız bırakmak: Mağaza algoritmaları yanıtlanan yorumları sever; kullanıcılar da. Haftada 15 dakikalık iş, puanı gözle görülür iyileştirir.
- Analitiği lansmandan sonra eklemek: İlk hafta verisi en kıymetli veridir ve geri getirilemez. Ölçüm, kod tabanına ilk sprintte girmeli.
Bu altı hatanın ortak paydası aynı: hepsi proje başında beş dakikalık bir kararla önlenir, sonunda ise haftalarla ödenir. Sözleşme aşamasında bu listeyi yüklenicinizle madde madde konuşun — verdiği cevaplar, ekibin olgunluğu hakkında portfolyosundan daha çok şey söyler.
Maliyeti Düşürmenin Doğru ve Yanlış Yolları
Doğru: Kapsamı daraltmak (tek platformla başlamak bile meşru), hazır backend servisleriyle başlamak, tasarımda sistem fontları ve standart bileşenler kullanmak, v2 özelliklerini gerçek kullanıcı verisine göre önceliklendirmek.
Yanlış: Testi kısmak (her kısılan test günü, mağaza yorumu olarak geri döner), deneyimsiz-en-ucuz geliştirici (yeniden yazdırma maliyeti klasiği), tasarımı şablondan devşirmek (mağazada ilk izlenim = ekran görüntüleri) ve bakım bütçesini sıfırlamak (işletim sistemi güncellemeleri kimseye sormaz).
Altın kural: kestiğiniz her kalemin ne zaman geri geleceğini yazın. "Push bildirimi v2'ye kaldı — Mart'ta" bilinçli tasarruftur; "push bildirimi çıktı" ise sessiz kapsam erimesi. İkisinin bütçeye etkisi aynı görünür, ürüne etkisi bambaşkadır. Karar toplantılarında bu tek cümlelik disiplin, projelerin sonunda "eksik çıktı" hissini büyük ölçüde ortadan kaldırır.
Sonuç
Başarılı uygulama; iyi fikirden çok, iyi yürütülmüş süreçten çıkar: doğrulanmış problem, daraltılmış MVP, doğru teknoloji, disiplinli test ve yayın sonrası sahiplenme. Fikrinizi bu süreçten geçirmek isterseniz mobil uygulama hizmet sayfamıza göz atın veya doğrudan ücretsiz keşif görüşmesi planlayın — fikriniz gizli kalır, size net bir yol haritası ve kapsamla dönelim.