Mobil Uygulama Yaptırmak: Fikirden Teklife Proje Briefi

Mobil Uygulama Yaptırmak: Fikirden Teklife Proje Briefi

Kısaca: Mobil uygulama yaptırmak için önce ekran çizmek değil, çözülecek problemi ve ilk sürümün başarısını tanımlamak gerekir. İyi bir proje briefi; hedef kullanıcıyı, temel akışları, iOS/Android kapsamını, yönetim panelini, entegrasyonları, veri ve hesap sahipliğini, yayın sorumluluğunu ve bakım beklentisini açıklar. Böylece firmalardan aynı kapsam için karşılaştırılabilir teklif alırsınız.

“Uber gibi”, “Trendyol benzeri” veya “basit bir randevu uygulaması” yazmak teklif için yeterli değildir. Bu ürünlerin görünmeyen tarafında kullanıcı rolleri, bildirim, ödeme, destek, raporlama, güvenlik, mağaza yayını ve operasyon bulunur. Kapsam belirsizse firmalar farklı varsayımlar yapar; fiyat ve süreler bu yüzden birbirinden kopar.

Mobil Uygulama Briefinde Olması Gereken 10 Bölüm

1. İş Problemi ve Hedef

Uygulamanın ne yapacağını değil, hangi sorunu çözeceğini tek paragrafta yazın. Örneğin “müşteriler randevu alsın” yerine “telefonla randevu yükünü azaltmak, uygun saatleri gerçek zamanlı göstermek ve gelmeyen müşterileri hatırlatmayla azaltmak” daha ölçülebilirdir.

2. Hedef Kullanıcılar ve Roller

Müşteri, çalışan, bayi, kurye ve yönetici aynı ekranları kullanmaz. Her rolün görebileceği veri ve yapabileceği işlemi ayırın. Yetki modeli sonradan eklenen küçük bir özellik değil, ürün mimarisidir.

3. İlk Sürümün Ana Akışları

Kullanıcının tamamlaması gereken en kritik üç ila beş akışı yazın:

1. Kayıt veya misafir kullanım
2. Ürün/hizmet bulma
3. Seçim veya rezervasyon
4. Ödeme ya da talep gönderme
5. İşlem sonucunu takip etme

Her olası özelliği ilk sürüme koymak yerine ürünün değerini kanıtlayan minimum akışları seçin.

4. Ekran ve Özellik Listesi

Modül	Temel kapsam	Karar verilmesi gereken konu
Üyelik	Kayıt, giriş, şifre yenileme	Telefon, e-posta veya sosyal giriş?
Profil	Kişisel bilgiler ve tercihler	Hangi veri zorunlu?
Arama	Liste, filtre ve detay	Konum veya kişiselleştirme var mı?
İşlem	Sepet, randevu, teklif veya sipariş	İptal ve değişiklik nasıl çalışır?
Bildirim	Push, e-posta veya SMS	Hangi olay hangi kanalı tetikler?
Destek	SSS, talep veya canlı yardım	Mesai ve yanıt sorumluluğu kimde?
Yönetim	İçerik, kullanıcı ve rapor	Web panelinde kim neyi yönetir?

5. iOS, Android ve Teknoloji Kararı

Hedef kitlenin cihaz dağılımı, performans ihtiyacı, cihaz özelliği kullanımı ve ekip planı teknoloji kararını etkiler. Native veya cross-platform seçimini yalnızca ilk geliştirme fiyatına göre vermeyin. Güncelleme, test ve ekip bulunabilirliği de toplam maliyete dâhildir.

Seçenekleri karşılaştırmak için MVP, native ve cross-platform rehberini okuyabilirsiniz.

6. Backend, Yönetim Paneli ve Entegrasyonlar

Mobil ekran, sistemin yalnızca görünen kısmıdır. Kullanıcı, içerik, sipariş, randevu veya kampanyanın yönetileceği bir web paneli gerekebilir. Mevcut ERP, CRM, ödeme, harita, kargo, muhasebe veya kimlik sistemleri listelenmelidir.

Her entegrasyon için şu dört soruya cevap verin:

• Verinin sahibi hangi sistem?
• Veri hangi yönde ve ne sıklıkla akacak?
• Hata olduğunda ne yapılacak?
• API erişimi ve dokümantasyonu hazır mı?

7. Veri, Güvenlik ve Gizlilik

Toplanacak veriyi ihtiyaçla sınırlandırın. Kamera, konum, rehber, sağlık veya ödeme verisi isteniyorsa neden gerekli olduğunu ve kimlerin erişeceğini yazın. KVKK kapsamı işletme ve veri türüne göre değerlendirilmelidir; güncel kararlar ve rehberler için Kişisel Verileri Koruma Kurumu birincil kaynaktır.

8. Mağaza Hesapları ve Yayın Sorumluluğu

Apple Developer ve Google Play Console hesaplarının kimin adına açılacağını baştan belirleyin. Tercihen şirket hesap sahibi, geliştirme firması yetkili kullanıcı olmalıdır. Uygulama adı, gizlilik sayfası, mağaza görselleri, test kullanıcıları ve inceleme yanıtları da yayın planına dâhildir.

Google'ın güncel kalite çerçevesi için Android Core App Quality, Apple gönderim ilkeleri için App Review Guidelines sayfaları takip edilmelidir.

9. Başarı Metrikleri

İndirme sayısı tek başına başarı değildir. Ürüne göre aktivasyon, ilk işlem tamamlama, randevu, sipariş, haftalık aktif kullanıcı, tekrar kullanım, hata oranı veya destek talebi gibi metrikler seçin. Analitik olayları geliştirme başlamadan tanımlamak sonradan veri kaybını önler.

10. Takvim, Bütçe ve Bakım Beklentisi

Kesin bütçeniz olmasa bile yatırım aralığını ve ticari son tarihi açıklayın. Firma ilk sürüm kapsamını buna göre önceliklendirebilir. Yayın sonrası hata müdahalesi, işletim sistemi uyumu, sunucu, mağaza güncellemesi ve yeni özelliklerin nasıl yönetileceğini ayrıca sorun.

Kopyalayıp Kullanabileceğiniz Kısa Brief Şablonu

Projenin amacı:
Hedef kullanıcılar ve roller:
Çözülecek ana problem:
İlk sürümün 3-5 kritik akışı:
Zorunlu ekranlar:
Yönetim panelinde yapılacak işler:
Mevcut sistemler ve entegrasyonlar:
Toplanacak hassas veriler ve izinler:
iOS / Android kapsamı:
Ödeme, bildirim, konum ve çevrimdışı kullanım ihtiyacı:
Analitik ve başarı metrikleri:
Mağaza hesabı ve yayın sorumluluğu:
Hedef tarih ve yatırım aralığı:
Bakım ve destek beklentisi:

Teklifleri Nasıl Karşılaştırmalısınız?

Başlık	Teklifte görünmesi gereken teslim
Keşif	Akış, kapsam ve teknik plan
Tasarım	Ekran sayısı, prototip ve revizyon
Geliştirme	Platform, modül ve entegrasyon listesi
Test	Cihaz, işletim sistemi ve kabul senaryoları
Yayın	Mağaza hazırlığı ve inceleme desteği
Sahiplik	Kaynak kod, tasarım, hesap ve veri
Dokümantasyon	Kurulum, API ve yönetim paneli rehberi
Bakım	Garanti, yanıt süresi ve kapsam dışı işler

Sadece toplam fiyat ve teslim tarihine bakmayın. Hangi varsayımların yapıldığını ve hangi işlerin kapsam dışı olduğunu okuyun. Çok düşük teklif genellikle bazı görünmeyen modüllerin hiç hesaplanmadığını gösterir; yüksek teklif ise otomatik olarak daha iyi ürün garantisi değildir.

Sık Yapılan Hatalar

• Rakip uygulamayı kopyalamanın yeterli olduğunu düşünmek
• Yönetim panelini ve operasyon ekibini unutmamak
• Tüm özellikleri ilk sürüme koymak
• Mağaza hesaplarını firma adına açtırmak
• Analitik planını yayın sonrasına bırakmak
• API erişimi hazır değilken entegrasyon süresini kesin kabul etmek
• Garanti, bakım ve yeni özellik geliştirmeyi aynı şey sanmak
• Kaynak kod ve veri devrini sözleşmede yazmamak

Sıkça Sorulan Sorular

Mobil uygulama yaptırmak için fikrim yeterli mi?

Başlangıç için evet; teklif ve geliştirme için hayır. Fikir hedef kullanıcı, ana akışlar, operasyon, entegrasyon ve başarı ölçütleriyle doğrulanabilir bir kapsama dönüştürülmelidir.

Mobil uygulama fiyat teklifi almak için ekran tasarımı şart mı?

Şart değildir. Akış ve modül listesi fiyat aralığı için yeterli olabilir. Ancak sabit kapsam ve sözleşme öncesinde ekran/prototip çalışması belirsizliği ciddi biçimde azaltır.

Önce iOS mu Android mi yapılmalı?

Hedef kitlenin cihazları, ürünün kullandığı cihaz özellikleri ve doğrulama hedefi belirleyicidir. Cross-platform tek kod tabanıyla iki mağazayı hedefleyebilir; fakat her ürün için otomatik olarak doğru seçim değildir.

Uygulamanın yönetim paneli fiyata dâhil midir?

Teklife göre değişir. İçerik, kullanıcı, sipariş veya rapor yönetilecekse panel ayrı bir ürün yüzeyidir ve ekranları, rolleri, testleriyle kapsamda yazılmalıdır.

Uygulamayı mağazaya kim yükler?

Geliştirme firması teknik gönderimi yapabilir; ancak hesap sahibi, politika beyanları, şirket bilgileri ve nihai sorumluluk baştan belirlenmelidir. Hesapların işletme adına olması devir riskini azaltır.

İlk sürümden sonra ne olur?

Kullanım verisi ve geri bildirim izlenir; kritik hatalar düzeltilir, işletim sistemi ve mağaza koşulları takip edilir, yeni özellikler ayrı yol haritasına alınır. Ayrıntı için mobil uygulama bakım rehberini inceleyin.

Sonuç

İyi brief, uygulamayı kısıtlamaz; belirsiz varsayımları görünür kılar. Ekibinizin hangi problemi çözdüğünü, ilk sürümün neyi kanıtlayacağını ve sistemin kim tarafından işletileceğini yazdığınızda tekliflerin fiyatı, süresi ve riski karşılaştırılabilir hâle gelir.

Maliyet kalemlerini görmek için mobil uygulama fiyatları rehberimizi, teknik ve ürün kapsamı için mobil uygulama hizmetimizi inceleyebilirsiniz. Briefinizi birlikte netleştirmek için ekibimizle görüşün.