Mobil uygulama projesi başlatmadan önce sorulacak sorular, projenin yalnızca “uygulama fikri güzel mi?” seviyesinde kalmasını engeller. Doğru sorular; bütçeyi, geliştirme süresini, teknik kapsamı, kullanıcı deneyimini, güvenliği ve teslim sonrası bakım sorumluluklarını daha baştan netleştirir.
Bir işletme mobil uygulama yaptırmaya karar verdiğinde genellikle ilk refleks “kaç paraya yapılır?” sorusudur. Bu soru yanlış değildir; fakat tek başına yeterli değildir. Çünkü aynı fikir, kapsamına göre 350.000 TL’lik bir MVP de olabilir, 3.000.000 TL üzeri kurumsal bir dijital ürün de olabilir.
Atalay Tech olarak mobil uygulama, web platformu ve yapay zekâ entegrasyonu projelerinde gördüğümüz en kritik fark şudur: Başlangıçta iyi sorular soran müşteriler, proje ilerledikçe daha az revizyon, daha az belirsizlik ve daha sağlıklı teslim süreci yaşar. Özellikle mobil uygulama geliştirme sürecinde keşif aşaması ne kadar netse, tasarım ve yazılım üretimi de o kadar kontrollü ilerler.
İlk soru fikrin “uygulama” olup olmadığı değil, hangi problemi çözdüğüdür. Mobil uygulama; müşteriye daha hızlı erişim, tekrar kullanım, bildirim gönderimi, üyelik sistemi, ödeme akışı, içerik tüketimi veya operasyon yönetimi gibi net bir iş problemi çözmelidir.
Örneğin bir spor salonu için mobil uygulama fikri ilk bakışta “üyeler giriş yapsın, programlarını görsün” gibi basit görünebilir. Fakat gerçek problem randevu takibi, üyelik yenileme, eğitmen müsaitliği, otomatik ödeme, gelişim ölçümü ve bildirim yönetimi olabilir. Bu fark, kapsamı doğrudan değiştirir.
Mobil uygulama projesi başlatmadan önce şu sorular yazılı cevaplanmalıdır:
Burada amaç fikri küçültmek değildir. Amaç, yazılım bütçesini gerçekten değer üreten modüllere yönlendirmektir.
Mobil uygulama kararında persona çalışması yalnızca pazarlama dokümanı değildir. Yazılım kapsamını, ekran akışını, bildirim stratejisini, üyelik yapısını ve veri modelini belirler.
Örneğin Ayşe, 32 yaşında bir klinik yöneticisi olsun. Kliniğinde randevuları WhatsApp üzerinden takip ediyor, danışan geçmişini Excel’de tutuyor ve ödeme hatırlatmalarını manuel yapıyor. Ayşe için mobil uygulama fikri “klinik uygulaması” değildir; asıl ihtiyaç randevu, danışan geçmişi, ödeme takibi ve bildirim otomasyonudur.
Başka bir senaryoda Mehmet, 41 yaşında bir saha operasyon müdürü olsun. Ekibi farklı lokasyonlarda çalışıyor, görev tamamlanma durumları geç raporlanıyor ve fotoğraflı kanıtlar dağınık WhatsApp gruplarında kalıyor. Mehmet için mobil uygulamanın değeri; görev atama, konum doğrulama, offline kayıt ve yönetim paneline anlık veri aktarımıdır.
Bu nedenle hedef kullanıcıyı belirlerken sadece demografik bilgi yetmez. Kullanıcının uygulamayı hangi anda açacağı da yazılmalıdır.
| Soru | Zayıf Cevap | Güçlü Cevap |
|---|---|---|
| Kullanıcı kim? | Herkes kullanabilir | İstanbul’daki saha satış ekipleri |
| Hangi problem çözülüyor? | İşleri kolaylaştıracak | Günlük ziyaret raporları 24 saat gecikiyor |
| Ne zaman açacak? | İhtiyaç olunca | Müşteri ziyareti başında ve sonunda |
| Başarı ölçütü ne? | Kullanıcı beğensin | Rapor gecikmesi %70 azalsın |
| İlk sürüm hedefi ne? | Tüm özellikler olsun | Görev, konum, fotoğraf, rapor akışı |
Bu tablo, mobil uygulama brief’inin ilk sayfasında yer alabilecek kadar kritiktir. Çünkü hedef kullanıcı belirsizse, ekran tasarımı da yazılım mimarisi de belirsiz kalır.
Mobil uygulama projesi başlatmadan önce cevaplanması gereken en önemli sorulardan biri, ilk sürümün MVP mi yoksa kapsamlı kurumsal ürün mü olacağıdır. MVP, düşük kalite anlamına gelmez. MVP, doğru özellikleri seçerek pazara daha hızlı çıkmak anlamına gelir.
Örneğin bir pazar yeri uygulamasında ilk fikir; satıcı paneli, alıcı uygulaması, kargo entegrasyonu, sanal POS, yorum sistemi, kupon, canlı destek, gelişmiş öneri algoritması ve kampanya yönetimi içerebilir. Fakat ilk sürümde asıl doğrulanması gereken şey alıcı-satıcı eşleşmesi ve sipariş akışıdır.
Atalay Tech’in mobil projelerde önerdiği yaklaşım genellikle şu ayrımdır:
| Seviye | Kapsam | Tahmini Süre | Tahmini Bütçe |
|---|---|---|---|
| MVP | Üyelik, ana akış, temel panel, bildirim, basit raporlama | 6-10 hafta | 350.000 - 900.000 TL + KDV |
| Orta Ölçek | Ödeme, gelişmiş filtre, rol yönetimi, entegrasyon, analitik | 10-16 hafta | 900.000 - 2.000.000 TL + KDV |
| Kurumsal | Çoklu rol, ERP/CRM entegrasyonu, yüksek trafik mimarisi, SLA, gelişmiş güvenlik | 16-28 hafta | 2.000.000 - 5.000.000 TL+ + KDV |
| Sürekli Ürün | Versiyon bazlı geliştirme, A/B test, growth backlog, bakım ekibi | Aylık döngü | Proje + aylık destek modeli |
Bu aralıklar sektör, kapsam, entegrasyon sayısı, tasarım derinliği ve güvenlik beklentisine göre değişir. Daha net bir bütçe hesabı için mobil uygulama fiyatları aracından yararlanmak, ilk görüşmeden önce iyi bir hazırlık sağlar.
Mobil uygulama fikrinin başarılı sayılması için ölçülebilir hedef gerekir. “Güzel bir uygulama olsun” hedef değildir. “İlk 3 ayda 5.000 kayıt, %35 aylık aktif kullanıcı oranı ve 1.000 tamamlanan işlem” ise ölçülebilir hedeftir.
Data.ai’nin 2025 raporuna göre kullanıcılar mobilde ciddi zaman geçirirken, uygulama mağazalarındaki rekabet de büyümeye devam ediyor. Statista tarafındaki mobil uygulama gelir tahminleri de pazarın milyarlarca dolarlık ölçekte olduğunu gösteriyor. Bu veriler fırsatı gösterir; fakat her uygulamanın başarılı olacağı anlamına gelmez. Başarı, doğru metriklerin tasarım aşamasında belirlenmesiyle başlar.
Ölçülmesi gereken temel metrikler şunlardır:
Bir mobil uygulama projesi başlatmadan önce “başarı” kelimesinin şirket içinde aynı anlama gelip gelmediği netleştirilmelidir. Yönetici ekibi indirme sayısına bakarken operasyon ekibi işlem tamamlama oranına bakıyorsa, proje sonunda değerlendirme karmaşası yaşanır.
Mobil uygulama projelerinde en sık yapılan hata, tüm fikirleri ilk sürüme koymaya çalışmaktır. Bu yaklaşım hem maliyeti artırır hem de yayın tarihini geciktirir. Daha önemlisi, kullanıcıdan erken geri bildirim alma şansını azaltır.
Özellikleri seçerken “olsa güzel olur” ile “olmazsa ürün çalışmaz” ayrımı yapılmalıdır. Örneğin bir randevu uygulamasında takvim, kullanıcı hesabı ve bildirim kritik olabilir. Ancak sadakat puanı, rozet sistemi veya gelişmiş kampanya ekranı ikinci faza bırakılabilir.
| Özellik Türü | İlk Sürüme Alınmalı mı? | Örnek |
|---|---|---|
| Çekirdek akış | Evet | Kayıt, giriş, ana işlem, profil |
| Gelir akışı | Çoğu projede evet | Ödeme, abonelik, teklif talebi |
| Operasyon paneli | Evet | İçerik, kullanıcı, sipariş, randevu yönetimi |
| Pazarlama modülü | Duruma göre | Kupon, kampanya, referans kodu |
| Sosyal özellikler | İhtiyaca göre | Takip, beğeni, yorum, mesajlaşma |
| Yapay zekâ modülü | Değer üretiyorsa | Akıllı öneri, otomatik sınıflandırma, metin analizi |
| Gelişmiş raporlama | İkinci faz olabilir | Segment bazlı grafikler, özel dashboard |
Atalay Tech’in mobil uygulama, web platformu ve AI entegrasyonu projelerinde tercih ettiği yöntem, ilk görüşmede özellikleri fazlara ayırmaktır. Böylece müşteri hem ilk yayına daha hızlı ulaşır hem de bütçesini gerçek kullanıcı verisine göre yönetebilir.
Teknoloji kararı yalnızca yazılım ekibinin tercihi değildir. Bütçe, süre, hedef kullanıcı kitlesi, performans ihtiyacı, cihaz özellikleri ve bakım planı teknoloji seçimini etkiler.
React Native, birçok ticari mobil uygulama için güçlü bir seçenektir. Tek kod tabanıyla iOS ve Android uygulama geliştirme imkânı verdiği için maliyet ve süre açısından avantaj sağlar. Native iOS ve native Android ise çok yüksek performans, özel cihaz donanımı veya platforma özgü deneyim gereken projelerde öne çıkar.
| Kriter | React Native | Native iOS/Android | No-Code |
|---|---|---|---|
| İlk geliştirme süresi | Hızlı | Daha uzun | Çok hızlı |
| iOS + Android maliyeti | Daha verimli | Daha yüksek | Düşük/orta |
| Performans | Çoğu iş için yüksek | En yüksek | Sınırlı |
| Tasarım esnekliği | Yüksek | Çok yüksek | Platforma bağlı |
| Entegrasyon kabiliyeti | Yüksek | Çok yüksek | Sınırlı |
| Uzun vadeli bakım | Yönetilebilir | İki ekip gerekebilir | Araç bağımlılığı yüksek |
| Uygun proje tipi | MVP, pazar yeri, sosyal, kurumsal | Yoğun donanım, kamera, AR, oyun | Basit form, iç süreç, prototip |
Burada kritik soru şudur: Uygulamanızın rekabet avantajı teknoloji detayında mı, yoksa iş modelinde ve kullanıcı deneyiminde mi? Çoğu işletme için ilk amaç, güvenilir bir ürünle pazara çıkmak ve kullanıcı davranışını ölçmektir. Bu nedenle mobil uygulama yaptırmak isteyen işletmelerin teknoloji kararını bütçe, zaman ve ölçeklenebilirlik dengesine göre vermesi daha sağlıklıdır.
Google’ın Android geliştirici dokümantasyonu ve Apple’ın Human Interface Guidelines kaynakları, platform uyumunun yalnızca kod değil kullanıcı deneyimi açısından da düşünülmesi gerektiğini gösterir. Bildirim izinleri, navigasyon davranışı, ödeme kuralları ve mağaza inceleme süreçleri teknoloji kararının parçasıdır.
Mobil uygulama tek başına çalışan bir ekranlar bütünü değildir. Çoğu projede arka planda API, veritabanı, yönetim paneli, bildirim sistemi, dosya depolama, ödeme altyapısı ve üçüncü parti entegrasyonlar bulunur.
Örneğin bir video içerik platformunda mobil uygulama yalnızca kullanıcının gördüğü taraftır. Asıl operasyon; video yükleme, dönüştürme, kategori yönetimi, kullanıcı yetkileri, ödeme takibi, içerik onayı ve raporlama panelinde gerçekleşir.
Proje başlamadan önce şu entegrasyonlar ayrıca yazılmalıdır:
Yönetim paneli ihmal edilirse, uygulama yayına çıktıktan sonra operasyon manuel ilerler. Bu da yazılımın değerini düşürür. Bu nedenle iyi bir mobil uygulama şirketi, yalnızca mobil ekranları değil, uygulamanın arkasındaki iş akışını da sorgular.
Mobil uygulama projesi başlatmadan önce güvenlik başlığı “sonradan bakarız” denilecek bir konu değildir. Kullanıcı hesabı, telefon numarası, ödeme bilgisi, sağlık verisi, konum bilgisi veya mesajlaşma içeren projelerde güvenlik mimarisi başlangıçta planlanmalıdır.
Örneğin bir sağlık topluluğu uygulamasında kullanıcı profili, mesajlaşma, dosya paylaşımı ve özel içerikler bulunuyorsa, sadece giriş ekranının çalışması yeterli değildir. Yetkilendirme, oturum süresi, loglama, veri saklama politikası, hesap silme ve açık rıza süreçleri de kapsamın parçasıdır.
Sorulması gereken temel güvenlik soruları:
Türkiye’de kişisel veri işleme süreçleri için KVKK resmî sitesi temel referanslardan biridir. Avrupa pazarına açılacak projelerde ise GDPR tarafı ayrıca değerlendirilmelidir.
Uygulama geliştirme bitince proje otomatik olarak App Store ve Google Play’de yayınlanmış sayılmaz. Mağaza hesapları, şirket bilgileri, gizlilik politikası, ekran görüntüleri, uygulama açıklaması, izin gerekçeleri, test hesapları ve inceleme süreçleri hazırlanmalıdır.
Özellikle üyelik, ödeme, sağlık, finans, kullanıcı içeriği veya mesajlaşma içeren uygulamalarda mağaza inceleme süreci daha dikkatli ilerler. Apple ve Google, kullanıcı verisi, abonelik, hesap silme, izin kullanımı ve yanıltıcı deneyim gibi konularda detaylı kontroller yapabilir.
Yayın öncesi netleşmesi gerekenler:
Bu başlıklar proje sözleşmesi ve teslim planına da yansıtılmalıdır. Aksi halde yazılım tamamlandıktan sonra yayın aşamasında gereksiz zaman kaybı yaşanabilir.
Mobil uygulama projesinde bütçe sadece toplam fiyat değildir. Ödeme planı, revizyon sınırları, ek geliştirme bedeli, bakım ücreti, lisans maliyetleri ve üçüncü parti servis giderleri de bütçenin parçasıdır.
Örneğin proje teklifinde mobil uygulama geliştirme bedeli yer alabilir; fakat SMS gönderimi, sunucu, CDN, harita API’si, ödeme komisyonu, mağaza hesabı ve bakım paketi ayrı kalemler olabilir. Bu kalemlerin baştan konuşulması, proje ilerledikçe “bu fiyata dahil miydi?” tartışmasını azaltır.
| Bütçe Kalemi | Açıklama | Sık Yapılan Hata |
|---|---|---|
| Tasarım | UI/UX ekranları, prototip, revizyon | Sadece birkaç ekran sanmak |
| Backend/API | Veritabanı, iş kuralları, entegrasyon | Mobil uygulamadan ayrı düşünmemek |
| Yönetim paneli | İçerik, kullanıcı, işlem yönetimi | Operasyonu manuel bırakmak |
| Mobil geliştirme | iOS ve Android uygulama | Platform sayısını netleştirmemek |
| Test | Cihaz, senaryo, hata düzeltme | Son haftaya bırakmak |
| Yayın | Store hazırlığı ve inceleme süreci | Mağaza hesabını geç açmak |
| Bakım | Hata desteği, güncelleme, izleme | Yayından sonra bütçe ayırmamak |
Bütçe konuşmasında en sağlıklı yöntem, kapsamı fazlara ayırmaktır. İlk fazda çekirdek ürün çıkarılır, ikinci fazda büyüme özellikleri eklenir, üçüncü fazda optimizasyon ve ölçekleme yapılır.
İyi bir brief, ajansın tahmin yapmasını kolaylaştırır. Sadece “Yemeksepeti gibi uygulama istiyorum” demek yeterli değildir. Çünkü bu ifade arayüz, ödeme, harita, restoran paneli, kurye yönetimi, kampanya sistemi, destek modülü ve komisyon modelini aynı anda ima eder.
Brief mümkün olduğunca sade ama somut olmalıdır. Ajansa ilk görüşmeden önce gönderilebilecek ideal brief şunları içermelidir:
Brief ne kadar net olursa teklif de o kadar gerçekçi olur. Belirsiz brief, genellikle ya gereğinden pahalı tekliflere ya da sonradan büyüyen kapsamlara yol açar.
Mobil uygulama projesinde yalnızca yazılım ajansı değil, müşteri tarafındaki karar mekanizması da önemlidir. Projede kim onay verecek, kim test edecek, kim içerik sağlayacak ve kim geri bildirimleri tek kanaldan iletecek?
Özellikle kurumsal projelerde birden fazla departman devreye girer. Satış ekibi farklı özellik ister, operasyon ekibi farklı akış ister, yönetim ekibi raporlama ister. Eğer karar mekanizması net değilse, tasarım onayları uzar ve yazılım sprintleri bölünür.
Proje başlamadan önce şu roller netleşmelidir:
Atalay Tech gibi yazılım ajansları açısından en verimli süreç, müşterinin tek bir proje sorumlusu belirlemesiyle ilerler. Bu kişi tüm iç geri bildirimleri toplar, önceliklendirir ve ajansa düzenli şekilde aktarır.
Mobil uygulama yayınlandığında proje bitmiş sayılmaz. Kullanıcı geri bildirimleri, işletim sistemi güncellemeleri, mağaza politikaları, güvenlik ihtiyaçları ve yeni özellik talepleri devam eder.
Yayın sonrası bakım planı olmayan uygulamalar kısa sürede teknik borç üretir. Örneğin iOS güncellemesi sonrası bildirim izinlerinde davranış değişebilir, Android tarafında cihaz uyumluluğu problemi çıkabilir veya ödeme altyapısı yeni gereklilikler isteyebilir.
Bakım planında şu başlıklar bulunmalıdır:
Mobil uygulama, yaşayan bir dijital üründür. Bu nedenle proje başında yalnızca ilk teslimi değil, 6-12 aylık gelişim planını da konuşmak gerekir.
İlk soru “kaç paraya yapılır?” değil, “bu uygulama hangi problemi çözecek?” olmalıdır. Çünkü bütçe, süre ve teknoloji seçimi problemin niteliğine göre belirlenir. Örneğin müşteri sadakati artırmak isteyen bir perakende işletmesiyle saha operasyonunu dijitalleştirmek isteyen bir lojistik şirketinin ihtiyaçları aynı değildir. Birinde kampanya, bildirim ve üyelik sistemi öne çıkarken diğerinde görev atama, konum doğrulama ve raporlama öne çıkar. Problem netleşmeden alınan fiyat teklifleri genellikle eksik veya fazla kapsamlı olur.
Fikrinizin MVP’ye uygun olup olmadığını anlamak için ilk sürümde hangi davranışı doğrulamak istediğinizi belirlemelisiniz. Kullanıcı kayıt olacak mı, ödeme yapacak mı, randevu oluşturacak mı, içerik tüketecek mi, satıcıyla iletişime geçecek mi? İlk sürüm bu ana davranışı test ediyorsa MVP mantıklıdır. Ancak regülasyon, yüksek güvenlik, karmaşık entegrasyon veya çoklu departman kullanımı varsa MVP yine yapılabilir fakat daha kontrollü planlanmalıdır. MVP, özensiz ürün değil; gereksiz özellikleri erteleyen stratejik ilk sürümdür.
Evet, bütçe aralığını baştan söylemek çoğu zaman daha doğru teklif almanızı sağlar. Yazılım ajansı bütçeyi bildiğinde kapsamı daha gerçekçi fazlara bölebilir. Örneğin 600.000 TL bütçeli bir MVP ile 2.500.000 TL bütçeli kurumsal ürünün teknik mimarisi, tasarım derinliği ve entegrasyon kapsamı farklı olur. Bütçeyi gizlemek bazen karşılıklı zaman kaybına yol açar. Burada önemli olan net bütçe vermek zorunda olmak değil, en azından hedef aralık ve öncelikleri paylaşmaktır.
Hedef kitleniz hem iOS hem Android kullanıyorsa çoğu ticari projede iki platformu birlikte planlamak daha mantıklıdır. React Native gibi çapraz platform teknolojiler bu noktada süre ve maliyet avantajı sağlayabilir. Ancak bazı projelerde ilk sürüm tek platformdan başlayabilir. Örneğin kurum içi saha uygulamasında şirket cihazları sadece Android ise önce Android yeterli olabilir. Premium tüketici kitlesi hedefleniyorsa iOS önceliklendirilebilir. Karar, hedef kullanıcı cihaz dağılımı, bütçe ve yayın hedefiyle birlikte verilmelidir.
Bu tamamen teklif kapsamına bağlıdır. Birçok mobil uygulama projesinde yönetim paneli zorunludur; fakat bazı tekliflerde ayrı kalem olarak yazılır. Kullanıcı, içerik, sipariş, randevu, ödeme, bildirim veya rapor yönetimi gerekiyorsa panel mutlaka planlanmalıdır. Yönetim paneli olmadan uygulama yayına çıksa bile operasyon manuel ilerler ve ekip yazılımcıya bağımlı hale gelir. Bu nedenle teklif alırken “mobil uygulama dışında backend, API ve admin panel dahil mi?” sorusu açıkça sorulmalıdır.
Sözleşmede kapsam, teslim aşamaları, ödeme planı, revizyon sınırları, ek geliştirme bedeli, fikri mülkiyet, kaynak kod teslimi, gizlilik, bakım süresi, gecikme durumları ve yayın sorumlulukları net yazılmalıdır. Ayrıca üçüncü parti servis ücretlerinin kime ait olduğu belirtilmelidir. Örneğin SMS, sunucu, harita API’si, mağaza hesabı ve ödeme komisyonları yazılım bedeline dahil olmayabilir. Sözleşme teknik detayları tamamen çözmez; fakat tarafların sorumluluklarını netleştirerek proje içi belirsizliği azaltır.
Evet, ticari amaçla kullanılan mobil uygulamalarda bakım planı önerilir. Uygulama mağazası kuralları, iOS ve Android güncellemeleri, güvenlik açıkları, sunucu performansı ve kullanıcı geri bildirimleri zaman içinde değişir. Bakım planı olmayan uygulamalarda küçük hatalar bile büyüyebilir. Özellikle ödeme, üyelik, mesajlaşma, konum, video veya kurumsal veri içeren uygulamalarda izleme, hata müdahalesi ve düzenli güncelleme gerekir. Bakım, yalnızca hata düzeltme değil, ürünün sağlıklı kalmasını sağlayan operasyonel süreçtir.
Ajans seçerken yalnızca fiyat karşılaştırması yapmak yeterli değildir. Ajansın keşif süreci, teknik yaklaşımı, yönetim paneli deneyimi, yayın desteği, bakım modeli, iletişim düzeni ve daha önce hizmet verdiği proje türleri değerlendirilmelidir. Mobil uygulama, backend, web paneli ve entegrasyonları birlikte düşünebilen ekipler genellikle daha sağlıklı sonuç üretir. Ayrıca teklifin ne kadar detaylı yazıldığına bakmak gerekir. Belirsiz, tek satırlık ve kapsamı açıklanmayan teklifler proje ilerledikçe risk oluşturabilir.
Sağlık uygulaması yaptırmak isteyen klinikler, girişimler ve sağlık hizmeti sağlayıcıları için kapsam, KVKK, güvenlik, maliyet, entegrasyon, test ve bakım kriterlerini sade ama teknik derinliği olan bir rehberle ele alıyoruz.
Hastane ve klinikler için randevu uygulaması; hasta randevusu, doktor takvimi, bildirim, ödeme, çağrı merkezi ve yönetim paneli süreçlerini tek sistemde toplar. Bu rehberde MVP kapsamından kurumsal yapıya kadar özellikleri, maliyetleri, entegrasyonları ve geliştirme adımlarını inceliyoruz.
Klinik mobil uygulama geliştirme; randevu, hasta takibi, bildirim, doktor paneli, ödeme, KVKK ve yönetim süreçlerini tek yapıda toplar. Bu rehber, klinikler için mobil uygulama kapsamını, MVP yaklaşımını, maliyetleri, teknik kararları ve geliştirme sürecini pratik örneklerle açıklar.
