Mobil Uygulama Ajansına Brief Nasıl Verilir?

Bir mobil uygulama fikrini ajansa anlatırken “Yemeksepeti gibi olacak”, “Uber mantığında çalışacak” veya “Trendyol tarzı bir uygulama istiyoruz” demek çoğu zaman yeterli değildir. Bu cümleler fikrin yönünü gösterir; fakat kapsamı, teknik gereksinimi, bütçeyi, kullanıcı akışını ve teslim sürecini netleştirmez.

İyi hazırlanmış bir brief, mobil uygulama geliştirme sürecinde ajansın sadece fiyat vermesini değil, doğru soruları sormasını sağlar. Böylece teklif “kaç ekran yapılacak?” seviyesinde kalmaz; iş modeli, kullanıcı deneyimi, panel ihtiyacı, ödeme altyapısı, bildirim sistemi, güvenlik ve bakım planı birlikte değerlendirilir.

Mobil uygulama pazarı da bu hazırlığı daha kritik hale getiriyor. Sensor Tower’ın 2025 mobil raporuna göre kullanıcılar uygulamalarda yıllık 4,2 trilyon saat geçirdi ve tüketici harcaması 150 milyar dolara ulaştı. GSMA’nın 2026 Mobile Economy raporu ise mobil teknolojilerin 2025’te küresel ekonomiye 7,6 trilyon dolar katkı sunduğunu belirtiyor. Bu ölçekte bir ekosistemde, uygulama yaptırmak sadece yazılım işi değil; ürün, operasyon, pazarlama ve veri yönetimi kararıdır.

Atalay Tech tarafında mobil uygulama, web platformu ve AI entegrasyonu içeren projelerde en sık gördüğümüz fark şudur: Brief net olduğunda teklif daha gerçekçi olur, toplantılar kısalır, revizyonlar azalır ve MVP daha hızlı şekillenir. Brief dağınık olduğunda ise ajans tahmin yapmak zorunda kalır; bu da fiyat, süre ve beklenti tarafında gereksiz sürtüşme oluşturur.

Mobil Uygulama Briefi Nedir?

Mobil uygulama briefi, ajansa “ne yaptırmak istediğinizi” anlatan kısa ama stratejik dokümandır. Bir teknik şartname kadar detaylı olmak zorunda değildir; fakat fikrin hedefini, kullanıcı kitlesini, temel özellikleri, platform tercihini, bütçe aralığını ve teslim beklentisini açıkça ifade etmelidir.

Brief, proje başlamadan önce yazılım ekibine yön veren ilk dokümandır. Ajans bu belgeye bakarak şu sorulara cevap arar:

• Bu uygulama hangi problemi çözüyor?
• İlk versiyonda hangi özellikler mutlaka olmalı?
• Hangi özellikler sonraki faza bırakılabilir?
• Kullanıcı mobil uygulamada hangi adımları izleyecek?
• Yönetim paneli, ödeme sistemi, bildirim ve entegrasyon var mı?
• Proje MVP mi, orta ölçekli ürün mü, kurumsal platform mu?
• Yayın sonrası bakım ve güncelleme beklentisi nedir?

Briefin amacı ajansa her detayı dikte etmek değildir. Doğru amaç, ajansın sizi doğru anlamasını sağlayacak çerçeveyi oluşturmaktır. İyi ajans zaten brief sonrası keşif toplantısında eksik kalan alanları sorar, riskleri gösterir ve daha uygulanabilir bir kapsam çıkarır.

Neden Brief Olmadan Alınan Teklifler Yanıltıcı Olabilir?

Brief olmadan alınan teklifler genellikle üç nedenle yanıltıcı olur: kapsam belirsizliği, teknik varsayım farkı ve teslim standardı farkı.

Örneğin “üyelik sistemi olan bir mobil uygulama” dediğinizde bir ajans sadece e-posta/şifre ile giriş anlar. Başka bir ajans Apple ile giriş, Google ile giriş, SMS doğrulama, KVKK onayı, hesap silme, oturum yönetimi, cihaz bazlı bildirim izni ve admin panelinden kullanıcı yönetimini de hesaba katar.

İki teklif arasında büyük fiyat farkı varsa sebep her zaman “biri pahalı, biri ucuz” değildir. Bazen ajanslardan biri kapsamı gerçekçi okumuş, diğeri ise eksik varsaymıştır.

Bu yüzden mobil uygulama ajansı ile görüşmeden önce brief hazırlamak, sadece ajansın işini kolaylaştırmaz. Sizin de bütçenizi, sürenizi ve ürün beklentinizi daha net yönetmenizi sağlar.

Brief Hazırlamadan Önce Cevaplanması Gereken 7 Soru

Brief yazmaya başlamadan önce şirket içinde kısa bir hazırlık yapmak gerekir. Özellikle karar verici, operasyon ekibi, satış ekibi ve varsa teknik ekip aynı beklentide olmalıdır.

Aşağıdaki sorular, briefin omurgasını oluşturur:

Bu soruların tamamına mükemmel cevap vermeniz gerekmez. Önemli olan ajansa “ne bildiğinizi” ve “neyin henüz netleşmediğini” dürüstçe aktarmaktır.

İyi Bir Mobil Uygulama Briefinde Neler Olmalı?

İyi bir brief kısa, okunabilir ve karar aldıran bir dokümandır. 20 sayfalık karmaşık bir sunum hazırlamak yerine 3-6 sayfalık net bir belge çoğu zaman daha verimlidir.

1. Proje Amacı ve İş Hedefi

Briefin ilk bölümü uygulamanın neden yapılacağını anlatmalıdır. “Mobil uygulama istiyoruz” yerine, uygulamanın ticari hedefini yazmak gerekir.

Örnek:

Mevcut B2B sipariş süreçlerimiz WhatsApp ve telefon üzerinden ilerliyor. Mobil uygulama ile bayilerin ürünleri görmesini, stok durumunu takip etmesini, sipariş vermesini ve kampanya bildirimleri almasını istiyoruz. İlk hedefimiz sipariş operasyonunda manuel iletişimi azaltmak ve tekrar sipariş oranını artırmak.

Bu açıklama, ajansa sadece ekran tasarlatmaz. Ajans bu hedefe göre bildirim, hızlı sipariş, favori ürün, tekrar sipariş ve admin paneli gibi özellikleri önceliklendirebilir.

2. Hedef Kullanıcı ve Persona

Briefte hedef kullanıcı net değilse tasarım kararları da zayıf olur. Kullanıcının yaşı, rolü, cihaz alışkanlığı, teknik seviyesi ve uygulamayı hangi bağlamda kullanacağı yazılmalıdır.

Örnek persona:

Ayşe, 32 yaşında, saha satış yöneticisi. Gün içinde 15-20 bayi ziyareti yapıyor. Ürün stoklarını hızlı kontrol etmek, müşteriye güncel fiyat göstermek ve siparişi ofise dönmeden oluşturmak istiyor. Uzun formlardan hoşlanmıyor; uygulamada en fazla 3-4 adımda işlem bitirmek istiyor.

Bu persona, tasarım ekibine çok şey söyler. Butonların büyük olması, aramanın hızlı çalışması, offline senaryo düşünülmesi, sipariş akışının sade tutulması gibi kararlar doğrudan buradan çıkar.

3. Kullanıcı Senaryoları

Kullanıcı senaryosu, uygulama içindeki gerçek akışı anlatır. Briefte “ürün listesi olacak” demek yerine kullanıcının ne yapacağını adım adım yazmak daha değerlidir.

Örnek senaryo:

1. Kullanıcı telefon numarası veya e-posta ile giriş yapar.
2. Ana ekranda kendisine özel kampanyaları görür.
3. Ürün kategorisine girer ve stokta olan ürünleri filtreler.
4. Ürünü sepete ekler.
5. Teslimat adresini seçer.
6. Siparişi onaylar.
7. Sipariş durumu değiştiğinde push bildirim alır.

Bu akış, ajansın ekran sayısını, API ihtiyaçlarını, panel modüllerini ve bildirim kurgusunu daha doğru analiz etmesini sağlar.

4. Özellik Listesi ve Önceliklendirme

Briefte tüm fikirleri tek seferde “zorunlu” yazmak maliyeti şişirir. Bunun yerine özellikleri MVP, ikinci faz ve opsiyonel olarak ayırmak gerekir.

Atalay Tech projelerinde brief tarafında en çok önerdiğimiz yaklaşım budur: Önce ürünü yayına çıkaracak çekirdek değer belirlenir, sonra ticari geri bildirimlere göre ikinci faz planlanır.

5. Platform Tercihi: iOS, Android veya İkisi Birden

Ajansa brief verirken hangi platformlarda yayın yapılacağı açık olmalıdır. Türkiye’de birçok ticari uygulama için iOS ve Android birlikte düşünülür; fakat bazı B2B veya saha operasyonu projelerinde sadece Android cihazlarla başlamak mantıklı olabilir.

Apple’ın App Store Review Guidelines dokümanı; güvenlik, performans, iş modeli, tasarım ve yasal uygunluk başlıklarını ayrı ayrı ele alır. Google tarafında da Android geliştirici dokümantasyonu performans, izinler, veri güvenliği ve yayın kalitesi için kapsamlı teknik standartlar sunar. Bu yüzden briefte platform tercihi yalnızca “nerede yayınlanacak?” sorusu değildir; mağaza kurallarını, test planını ve veri izinlerini de etkiler.

6. Yönetim Paneli ve Backend İhtiyacı

Mobil uygulama çoğu zaman tek başına çalışmaz. Kullanıcı, içerik, sipariş, ödeme, bildirim ve raporlama gibi alanların yönetileceği bir backend ve yönetim paneli gerekir.

Briefte şu sorulara cevap verilmelidir:

• İçerikleri kim yönetecek?
• Kullanıcılar panelden görülecek mi?
• Sipariş, başvuru veya talep akışı olacak mı?
• Rol ve yetki yönetimi gerekiyor mu?
• Raporlama ekranları olacak mı?
• Panel çok dilli mi çalışacak?
• Log, hata takibi ve işlem geçmişi tutulacak mı?

Örneğin bir eğitim uygulamasında mobil tarafta ders videoları ve quizler yer alabilir. Fakat içerik ekleme, öğrenci takibi, abonelik durumu, izlenme raporu ve bildirim gönderimi panelden yönetilecekse asıl kapsamın önemli kısmı backend tarafındadır.

7. Entegrasyonlar: Ödeme, Kargo, ERP, CRM ve AI

Briefte entegrasyonlar net yazılmadığında proje süresi ciddi şekilde değişebilir. Basit bir katalog uygulaması ile ERP stok verisi, sanal POS, kargo takip ve CRM entegrasyonu olan bir uygulama aynı şey değildir.

Atalay Tech’in mobil uygulama, web platformu ve AI entegrasyonu deneyiminde en kritik nokta şudur: Entegrasyon “sonra bakarız” denildiğinde çoğu zaman proje sonunda gecikme yaratır. API dokümantasyonu, test hesabı ve veri örnekleri brief aşamasında paylaşılırsa ajans daha sağlıklı planlama yapar.

Mobil Uygulama Briefi İçin Örnek Şablon

Aşağıdaki şablon, ajansa gönderilecek ilk brief için kullanılabilir. Her başlığın altına kısa ve somut cevaplar yazmak yeterlidir.

Bu şablon, ilk görüşmede ajansın sizi daha iyi anlamasını sağlar. Fakat brief sabit bir sözleşme değildir; keşif toplantısı sonrası kapsam, fazlar ve teknik yaklaşım birlikte olgunlaştırılmalıdır.

Briefte Bütçe Aralığı Vermek Gerekir mi?

Evet, çoğu durumda bütçe aralığı vermek gerekir. Bütçe söylemek “ajans fiyatı şişirir” anlamına gelmez; doğru ajans bütçeye göre kapsamı optimize eder.

Bütçe bilgisi verilmediğinde ajans üç farklı şekilde teklif hazırlayabilir: minimum MVP, orta ölçekli ürün veya kurumsal kapsam. Bu da tekliflerin karşılaştırılmasını zorlaştırır.

Aşağıdaki aralıklar 2026 Türkiye pazarında profesyonel ajans işi için tahmini referans olarak düşünülmelidir. Kapsam, entegrasyon, tasarım seviyesi, panel ihtiyacı, ekip yoğunluğu ve teslim takvimine göre değişebilir.

Bütçe aralığı, ajansın size “bu bütçeyle neleri ilk faza alalım?” sorusunu sormasını sağlar. Bu yaklaşım, mobil uygulama fiyatları konusunda daha gerçekçi bir değerlendirme yapmanıza da yardımcı olur.

Briefte Tasarım Beklentisi Nasıl Anlatılır?

Tasarım beklentisi sadece renk ve logo değildir. Mobil uygulamanın kullanım hızı, ekran yoğunluğu, buton yerleşimi, okunabilirlik, erişilebilirlik ve kullanıcı güveni tasarım briefinin parçasıdır.

Ajansa şu bilgileri vermek faydalıdır:

• Marka kimliği hazır mı?
• Logo, renk paleti ve font ailesi var mı?
• Referans alınan uygulamalar hangileri?
• Hangi uygulamalar kesinlikle örnek alınmamalı?
• Kullanıcı hızlı işlem mi yapacak, içerik mi tüketecek?
• Koyu mod veya açık mod beklentisi var mı?
• Uygulama kurumsal mı, genç ve dinamik mi, premium mu görünmeli?

Örneğin bir finans uygulamasında güven hissi, sade ekranlar ve net işlem onayı önemlidir. Bir sosyal topluluk uygulamasında ise profil, gönderi, etkileşim ve bildirim deneyimi daha öne çıkar. Aynı “iyi tasarım” ifadesi bu iki uygulamada farklı sonuçlar doğurur.

MVP Kapsamı Briefte Nasıl Belirlenir?

MVP, ürünün en küçük ama değer üreten ilk versiyonudur. Briefte MVP belirlemek, maliyeti düşürmekten ibaret değildir; öğrenme hızını artırır.

Yanlış MVP yaklaşımı şudur: “Tüm özellikleri koyalım, sonra kullanıcıya çıkarız.”

Doğru MVP yaklaşımı şudur: “Kullanıcının ana problemi çözülene kadar gereken minimum özellikleri ilk faza alalım, geri kalanları veriye göre planlayalım.”

Mobile uygulama yaptırmak isteyen firmalar için en sağlıklı yaklaşım, ajansa “bize her şeyi yapın” demek yerine “ilk 90 günde hangi değerli ürünü çıkarabiliriz?” sorusunu sormaktır.

Ajansa Gönderilecek Briefte Teknik Detay Ne Kadar Olmalı?

Teknik ekip olmayan bir şirketin React Native, native iOS, Kotlin, Swift, Laravel, Node.js veya cloud mimarisi konusunda karar vermesi şart değildir. Fakat bazı teknik beklentileri açıkça yazmak gerekir.

Briefte teknik karar dikte etmek yerine ihtiyaç belirtmek daha doğru olur.

Örneğin:

• “Uygulama iOS ve Android’de aynı anda yayınlanmalı.”
• “Kullanıcı hesabını silebilmeli.”
• “KVKK onayı ve açık rıza metinleri gösterilmeli.”
• “Ödeme alındığında panelde sipariş durumu güncellenmeli.”
• “Bildirimler kullanıcı segmentine göre gönderilebilmeli.”
• “Video içerikler güvenli şekilde izlenmeli.”
• “Yönetici, kullanıcı işlemlerini panelden takip edebilmeli.”

Bu ihtiyaçlar ajansın doğru mimariyi önermesini sağlar. Atalay Tech tarafında örneğin mobil uygulama ile web panelin birlikte çalıştığı projelerde, sadece uygulama ekranları değil; API yapısı, veri modeli, rol/yetki sistemi, medya depolama, bildirim altyapısı ve bakım süreci birlikte değerlendirilir.

Briefte Teslim Süreci Nasıl Tanımlanmalı?

Mobil uygulama projelerinde teslim süreci tek bir “bitti” anından oluşmaz. Keşif, tasarım, geliştirme, test, mağaza yayını ve bakım aşamaları ayrı ayrı planlanmalıdır.

Apple’ın App Store tarafında uygulamalar güvenlik, performans, iş modeli, tasarım ve yasal uygunluk gibi kategorilerde incelenir. Google Play tarafında da veri güvenliği, izinler, hedef API seviyesi ve yayın politikaları proje planını etkiler. Bu nedenle briefte mağaza yayını “son adım” gibi görünse bile, yasal metinler ve hesap süreçleri baştan düşünülmelidir.

Briefte Sözleşme ve Bakım Beklentisi Nasıl Yazılmalı?

Brief, sözleşmenin yerine geçmez; fakat sözleşme için zemin hazırlar. Ajansa daha ilk aşamada bakım, hata desteği, revizyon hakkı, kaynak kod teslimi, sunucu yönetimi ve mağaza hesapları konusunda beklentinizi yazmanız faydalıdır.

Şu başlıklar özellikle net olmalıdır:

• Proje sonunda kaynak kod teslim edilecek mi?
• Sunucu kimin hesabında barınacak?
• App Store ve Google Play hesapları kime ait olacak?
• Yayın sonrası hata desteği kaç ay sürecek?
• Yeni özellik talepleri nasıl fiyatlandırılacak?
• Bakım paketi aylık mı, saatlik mi olacak?
• Acil müdahale süresi nasıl tanımlanacak?
• KVKK, gizlilik politikası ve kullanım şartları kim tarafından sağlanacak?

Bu konular briefte yazıldığında ajans teklifini daha gerçekçi oluşturur. Aksi halde proje tesliminde “bu dahil miydi?” tartışmaları yaşanabilir.

Zayıf Brief ve Güçlü Brief Arasındaki Fark

Aynı fikri iki farklı şekilde anlatmak, ajansın size tamamen farklı teklif vermesine neden olabilir.

Güçlü brief, ajansı köşeye sıkıştırmaz; aksine daha doğru çözüm üretmesini sağlar. Bu da hem teklif kalitesini hem de proje disiplinini artırır.

Mobil Uygulama Briefi Göndermeden Önce Kontrol Listesi

Briefi ajansa göndermeden önce aşağıdaki maddeleri kontrol edebilirsiniz:

• Proje amacı tek paragrafta net mi?
• Hedef kullanıcı gerçekçi şekilde tanımlandı mı?
• MVP özellikleri ayrı yazıldı mı?
• İkinci faz özellikleri ayrıldı mı?
• Platform tercihi belirtildi mi?
• Panel ihtiyacı yazıldı mı?
• Entegrasyonlar listelendi mi?
• Bütçe aralığı verildi mi?
• Hedef yayın tarihi gerçekçi mi?
• Tasarım beklentisi örneklerle anlatıldı mı?
• Bakım ve destek beklentisi belirtildi mi?
• Yasal metinler, KVKK ve mağaza hesapları düşünüldü mü?

Bu listeyi tamamladığınızda ajansla yapacağınız ilk görüşme çok daha verimli olur. Görüşme sonunda sadece “fiyat ne olur?” sorusuna değil, “bu ürün nasıl daha doğru fazlandırılır?” sorusuna da cevap alırsınız.

Ajans Briefi Aldıktan Sonra Ne Yapmalı?

Profesyonel bir ajans briefi aldıktan sonra doğrudan tek satırlık fiyat göndermemelidir. Önce kapsamı anlamalı, eksik alanları sormalı ve riskleri belirtmelidir.

Sağlıklı süreç genellikle şu şekilde ilerler:

1. Brief incelenir.
2. Keşif toplantısı yapılır.
3. Kullanıcı akışları ve teknik ihtiyaçlar netleşir.
4. MVP ve sonraki fazlar ayrılır.
5. Tasarım, backend, mobil uygulama ve panel kapsamı belirlenir.
6. Süre, ekip, ödeme planı ve bakım modeli tekliflendirilir.
7. Sözleşme ve proje takvimi hazırlanır.

Bu yaklaşım, özellikle orta ve kurumsal ölçekteki mobil uygulamalarda daha güvenlidir. Çünkü mobil uygulama sadece ekranlardan oluşmaz; veri, operasyon, güvenlik, mağaza yayını ve bakım tarafıyla birlikte yaşayan bir üründür.

Brief Hazırlarken Yapılan En Yaygın Hatalar

Brief hazırlarken en çok karşılaştığımız hatalar şunlardır:

• Rakip uygulamayı birebir kopyalamaya çalışmak
• Tüm özellikleri ilk faza sıkıştırmak
• Bütçe aralığını tamamen gizlemek
• Yönetim panelini “küçük bir detay” gibi görmek
• Entegrasyonların teknik zorluğunu hafife almak
• App Store ve Google Play süreçlerini sona bırakmak
• Test ve bakım süresini planlamamak
• Karar vericileri brief aşamasına dahil etmemek
• Kullanıcı senaryosu yerine sadece özellik listesi yazmak

Örneğin bir pazaryeri uygulamasında “satıcı paneli” küçük bir özellik değildir. Ürün ekleme, stok, sipariş, komisyon, ödeme, iade, bildirim, belge doğrulama ve raporlama gibi alt modüller doğurur. Briefte bu alanlar netleşmediğinde teklif düşük görünür; fakat proje ilerledikçe kapsam genişler.

Atalay Tech Perspektifi: Briefi Ürün Stratejisine Dönüştürmek

Atalay Tech olarak mobil uygulama, web platformu, yönetim paneli ve AI entegrasyonu içeren projelerde briefi sadece talep dokümanı olarak ele almıyoruz. Briefi, ürün stratejisinin ilk versiyonu olarak görüyoruz.

Bir müşterinin “mobil uygulama istiyoruz” talebi çoğu zaman şu alt başlıklara ayrılır:

• Kullanıcı deneyimi nasıl sadeleşecek?
• Hangi işlem mobilde gerçekten değerli?
• Hangi veriler panelden yönetilecek?
• Hangi entegrasyon ilk faz için şart?
• Hangi özellikler lansmandan sonra öğrenilerek geliştirilmeli?
• Yayın sonrası bakım ve yeni sürüm takvimi nasıl ilerlemeli?

Bu nedenle brief ne kadar net olursa, ajansın teknik ve stratejik katkısı da o kadar güçlenir. Eğer amacınız sadece fiyat almak değil, uygulanabilir bir ürün yol haritası çıkarmaksa mobil uygulama ajansı seçerken brief değerlendirme yaklaşımına da bakmanız gerekir.