Mobil uygulama yaptırmadan önce dört şeyi netleştirmeniz gerekir: uygulamanın hangi sorunu kimin için çözeceği, ilk sürümde (MVP) hangi özelliklerin olacağı, arkasında hangi yönetim panelinin ve sistemlerin duracağı ve yayından sonra kimin bakımını yapacağı. Bu dördü hazırsa teklifler karşılaştırılabilir hâle gelir, süre kısalır ve bütçe gereksiz özelliklere gitmez. Bu rehberde her adımı, ajansla ilk görüşmeden önce hazırlayabileceğiniz bir brif listesiyle birlikte anlatıyoruz.
Hizmet tarafında neler yaptığımızı merak ediyorsanız mobil uygulama yaptırmak isteyenler için hazırladığımız sayfaya bakabilirsiniz. Bu yazı ise karar vermeden önceki hazırlığa odaklanıyor.
1. Gerçekten uygulama mı gerekiyor?
Gelen taleplerin bir kısmında ihtiyaç aslında mobil uyumlu bir web sitesi ya da web tabanlı bir paneldir. Uygulama şu durumlarda anlam kazanır:
- Kullanıcı aynı işi sık sık (her gün, her hafta) yapacaksa
- Push bildirim, konum, kamera, çevrimdışı çalışma gibi telefon özellikleri gerekiyorsa
- Sadakat, üyelik veya rezervasyon gibi tekrar eden bir ilişki kurulacaksa
- Saha ekibi, kurye veya teknisyen gibi iç kullanıcılar mobilde çalışacaksa
Kullanıcı yılda bir iki kez gelecekse ve tek ihtiyacı bilgi almak ya da form doldurmaksa, mobil uyumlu bir site daha hızlı ve daha ekonomik bir çözümdür.
2. Sorunu ve hedef kullanıcıyı tek cümleyle yazın
"X kullanıcısı, Y işini, Z yerine bu uygulamayla daha kolay yapacak." Bu cümleyi kuramıyorsanız henüz kapsam yazmak için erkendir. Örnekler:
- "Spor yapmak isteyenler, maç için eksik oyuncuyu WhatsApp grupları yerine uygulamadan bulacak."
- "Teknik servis ekibi, iş emirlerini kâğıt form yerine telefondan kapatacak."
Bu cümleye, kullanıcıların kim olduğunu (müşteri mi, çalışan mı), hangi dili konuştuğunu ve uygulamayı hangi cihazla kullanacağını ekleyin. App Store'da yayında olan Sporla uygulamamız da bu tür tek cümlelik bir problem tanımıyla başladı.
3. MVP kapsamını belirleyin
MVP (minimum uygulanabilir ürün), fikri gerçek kullanıcıyla test etmeye yetecek en küçük sürümdür. İlk sürüme her şeyi koymak hem süreyi hem bütçeyi katlar. Özellikleri iki listeye ayırın:
| Olmazsa olmaz (ilk sürüm) | Sonraya bırakılabilir |
|---|---|
| Üyelik / giriş | Sosyal medya ile giriş seçenekleri |
| Ana işin yapıldığı 3–5 ekran | Gelişmiş filtreler, öneri sistemi |
| Bildirim (sadece kritik olanlar) | Kampanya ve segmentli bildirimler |
| Temel yönetim paneli | Detaylı raporlama ve dışa aktarma |
| Tek dil | Ek diller |
| Ödeme (iş modeli gerektiriyorsa) | Cüzdan, abonelik paketleri |
MVP'yi tanımlamanın daha ayrıntılı yolunu MVP mobil uygulama rehberi yazısında anlattık.
4. iOS, Android ya da ikisi birden
Türkiye'de kullanıcıların çoğu Android kullanır ama iPhone kullanıcıları bazı sektörlerde (ör. yüksek bütçeli hizmetler) ağırlıklıdır. Karar için:
- İki platform birden: Çoğu işletme için doğru seçimdir. React Native veya Flutter gibi tek kod tabanıyla iki platform aynı projede geliştirilir.
- Tek platform: İç kullanım uygulamalarında, şirketin kullandığı cihazlar belliyse yeterli olabilir.
- Native (ayrı ayrı): Yoğun grafik, oyun veya cihaz donanımıyla derin entegrasyon gerekiyorsa düşünülür; maliyeti ve bakımı ikiye katlar.
Teknoloji karşılaştırması için React Native ve Flutter yazılarımıza bakabilirsiniz.
5. Yönetim paneli ve API'yi unutmayın
Kullanıcının gördüğü uygulama işin yarısıdır. İçerikleri, kullanıcıları, siparişleri veya randevuları kimin, nereden yöneteceğini baştan düşünün:
- Yönetim paneli: İçerik ekleme, kullanıcı yönetimi, sipariş/randevu takibi, raporlar.
- API ve sunucu: Uygulamanın verisini saklayan ve panelle konuşan arka uç.
- Entegrasyonlar: Mevcut web siteniz, CRM, ERP, ödeme altyapısı, kargo veya muhasebe sistemi.
Mevcut bir sisteminiz varsa (ör. e-ticaret sitesi veya CRM), uygulamanın veriyi oradan mı alacağı yoksa yeni bir arka uç mu kurulacağı teklifin en büyük kalemlerinden birini belirler. Bu konuda API entegrasyonu sayfamız fikir verebilir.
6. Tasarım için hazırlık
Tasarım aşamasını hızlandırmak için şunları önceden toplayın:
- Logo ve kurumsal renkler
- Beğendiğiniz 2–3 uygulama ve beğenme nedeniniz
- Ekranlarda yer alacak gerçek metin ve görseller (ürün fotoğrafları, hizmet açıklamaları)
- Kullanıcının uygulamayı açtığında ilk yapması gereken iş
Kullanıcı akışı (hangi ekrandan hangisine gidildiği) onaylanmadan görsel tasarıma geçmek, sonradan maliyetli değişikliklere yol açar.
Kiminle çalışılır: freelancer, ajans, iç ekip
Uygulamayı kimin yapacağı, kapsam kadar önemli bir karardır. Üç yolun güçlü ve zayıf yanları farklıdır:
| Freelancer | Ajans / yazılım firması | İç ekip | |
|---|---|---|---|
| Başlangıç maliyeti | Düşük | Orta–yüksek | Yüksek (maaş, ekipman) |
| Kapsadığı işler | Genellikle tek alan (ör. sadece mobil) | Tasarım, mobil, arka uç, test, yayın | İşe alınan rollere bağlı |
| Süreklilik | Kişinin müsaitliğine bağlı | Sözleşme ve ekiple güvence altında | En yüksek, ama işe alım zaman alır |
| Uygun olduğu durum | Küçük, net kapsamlı işler | Fikirden mağazaya tüm süreç | Uygulama şirketin ana ürünüyse |
Çoğu işletme için ilk sürümü bir ajansla çıkarıp, uygulama büyüdükçe iç ekibe geçmek mantıklı bir yoldur. Bu durumda kaynak kodun ve dokümantasyonun size teslim edilmesi kritik hâle gelir.
Bütçe aralığını nasıl belirlersiniz?
Bütçeyi "ne kadar tutar?" sorusuyla değil, "bu uygulama bize ne kazandıracak?" sorusuyla başlatın. Uygulama bir satış kanalıysa beklenen sipariş sayısı, bir verimlilik aracıysa kazanılacak çalışma saati üzerinden düşünün. Ardından:
- İlk sürümü bu bütçenin altında tutacak şekilde MVP listesini daraltın.
- Yıllık giderleri (mağaza hesapları, sunucu, bakım) ayrı bir satır olarak planlayın.
- Yayından sonraki ilk 3–6 ay için geliştirme payı bırakın; gerçek kullanıcı geri bildirimi neredeyse her zaman yeni iş çıkarır.
Bütçe aralığınızı brifte açıkça yazmak, teklif verenlerin size gerçekçi bir kapsam önermesini kolaylaştırır.
Başarıyı nasıl ölçeceksiniz?
Yayından önce hangi göstergeye bakacağınıza karar verin; aksi hâlde uygulamanın işe yarayıp yaramadığını konuşmak zorlaşır:
- İndirme değil, aktif kullanıcı: Haftalık veya aylık geri gelen kullanıcı sayısı
- Ana işin tamamlanma oranı: Sipariş, randevu, kayıt gibi uygulamanın asıl işinin yapılma sayısı
- Kullanıcıyı tutma: İlk hafta ve ilk ay sonunda uygulamayı kullanmaya devam edenlerin oranı
- Mağaza puanı ve yorumlar: Hataları ve eksikleri en hızlı gösteren kaynak
Bu göstergeleri ölçmek için analitik altyapısının ilk sürümde kurulması gerekir; sonradan eklemek geçmiş veriyi kaybettirir.
7. Brif listesi: ilk görüşmeden önce hazırlayın
Ajansa veya yazılımcıya göndereceğiniz bir sayfalık brifte şunlar olsun:
- Tek cümlelik problem tanımı ve hedef kullanıcı
- İlk sürüm özellik listesi ve sonraya bırakılanlar
- Platform tercihi (iOS, Android veya ikisi)
- Yönetim paneli ihtiyacı ve kimlerin kullanacağı
- Bağlanması gereken mevcut sistemler
- Ödeme, bildirim, konum, kamera gibi özel ihtiyaçlar
- Dil sayısı
- Hedef yayın tarihi ve bu tarihin nedeni (sezon, kampanya, yatırım turu)
- Bütçe aralığı
- Yayından sonra bakım beklentisi
8. Teklifleri aynı sorularla karşılaştırın
En az üç teklif alın ve her birine aynı soruları sorun:
| Soru | Neden önemli |
|---|---|
| Hangi teknolojiyle, tek kod tabanı mı ayrı mı geliştirilecek? | Süreyi ve bakım maliyetini belirler |
| Yönetim paneli ve API teklife dahil mi? | Sık atlanan, sonradan büyük maliyet çıkaran kalem |
| Kaynak kod ve mağaza hesapları kimin olacak? | Firmayı değiştirdiğinizde uygulamanızı kaybetmemek için |
| Mağaza yayını ve ret durumları kimin sorumluluğunda? | Apple ve Google incelemesi süreç gerektirir |
| Yayından sonraki bakım nasıl, ücreti ne? | İşletim sistemi güncellemeleri her yıl uyum çalışması gerektirir |
| Canlı ve mağazada yayında örnek gösterebilir misiniz? | Ekran görüntüsü değil, indirilebilir gerçek uygulama görmek için |
Fiyatı belirleyen kalemleri mobil uygulama fiyatları 2026 yazısında ayrıntılı anlattık.
9. Mağaza yayını
Apple Developer Program ve Google Play Console hesaplarının sizin şirketiniz adına açılması gerekir; şirket hesabı için D-U-N-S numarası gibi belgeler hazırlanır, gizlilik politikası ve veri güvenliği formları doldurulur. Adım adım süreci App Store ve Google Play'e uygulama yükleme yazısında anlattık. Yayından sonra mağaza sayfasının görünürlüğü için ASO rehberine bakabilirsiniz.
10. Bakım ve yeni sürümler
Uygulama yayına girdiğinde iş bitmez. Apple ve Google her yıl işletim sistemi güncellemeleri yayınlar; uygulamanın bunlara uyumlu tutulması, hataların düzeltilmesi ve kullanıcı geri bildirimine göre yeni özelliklerin eklenmesi gerekir. Teklif alırken aylık bakım kapsamını ve yeni özellik geliştirmenin nasıl fiyatlanacağını yazılı olarak isteyin.
Hazırlığınız tamamsa bir sonraki adım, kapsamı birlikte netleştirmektir; mobil uygulama yaptırmak için süreci ve örnek projelerimizi hizmet sayfamızda bulabilirsiniz.
Sık yapılan hatalar
- Her şeyi ilk sürüme koymak: Süre uzar, bütçe biter, uygulama kullanıcıyla buluşmadan yorulur.
- Yönetim panelini sona bırakmak: Uygulama hazır olur ama içerik ve siparişleri yönetecek araç yoktur.
- Mağaza hesaplarını yazılımcının adına açtırmak: Firmayla yollar ayrıldığında uygulamanın sahipliği tartışmalı hâle gelir.
- Bakımı bütçelememek: İşletim sistemi güncellemesinden sonra çalışmayan bir uygulama, hiç olmayan bir uygulamadan daha çok güven kaybettirir.
- Ölçümü kurmamak: Hangi ekranın kullanıldığını ve nerede bırakıldığını bilmeden ikinci sürümü planlamak tahmine dayanır.
- Test kullanıcısı olmadan yayına çıkmak: Hedef kitleden birkaç kişiyle yapılacak kısa bir kapalı test, yayın sonrası en sık şikâyetleri önceden yakalar.
Sık Sorulan Sorular
Mobil uygulama yapmak için neler gerekir?
Net bir problem tanımı, hedef kullanıcı, ilk sürümün özellik listesi, platform kararı, yönetim paneli ihtiyacının belirlenmesi ve uygulamanın mağaza hesaplarının açılması gerekir. Teknik tarafta ise tasarım, mobil geliştirme, arka uç (API ve sunucu) ve test aşamaları yer alır.
Mobil uygulama yaptırmak ne kadar sürer?
Kapsamı net bir MVP genellikle birkaç ayda yayına alınabilir; süre ekran sayısına, yönetim paneline, entegrasyonlara ve içerik hazırlığına göre değişir. Mağaza incelemesi de takvime eklenmelidir.
Uygulama fikrimi ajansa anlatırken nasıl korurum?
İlk görüşmeden önce gizlilik sözleşmesi (NDA) isteyebilirsiniz. Sözleşmede kaynak kodun, tasarım dosyalarının ve mağaza hesaplarının size ait olacağının yazılması da en az fikir kadar önemlidir.
Mobil uygulama mı, mobil uyumlu web sitesi mi?
Kullanıcı sık geri gelecekse ve bildirim, konum, kamera gibi telefon özellikleri gerekiyorsa uygulama; ihtiyaç bilgi vermek ve talep toplamaksa mobil uyumlu web sitesi daha doğru bir başlangıçtır.
Yönetim paneli şart mı?
İçerik, kullanıcı, sipariş veya randevu yönetilecekse evet. Panel olmadan her değişiklik için yazılımcıya bağımlı kalırsınız.
Uygulama yayına girdikten sonra ne yapılmalı?
Kullanıcı geri bildirimini toplamak, hataları düzeltmek, işletim sistemi güncellemelerine uyum sağlamak ve mağaza sayfasını (ekran görüntüleri, açıklama, yorumlar) düzenli güncellemek gerekir.
Sonuç
Mobil uygulama yaptırmadan önce en değerli iş, kapsamı yazıya dökmektir: problem, kullanıcı, ilk sürüm, panel ve bakım. Bu hazırlıkla gelen teklifler karşılaştırılabilir olur, proje daha kısa sürede ve daha az sürprizle yayına girer.
