Mobil uygulama yaptırmak isteyen firmalar için en kritik soru “Uygulama kaç paraya yapılır?” değil, “Bu uygulama hangi iş sonucunu üretecek?” sorusudur. Çünkü mobil uygulama; müşteri sadakati, operasyonel hız, satış kanalı, saha ekibi yönetimi veya abonelik geliri gibi farklı hedeflere hizmet edebilir.
Bir restoran zinciri için mobil uygulama; kampanya bildirimi, sipariş tekrar oranı ve şube bazlı sadakat sistemi anlamına gelir. Bir B2B dağıtım firması için aynı yatırım; bayi siparişi, stok görünürlüğü, tahsilat takibi ve ERP entegrasyonu demektir. Bir eğitim markası için ise video içerik, sınav takibi, abonelik ve öğrenci ilerleme ekranları öne çıkar.
Atalay Tech olarak mobil uygulama, web platformu ve AI entegrasyonu geliştirdiğimiz projelerde en net farkı şurada görüyoruz: başarılı uygulamalar, özellik listesiyle değil, ölçülebilir iş hedefiyle başlar. Bu nedenle mobil uygulama geliştirme sürecinde ilk karar kod tarafında değil, kapsam ve öncelik tarafında verilir.
Dijital tarafta talep güçlü. DataReportal’ın Türkiye 2026 raporunda GSMA Intelligence verilerine göre Türkiye’de 2025 sonunda 81,9 milyon hücresel mobil bağlantı bulunduğu belirtilir: DataReportal Digital 2026 Turkey. GSMA’nın Avrupa 2026 raporunda mobil teknolojilerin 2025’te Avrupa ekonomisine 1,1 trilyon euro ekonomik değer kattığı aktarılır: GSMA Mobile Economy Europe 2026. Bu rakamlar, mobilin yalnızca tüketici alışkanlığı değil, ticari altyapı meselesi olduğunu gösterir.
Bir firmanın mobil uygulamaya ihtiyacı, “rakiplerde var” gerekçesiyle değil, müşterinin veya ekibin tekrar eden bir işlemi mobilde daha hızlı yapmasıyla ortaya çıkar. Uygulama, web sitesinin küçük ekrana sıkıştırılmış hali olmamalıdır.
Mobil uygulama ihtiyacı genellikle şu durumlarda güçlenir:
Örneğin bir servis firmasında teknisyenler gün içinde 20 farklı adrese gidiyorsa, mobil uygulama iş emri, konum, fotoğraf, müşteri imzası ve parça tüketimi takibini tek akışta toplayabilir. Aynı firmanın sadece tanıtım ihtiyacı varsa, mobil uygulama yerine iyi tasarlanmış bir web sitesi daha mantıklı olabilir.
Proje başlamadan önce netleşmeyen her madde, geliştirme sırasında maliyet ve süre riskine dönüşür. Bu yüzden firma, ajansla görüşmeden önce kendi iş modelini basit ama somut şekilde tarif etmelidir.
Aşağıdaki sorular ilk toplantıdan önce hazırlanırsa teklif daha gerçekçi olur:
| Soru | Neden Önemli? | Örnek Cevap |
|---|---|---|
| Uygulamayı kim kullanacak? | Persona ve ekran akışı belirlenir | Bayiler, son kullanıcılar, saha personeli |
| Ana işlem nedir? | MVP kapsamı netleşir | Sipariş verme, randevu alma, video izleme |
| Gelir modeli var mı? | Ödeme ve abonelik altyapısı planlanır | Tek seferlik satış, aylık abonelik, komisyon |
| Entegrasyon gerekiyor mu? | Backend maliyeti değişir | ERP, CRM, sanal POS, kargo, e-fatura |
| Yönetim paneli olacak mı? | Operasyon ekibi için zorunlu olabilir | İçerik, sipariş, kullanıcı, bildirim yönetimi |
| Yayın sonrası kim yönetecek? | Bakım ve destek modeli belirlenir | Firma ekibi, ajans, hibrit operasyon |
Bu tablo basit görünür ama teklif kalitesini doğrudan etkiler. “Pazar yeri uygulaması istiyoruz” demek yerine “satıcı ürün yükleyecek, alıcı ödeme yapacak, firma komisyondan gelir elde edecek” demek bambaşka bir kapsam oluşturur.
Mobil uygulama yaptırmak isteyen firmalar genellikle tüm fikri tek fazda canlıya almak ister. Bu çoğu zaman bütçeyi şişirir, yayına çıkışı geciktirir ve ilk kullanıcı geri bildirimini aylarca erteletir.
Daha sağlıklı yaklaşım, uygulamayı MVP, orta ölçek ve kurumsal fazlara ayırmaktır. MVP, ürünün “en küçük çalışan ticari versiyonu”dur. Eksik ürün değil, odaklı üründür.
| Seviye | Tipik Kapsam | Süre | 2026 Tahmini Bütçe |
|---|---|---|---|
| MVP | Üyelik, temel akış, yönetim paneli, bildirim, yayın | 6-10 hafta | 250.000 TL - 600.000 TL + KDV |
| Orta ölçek | Ödeme, gelişmiş filtre, rol yapısı, entegrasyon, raporlama | 10-16 hafta | 600.000 TL - 1.500.000 TL + KDV |
| Kurumsal | ERP/CRM, çoklu rol, yüksek trafik, özel güvenlik, SLA | 4-8 ay | 1.500.000 TL - 5.000.000 TL+ + KDV |
| Sürekli ürün | Yeni modüller, A/B test, analitik, AI, büyüme döngüsü | Aylık geliştirme | 75.000 TL - 500.000 TL/ay + KDV |
Bu aralıklar tahminidir; tasarım seviyesi, entegrasyon sayısı, backend karmaşıklığı, veri güvenliği gereksinimleri ve yayın sonrası destek modeliyle değişir. Daha net hesaplama için mobil uygulama fiyatları sayfasındaki fiyat aracı kullanılabilir.
Kapsam belirleme, “kaç ekran olacak?” sorusundan daha geniştir. Bir ekranın arkasında kullanıcı rolü, veri modeli, API, bildirim, güvenlik, loglama ve yönetim paneli olabilir.
Örneğin “sipariş ekranı” denildiğinde şu detaylar gerekir:
Atalay Tech perspektifinde kapsam çalışması, proje başlamadan önce küçük bir teknik harita üretmelidir. Bu haritada kullanıcı rolleri, ekranlar, entegrasyonlar, veri akışları, öncelikler ve yayın kriterleri netleşir. Böylece firma, sadece fiyat değil, neyin teslim edileceğini de bilir.
Daha satın alma niyetine yakın bir değerlendirme yapmak isteyen firmalar için mobil uygulama yaptırmak sayfası hizmet yaklaşımını daha doğrudan anlatır. Bu rehber ise karar öncesi düşünülmesi gerekenleri açıklar.
Teknoloji seçimi, firmanın hedeflediği kalite, süre, bütçe ve bakım modeline göre yapılmalıdır. “En iyi teknoloji” her proje için aynı değildir.
Native geliştirme, iOS ve Android’in ayrı ayrı Swift/Kotlin ile yazılmasıdır. Performans ve platform özellikleri açısından güçlüdür; fakat iki ayrı geliştirme hattı maliyeti artırabilir. React Native veya Flutter, tek kod tabanıyla iOS ve Android uygulaması geliştirmeyi sağlar. No-code araçlar ise daha basit prototiplerde hızlı sonuç verebilir; ancak kompleks iş kuralları ve uzun vadeli ölçeklenme tarafında sınırlı kalabilir.
| Seçenek | Güçlü Taraf | Risk | Kimler İçin Uygun? |
|---|---|---|---|
| Native iOS + Android | En yüksek platform kontrolü | Maliyet ve ekip ihtiyacı yüksek | Bankacılık, yoğun donanım, özel performans |
| React Native | Tek kod tabanı, hızlı geliştirme, yaygın ekosistem | Native modül kalitesi iyi yönetilmeli | Startup, B2B, pazar yeri, içerik, operasyon uygulamaları |
| Flutter | Tek kod tabanı, tutarlı UI | Bazı native entegrasyonlarda ek iş çıkabilir | Tasarım odaklı ve çapraz platform projeler |
| No-code | Hızlı prototip, düşük başlangıç maliyeti | Ölçek ve özel entegrasyon sınırlı | Demo, iç süreç prototipi, düşük riskli test |
| PWA | Web tabanlı, mağaza zorunluluğu yok | Push ve cihaz özellikleri platforma göre değişir | İç portal, basit müşteri paneli, hızlı erişim |
Atalay Tech’in mobil projelerinde sık kullanılan yaklaşım, backend tarafında sağlam API mimarisi ve mobil tarafta çapraz platform geliştirmedir. Bu model, özellikle iOS ve Android’i aynı anda hedefleyen firmalarda süre ve bütçe dengesini güçlendirir.
Bir mobil uygulama şirketi seçerken sadece portfolyoya bakmak yeterli değildir. Firma, uygulamayı teslim aldıktan sonra yönetebilir mi, teknik borç oluşursa kim çözer, mağaza süreçleri nasıl ilerler, güvenlik açıkları nasıl ele alınır gibi sorular da önemlidir.
Değerlendirme yaparken şu başlıklar somut şekilde sorulmalıdır:
| Kriter | Zayıf Sinyal | Güçlü Sinyal |
|---|---|---|
| Kapsam analizi | “Hepsini yaparız” cevabı | Modül, rol, ekran ve faz ayrımı |
| Teknik mimari | Sadece tasarım ekranı gösterir | API, veri modeli, güvenlik ve loglama anlatır |
| Yayın süreci | Mağaza yüklemesi belirsiz | App Store ve Google Play süreci planlı |
| Bakım | Teslim sonrası ilişki yok | Hata desteği, sürüm takibi, izleme var |
| İletişim | Sadece satış odaklı | Haftalık rapor, demo, karar kaydı |
| Güvenlik | Sonradan düşünülür | KVKK, yetki, oturum, şifreleme baştan planlanır |
Buradaki güçlü sinyaller, projenin pahalı olmasından bağımsızdır. Küçük bir MVP’de bile karar kayıtları, kapsam dokümanı ve test listesi olmalıdır.
Sağlıklı bir mobil uygulama projesi, keşif toplantısından mağaza yayınına kadar aşamalı ilerler. Her aşamanın çıktısı net olursa hem firma hem ajans aynı zeminde kalır.
İlk aşamada hedef kullanıcı, iş modeli, operasyon akışı ve başarı metriği belirlenir. Örneğin bir bayi sipariş uygulamasında başarı metriği “uygulama indirildi” değil, “bayilerin yüzde kaçı siparişi telefondan geçti?” olabilir.
Keşif sürecinde kullanıcı personayı somutlaştırmak gerekir. Örneğin “Murat, 42, bölge bayisi; gün içinde sahada, fiyat listesine hızlı bakmak ve stok sorup WhatsApp beklemek istemiyor.” Bu persona, uygulamanın ana ekranını bile etkiler.
Tasarım aşaması sadece görsellik değildir. Kullanıcı akışının sürtünmesini azaltır. Özellikle giriş, üyelik, ödeme, arama, bildirim izni ve sepet gibi ekranlarda bir fazla adım dönüşümü düşürebilir.
Prototipte her ekranın amacı bilinmelidir. Ana ekran, kullanıcıyı en sık yapılan işleme götürmelidir; vitrin gibi kalabalık olmamalıdır.
MVP aşamasında ilk canlı sürüm için zorunlu özellikler geliştirilir. Burada “olsa iyi olur” özellikleri bekletmek gerekir. Örneğin ilk sürümde manuel onaylı bayi başvurusu yeterliyken, tam otomatik risk skoru ikinci faza bırakılabilir.
Test sadece butona basmak değildir. Yetki testleri, hatalı veri girişi, ödeme akışı, bildirim izni, düşük internet senaryosu, eski cihaz performansı ve yönetim paneli kontrolleri yapılmalıdır.
KVKK açısından kişisel verinin nerede tutulduğu, kimlerin eriştiği, logların nasıl saklandığı ve hesap silme talebinin nasıl yönetildiği net olmalıdır.
App Store ve Google Play yayın süreci teknik hazırlık ister. Uygulama açıklamaları, ekran görüntüleri, gizlilik politikası, hesap silme bağlantısı, izin açıklamaları ve test hesapları hazır olmalıdır.
Apple’ın App Store inceleme kuralları ve Google Play politikaları düzenli güncellenir. Bu nedenle yayın öncesinde resmi kaynaklar kontrol edilmelidir: Apple App Review Guidelines ve Google Play Policy Center.
Yayın, projenin sonu değil ilk ölçüm noktasıdır. Crash oranı, aktif kullanıcı, dönüşüm, terk edilen ekranlar, bildirim açılma oranı ve ödeme başarısızlıkları takip edilmelidir.
Teslim sonrası teknik destek için teknik destek paketleri gibi düzenli bakım modeli, uygulamanın güncel kalmasını sağlar. Mobil işletim sistemleri, mağaza kuralları ve cihaz davranışları değiştiği için bakım bütçesi baştan planlanmalıdır.
Soyut ihtiyaç listesi yerine gerçekçi senaryolarla düşünmek daha sağlıklıdır. Aşağıdaki örnekler, farklı firmaların mobil uygulamadan nasıl fayda çıkarabileceğini gösterir.
| Firma Tipi | Ana Kullanıcı | Kritik Özellik | Ölçülebilir Hedef |
|---|---|---|---|
| B2B dağıtım firması | Bayi ve satış temsilcisi | Stok, sipariş, cari bakiye | Telefonla sipariş yükünü %30 azaltmak |
| Klinik veya sağlık merkezi | Hasta ve danışan | Randevu, bildirim, dosya | Randevu kaçırma oranını düşürmek |
| Eğitim platformu | Öğrenci | Video, test, ilerleme | Aylık aktif kullanıcıyı artırmak |
| E-ticaret markası | Sadık müşteri | Push, sepet, ödeme | Tekrar satın alma oranını yükseltmek |
| Saha servis firması | Teknisyen | İş emri, konum, fotoğraf | Form ve WhatsApp trafiğini azaltmak |
| Üyelik tabanlı topluluk | Üye | Profil, içerik, etkinlik | Üye etkileşimini merkezi toplamak |
Bu senaryolarda ortak nokta, uygulamanın yalnızca “dijital prestij” için yapılmamasıdır. Her uygulama, belirli bir iş yükünü azaltmalı veya belirli bir geliri artırmalıdır.
Mobil uygulama teklifi, tek satırlık fiyat belgesi olmamalıdır. İyi bir teklif; kapsam, hariçler, teslim aşamaları, ödeme planı, test kriterleri ve bakım şartlarını açıkça göstermelidir.
Teklifte şu alanların bulunması gerekir:
Burada önemli ayrım şudur: düşük fiyat her zaman avantaj değildir; yüksek fiyat da tek başına kalite göstergesi değildir. Belirleyici olan, teklifin belirsizliği ne kadar azalttığıdır.
Mobil uygulama bütçesi tek seferlik geliştirme maliyetinden ibaret değildir. Tasarım, backend, test, mağaza yayını, sunucu, bakım, yeni sürümler ve pazarlama ayrı kalemlerdir.
Sağlıklı bir ödeme planı genellikle fazlara bağlanır. Örneğin keşif ve tasarım onayı sonrası ilk ödeme, MVP geliştirme ortasında ikinci ödeme, test ve yayın öncesi final ödeme yapılabilir. Böylece her ödeme, somut teslimata karşılık gelir.
| Kalem | MVP Proje | Orta Ölçek Proje | Kurumsal Proje |
|---|---|---|---|
| Tasarım | 40.000-120.000 TL | 100.000-250.000 TL | 250.000 TL+ |
| Mobil geliştirme | 120.000-300.000 TL | 300.000-700.000 TL | 800.000 TL+ |
| Backend ve panel | 80.000-200.000 TL | 250.000-600.000 TL | 700.000 TL+ |
| Entegrasyon | 30.000-150.000 TL | 150.000-400.000 TL | 500.000 TL+ |
| Test ve yayın | 30.000-80.000 TL | 80.000-180.000 TL | 200.000 TL+ |
| Bakım | 25.000-75.000 TL/ay | 75.000-200.000 TL/ay | 200.000 TL+/ay |
Bu tablo, firma içinde bütçe konuşmasını somutlaştırmak için kullanılabilir. Net teklif için proje kapsamının incelenmesi gerekir.
Mobil uygulama projelerinde hata genellikle kod yazılırken değil, proje başlamadan önce yapılır. Belirsiz hedef, şişirilmiş kapsam ve eksik bakım planı ileride maliyet doğurur.
En sık görülen hatalar şunlardır:
Bu hataların ortak sonucu aynıdır: uygulama çıkar, fakat kullanılmaz veya işletme içinde yönetilemez hale gelir.
Atalay Tech’te mobil uygulama projelerine sadece ekran üretimi olarak bakmıyoruz. Mobil uygulama, çoğu zaman web platformu, yönetim paneli, API, bildirim sistemi, ödeme altyapısı ve gerektiğinde AI entegrasyonu ile birlikte düşünülmelidir.
Bir projenin güçlü başlaması için üç çıktı önemlidir:
Mobil uygulama yaptırmak isteyen firmalar için bu yaklaşım, projenin yalnızca “teslim edilen yazılım” değil, yaşayan bir dijital ürün olmasını sağlar.
İlk adım, uygulamanın çözmesi gereken iş problemini tek cümleyle tarif etmektir. “Müşterilerimize uygulama yapmak istiyoruz” yerine “bayilerimizin WhatsApp üzerinden verdiği siparişleri tek panelde toplamak istiyoruz” gibi net bir cümle kurulmalıdır. Ardından hedef kullanıcılar, ana işlem, gelir modeli, entegrasyon ihtiyacı ve yönetim paneli kapsamı çıkarılır. Bu hazırlık yapılmadan alınan teklifler genellikle birbirinden çok farklı olur. Çünkü her ajans, belirsiz alanları kendi varsayımıyla doldurur. Doğru başlangıç; kısa bir keşif, MVP önceliklendirmesi ve teknik kapsam haritasıdır.
2026 koşullarında basit bir MVP mobil uygulama genellikle 250.000 TL - 600.000 TL + KDV aralığında başlayabilir. Orta ölçekli, ödeme ve entegrasyon içeren projelerde bütçe 600.000 TL - 1.500.000 TL + KDV seviyesine çıkabilir. Kurumsal projelerde ERP/CRM entegrasyonu, yüksek güvenlik, çoklu rol, özel raporlama ve yoğun backend ihtiyacı nedeniyle 1.500.000 TL üzeri bütçeler görülebilir. Bu rakamlar tahminidir. En net maliyet; ekran sayısı, kullanıcı rolleri, entegrasyonlar, tasarım kalitesi ve bakım modeli incelendikten sonra belirlenir.
Kullanıcı işlemi sık tekrar ediyorsa, push bildirim önemliyse, cihaz özellikleri gerekiyorsa veya sadakat hedefleniyorsa mobil uygulama daha mantıklı olabilir. Ancak ihtiyaç sadece tanıtım, içerik yayınlama veya basit form toplama ise web uygulaması daha doğru başlangıç olabilir. Örneğin bir restoran markası için sadakat, kampanya ve tekrar sipariş akışı mobilde güçlüdür. Fakat kurumsal hizmet veren bir danışmanlık firması için iyi tasarlanmış web sitesi daha verimli olabilir. Karar, teknoloji tercihinden önce kullanıcı davranışına göre verilmelidir.
İlk sürümde yalnızca ana iş sonucunu üreten özellikler olmalıdır. Üyelik, ana işlem akışı, temel yönetim paneli, bildirim ve gerekli entegrasyonlar genellikle MVP’nin çekirdeğini oluşturur. Örneğin bir randevu uygulamasında ilk sürüm için kullanıcı kaydı, hizmet seçimi, takvim, randevu oluşturma, hatırlatma bildirimi ve panelden yönetim yeterli olabilir. Kupon sistemi, gelişmiş segmentasyon, AI öneri motoru veya sadakat puanı ikinci faza bırakılabilir. İlk sürümün amacı, hızlı ve ölçülebilir geri bildirim almaktır.
Basit MVP projeleri genellikle 6-10 hafta içinde canlıya hazırlanabilir. Orta ölçekli uygulamalarda süre 10-16 hafta aralığına çıkabilir. Kurumsal entegrasyon, özel güvenlik kontrolleri, çoklu kullanıcı rolü ve yoğun test gerektiren projelerde 4-8 aylık takvim daha gerçekçidir. Süreyi en çok etkileyen faktör ekran sayısı değil, ekranların arkasındaki iş kurallarıdır. Ödeme, ERP, kargo, abonelik, video altyapısı veya çoklu onay mekanizması varsa geliştirme ve test süresi uzar. Net takvim için kapsamın fazlara bölünmesi gerekir.
Evet, bakım çoğu projede şarttır. Mobil işletim sistemleri, cihaz modelleri, mağaza politikaları, SDK sürümleri ve güvenlik beklentileri sürekli değişir. Uygulama bugün çalışsa bile altı ay sonra yeni iOS veya Android sürümünde sorun çıkarabilir. Ayrıca kullanıcı geri bildirimleri, crash raporları, performans ölçümleri ve yeni özellik talepleri düzenli takip edilmelidir. Bakım sadece hata düzeltme değildir; uygulamanın güvenli, hızlı ve güncel kalmasını sağlar. Bu yüzden bakım bütçesi proje bittikten sonra değil, teklif aşamasında konuşulmalıdır.
Portfolyo önemlidir ama tek başına yeterli değildir. Firma; ajansın kapsam analizi, teknik mimari yaklaşımı, proje yönetimi, test süreci, mağaza yayını deneyimi ve teslim sonrası destek modelini de incelemelidir. Güzel görünen bir uygulama, zayıf backend veya eksik bakım nedeniyle kısa sürede sorun çıkarabilir. Ajansa “Kaynak kod teslimi nasıl olacak?”, “Yayın sonrası hata desteği var mı?”, “Yönetim paneli kapsamı nedir?”, “Veri güvenliği nasıl sağlanacak?” gibi sorular sorulmalıdır. İyi ajans, sadece fiyat vermez; riskleri ve varsayımları da açıklar.
AI entegrasyonu, sadece trend olduğu için değil, belirli bir iş akışını hızlandırdığı zaman mantıklıdır. Örneğin müşteri destek taleplerini sınıflandırmak, ürün önerisi üretmek, görsel analiz yapmak, metin özetlemek veya kullanıcı davranışına göre içerik sıralamak gerçek değer üretebilir. Ancak ilk sürümde temel iş akışı çalışmıyorsa AI entegrasyonu projeyi gereksiz karmaşıklaştırabilir. Daha sağlıklı yaklaşım, önce MVP’yi canlıya almak, veri biriktirmek ve ardından AI modülünü ölçülebilir bir hedefle eklemektir. Bu hedef, destek süresini azaltmak veya dönüşümü artırmak gibi net olmalıdır.
Mobil uygulama projesi başlatma kontrol listesi; fikir aşamasından MVP kapsamına, bütçe planından teknik altyapıya, test sürecinden App Store ve Google Play yayınına kadar karar vericilerin netleşmesi gereken adımları pratik şekilde açıklar.
Mobil uygulama yaptırmadan önce fikir doğrulama, MVP kapsamı, platform seçimi, maliyet, tasarım, test, mağaza yayını ve bakım sürecini netleştirmek gerekir. Bu rehber, 2026'da mobil uygulama yaptırmak isteyen işletmeler için karar sürecini somut örnekler, tablolar ve teknik kontrol noktalarıyla açıklar.
Mobil Uygulama Geliştirme Rehberi 2026; fikirden yayına kadar keşif, tasarım, MVP, teknoloji seçimi, test, mağaza yayını, bakım ve bütçe planlamasını anlatır. Atalay Tech perspektifiyle mobil uygulama yatırımı yapmadan önce karar vericilerin bilmesi gereken teknik, ticari ve operasyonel başlıkları özetler.
