Mobil uygulama geliştirme hizmeti kontrol listesi, yalnızca “hangi firmayla çalışmalıyım?” sorusuna cevap vermez. Asıl amacı; fikir, bütçe, teknik kapsam, teslim süresi, mağaza yayını ve bakım sürecinde sonradan maliyet çıkarabilecek noktaları en baştan görünür hale getirmektir.
Bir işletme için mobil uygulama; satış kanalı, operasyon paneli, müşteri sadakat aracı, bayi sipariş sistemi, randevu altyapısı veya saha ekibi takip çözümü olabilir. Bu nedenle mobil uygulama geliştirme hizmeti almadan önce yalnızca ekran sayısına değil, uygulamanın iş modeline, veri akışına, entegrasyonlarına ve sürdürülebilirliğine bakmak gerekir.
Sensor Tower’ın 2026 mobil raporunda kullanıcıların iOS ve Google Play uygulamalarında toplam 5,3 trilyon saat geçirdiği belirtiliyor. Statista’nın 2026 projeksiyonuna göre global uygulama pazar gelirinin 739 milyar dolar seviyesine yaklaşması bekleniyor. Bu büyüklük, mobil uygulamanın yalnızca “marka vitrini” değil, doğrudan gelir ve operasyon kanalı olduğunu gösterir. Kaynaklar: Sensor Tower State of Mobile 2026, Statista App Market Outlook.
Bu rehber, Atalay Tech’in mobil uygulama, web platformu, AI entegrasyonu ve yönetim paneli geliştirme projelerinde kullandığı değerlendirme perspektifiyle hazırlanmıştır. Amaç satış baskısı kurmak değil; hizmet almadan önce neyi sormanız, neyi yazılı istemeniz ve hangi riskleri önceden görmeniz gerektiğini netleştirmektir.
Mobil uygulama fikri genellikle “müşteriler uygulamadan sipariş versin”, “randevu alsın”, “bayiler fiyat görsün” veya “ekip sahadan veri girsin” gibi tek cümleyle başlar. Fakat geliştirme hizmeti almak için bu cümle yeterli değildir.
İlk kontrol noktası, uygulamanın hangi iş sonucunu üreteceğidir. Örneğin bir restoran uygulamasında hedef yalnızca menü göstermekse web sayfası yeterli olabilir. Fakat tekrar sipariş, kampanya bildirimi, ödeme alma ve kullanıcı segmentasyonu isteniyorsa mobil uygulama daha anlamlı hale gelir.
Kontrol etmeniz gereken sorular:
Örneğin bir B2B bayi uygulamasında kullanıcı senaryosu şöyle olabilir: “Mehmet, 42 yaşında bir bayi sahibi. Sabah stok durumunu kontrol etmek, müşterisine anlık fiyat vermek, sipariş geçmek ve geçmiş cari hareketlerini görmek istiyor.” Bu senaryo netleşmeden teklif almak, yalnızca ekran sayısına dayalı eksik bir fiyatlandırmaya yol açar.
Mobil uygulama geliştirme hizmeti alırken en kritik belge kapsam dokümanıdır. Kapsam dokümanı; uygulamada hangi modüllerin olacağını, hangi kullanıcı rollerinin bulunacağını, hangi verilerin tutulacağını ve hangi entegrasyonların yapılacağını açıklar.
Sadece “Netflix benzeri uygulama”, “Yemeksepeti tarzı uygulama” veya “Trendyol gibi olsun” demek yeterli değildir. Bu referanslar fikir verir ama yazılım kapsamı çıkarmaz. Örneğin “Trendyol gibi” ifadesi; satıcı paneli, ödeme, kargo, iade, kupon, favori, ürün varyasyonu, canlı destek, öneri algoritması ve bildirim altyapısı gibi onlarca alt sistemi içerir.
Aşağıdaki tablo, hizmet almadan önce kapsam tarafında bakmanız gereken temel alanları özetler.
| Kontrol Alanı | Sorulması Gereken Soru | Eksik Kalırsa Risk |
|---|---|---|
| Kullanıcı rolleri | Müşteri, admin, bayi, satıcı, saha personeli var mı? | Yetki karmaşası ve yeniden geliştirme |
| Ana akış | Kullanıcı uygulamada hangi işlemi tamamlayacak? | Gereksiz ekran üretimi |
| Yönetim paneli | İçerik, sipariş, kullanıcı ve bildirimler nereden yönetilecek? | Operasyon ekibi uygulamayı kullanamaz |
| Entegrasyon | ERP, ödeme, kargo, CRM, harita veya AI servisi bağlanacak mı? | Teklif sonrası ek maliyet |
| Bildirimler | Push, e-posta, SMS veya WhatsApp tetiklenecek mi? | Kullanıcı geri kazanımı zayıflar |
| Raporlama | Hangi metrikler takip edilecek? | Başarı ölçülemez |
| Çoklu dil | Türkçe dışında dil gerekiyor mu? | Sonradan metin mimarisi değişir |
| Güvenlik | KVKK, rol bazlı yetki, log ve veri saklama var mı? | Hukuki ve operasyonel risk |
Atalay Tech tarafında mobil uygulama projelerinde kapsamı yalnızca mobil ekranlardan ibaret ele almamak gerekir. Çoğu projede mobil uygulamanın yanında API, admin paneli, bildirim sistemi, dosya depolama, güvenlik katmanı ve yayın sonrası bakım süreci de bulunur.
Bir uygulamanın ilk sürümünde her özelliği yapmak zorunda değilsiniz. Hatta çoğu projede bu yaklaşım riski artırır. Doğru yöntem, uygulamanın ilk değer üreten sürümünü tanımlamaktır.
MVP, yani minimum uygulanabilir ürün, yalnızca “ucuz sürüm” anlamına gelmez. MVP; pazara çıkmak, kullanıcı davranışını görmek ve sonraki geliştirme kararlarını veriyle almak için hazırlanmış ilk canlı sürümdür.
Örneğin bir randevu uygulamasında MVP şunları içerebilir:
Aynı uygulamanın kurumsal versiyonunda ise doktor paneli, çok şubeli yapı, ödeme, sigorta entegrasyonu, raporlama, KVKK onay metinleri, çoklu dil ve gelişmiş rol yönetimi bulunabilir.
| Seviye | Uygun Senaryo | Tipik Özellikler | Tahmini Süre | Tahmini Maliyet |
|---|---|---|---|---|
| MVP | Fikri hızlı test etmek isteyen girişim veya KOBİ | Üyelik, temel akış, admin paneli, bildirim | 6-10 hafta | 250.000 - 600.000 TL + KDV |
| Orta ölçek | Gelir modeli netleşmiş işletme | Ödeme, entegrasyon, raporlama, gelişmiş panel | 10-16 hafta | 600.000 - 1.500.000 TL + KDV |
| Kurumsal | Çok kullanıcılı, entegrasyonlu, yüksek trafikli yapı | ERP/CRM, çoklu rol, güvenlik, log, ölçeklenebilir mimari | 4-8 ay | 1.500.000 - 5.000.000 TL+ + KDV |
Bu aralıklar proje kapsamına, ekran sayısına, entegrasyon zorluğuna, tasarım detayına ve bakım beklentisine göre değişir. Daha net bir ön değerlendirme için mobil uygulama fiyatları aracını kullanarak kapsamınızı kabaca sınıflandırabilirsiniz.
Mobil uygulama geliştirme hizmeti alırken “native mi, cross-platform mu, no-code mu?” sorusu mutlaka sorulmalıdır. Fakat bu karar yalnızca geliştiricinin konforuna göre verilmemelidir. Uygulamanın performans ihtiyacı, bütçesi, yayın hızı, bakım planı ve cihaz özelliklerine erişim ihtiyacı belirleyici olmalıdır.
Native geliştirme, iOS için Swift ve Android için Kotlin gibi platforma özel dillerle yapılır. React Native veya Flutter gibi cross-platform çözümler ise tek kod tabanıyla iOS ve Android uygulaması çıkarmayı hedefler. No-code araçlar daha hızlı prototip için kullanılabilir ama karmaşık iş süreçlerinde sınırlara çabuk yaklaşabilir.
| Seçenek | Avantaj | Dezavantaj | Kimler İçin Uygun? |
|---|---|---|---|
| Native iOS + Android | En yüksek platform uyumu ve performans | İki ayrı geliştirme maliyeti | Bankacılık, oyun, yoğun cihaz donanımı |
| React Native | Tek kod tabanı, hızlı geliştirme, güçlü ekosistem | Çok özel native modüllerde ek çalışma gerekebilir | B2B, randevu, e-ticaret, sosyal, içerik uygulamaları |
| Flutter | Tutarlı arayüz ve yüksek performans | Bazı native entegrasyonlarda ek uzmanlık gerekir | Görsel yoğun, özel UI isteyen ürünler |
| No-code | Hızlı prototip ve düşük başlangıç maliyeti | Ölçek, performans ve özelleştirme sınırı | Demo, iç kullanım, düşük riskli testler |
| PWA | Mağaza bağımlılığı az, web tabanlı erişim | Push, offline ve cihaz erişimi sınırlı olabilir | Basit katalog, içerik ve form uygulamaları |
Google’ın Android Core App Quality rehberi, uygulama kalitesinin performans, kararlılık, kullanılabilirlik ve platform beklentileriyle birlikte değerlendirilmesi gerektiğini vurgular. Apple tarafında da App Review Guidelines yayına alınacak uygulamanın içerik, gizlilik, ödeme ve kullanıcı deneyimi açısından kurallara uygun olmasını bekler.
Teknoloji kararı verilirken “bugün hızlı çıkalım” ile “2 yıl sonra uygulama büyüdüğünde bakım yapabilecek miyiz?” sorusu birlikte düşünülmelidir.
Mobil uygulama tasarımı yalnızca güzel görünen ekranlardan ibaret değildir. Asıl değer, kullanıcının hedef aksiyona en kısa ve hatasız yoldan ulaşmasını sağlamaktır.
Örneğin bir yemek sipariş uygulamasında iyi tasarım; ana ekranda restoran görsellerinin güzel durması değildir. Kullanıcının geçmiş siparişini tekrar verebilmesi, adres seçimini karıştırmaması, ödeme sırasında hata almaması ve sipariş durumunu net görmesidir.
Kontrol edilmesi gereken UX noktaları:
Persona ile düşünelim: Ayşe, 28 yaşında freelance tasarımcı. İş çıkışı spor salonu uygulamasından ders rezervasyonu yapmak istiyor. Uygulama her seferinde giriş istiyor, ders saatleri küçük fontla listeleniyor ve iptal koşulu ödeme ekranında sonradan çıkıyorsa Ayşe uygulamayı siler. Bu sorun teknik değil, ürün deneyimi sorunudur.
Mobil uygulama hizmeti alırken görünmeyen en büyük iş backend tarafındadır. Kullanıcı mobil ekranda yalnızca butona basar; fakat arka planda API çalışır, veritabanı güncellenir, ödeme sağlayıcısı cevap verir, bildirim kuyruğa alınır ve admin panelinde kayıt oluşur.
Bu nedenle yalnızca “uygulama yapılacak mı?” değil, “uygulama hangi altyapıyla yönetilecek?” sorusu sorulmalıdır.
Özellikle şu başlıklar net olmalıdır:
Atalay Tech’in mobil uygulama projelerinde sık karşılaşılan yapı; mobil uygulama, API, admin paneli ve gerektiğinde web platformunun birlikte planlanmasıdır. Örneğin bir bayi uygulamasında mobil taraf sipariş geçer; admin panel siparişi yönetir; ERP entegrasyonu stok ve fiyat bilgisini günceller; bildirim sistemi bayiye sipariş durumunu iletir.
Bu mimari konuşulmadan alınan teklif, genellikle “sadece mobil ekran” teklifidir. Gerçek operasyon ihtiyacı sonradan ortaya çıktığında süre ve bütçe değişir.
Mobil uygulama kullanıcı verisi topluyorsa güvenlik ve KVKK baştan ele alınmalıdır. Ad, soyad, telefon, e-posta, adres, konum, ödeme geçmişi, sağlık verisi veya mesajlaşma içeriği gibi alanlar farklı risk seviyelerine sahiptir.
Özellikle Türkiye’de hizmet veren uygulamalar için KVKK aydınlatma metni, açık rıza süreçleri, veri saklama politikası, hesap silme akışı ve kullanıcı verilerine erişim yetkileri netleştirilmelidir. Hassas veriler söz konusuysa yalnızca “SSL var” demek yeterli değildir.
Kontrol listesi:
Google Play’in uygulama kalite ve güvenlik politikaları, düşük kaliteli veya politika ihlali yapan uygulamaların yayında sorun yaşayabileceğini gösterir. 2026’da uygulama mağazaları yalnızca çalışan uygulamaya değil, veri güvenliği beyanlarına, izin kullanımına ve kullanıcı deneyimine de daha fazla dikkat eder.
Mobil uygulama geliştirme hizmeti alırken teklifin tek satır “mobil uygulama: X TL” şeklinde olması sağlıklı değildir. Teklif, kapsamın anlaşılmasını kolaylaştırmalı ve tarafların beklentisini aynı zemine çekmelidir.
Aşağıdaki tablo, teklif dokümanında ayrı ayrı görünmesi gereken temel kalemleri gösterir.
| Teklif Kalemi | Açıklama | Neden Ayrı Yazılmalı? |
|---|---|---|
| Keşif ve analiz | İş modeli, kullanıcı rolleri, kapsam çıkarımı | Yanlış ürün geliştirme riskini azaltır |
| UI/UX tasarım | Wireframe, ekran tasarımı, prototip | Görsel beklentiyi netleştirir |
| Mobil geliştirme | iOS, Android veya cross-platform uygulama | Platform kapsamı belirlenir |
| Backend/API | Sunucu tarafı iş kuralları ve veri akışı | Sadece ekran değil sistem geliştirilir |
| Admin paneli | İçerik, kullanıcı, sipariş, rapor yönetimi | Operasyonel kullanım sağlanır |
| Entegrasyonlar | Ödeme, ERP, CRM, kargo, harita, AI | Ek iş yükü görünür olur |
| Test ve yayın | QA, mağaza hazırlığı, App Store/Google Play süreci | Yayın riski azaltılır |
| Bakım ve destek | Hata düzeltme, versiyon güncelleme, izleme | Teslim sonrası sürdürülebilirlik sağlanır |
Eğer mobil uygulama yaptırmak istiyorsanız, teklifin yalnızca fiyat değil, aynı zamanda proje sınırlarını anlatan bir belge olduğunu bilmelisiniz. Sözleşme, kapsam dokümanı ve ödeme planı bu teklifin doğal devamı olmalıdır.
Doğru mobil uygulama şirketi seçimi, yalnızca portföy ekranlarına bakarak yapılmaz. Şirketin ürün mantığı, teknik mimari yaklaşımı, iletişim düzeni ve teslim sonrası destek kapasitesi birlikte incelenmelidir.
Bir ajansa şu soruları sormak gerekir:
Atalay Tech perspektifinde iyi bir yazılım iş ortağı, yalnızca “uygulamayı kodlayan” taraf değildir. İş hedefini anlayan, kapsamı sadeleştiren, teknik borcu görünür kılan ve uygulamanın yayın sonrası yaşamasını planlayan taraftır.
Mobil uygulama App Store veya Google Play’e yüklendiğinde proje bitmez. Asıl dönem, kullanıcılar uygulamayı indirdikten sonra başlar.
Yayın sonrası takip edilmesi gereken metrikler:
Örneğin bir e-ticaret uygulamasında 10.000 indirme tek başına başarı değildir. 10.000 indirmenin yalnızca 300’ü kayıt oluyor, 40’ı sepete ürün atıyor ve 8’i satın alma yapıyorsa sorun pazarlamada değil, onboarding, ürün keşfi veya ödeme akışında olabilir.
Bakım planı şu başlıkları içermelidir:
Bakım bütçesi genellikle proje maliyetinin aylık %5-%15’i aralığında planlanabilir. Bu oran uygulamanın karmaşıklığına, kullanıcı sayısına, entegrasyonlara ve SLA beklentisine göre değişir.
Hizmet almadan önce aşağıdaki listeyi ekip içinde doldurmak, teklif görüşmelerini çok daha verimli hale getirir.
İş ve ürün tarafı
Teknik taraf
Ticari taraf
Bu liste eksiksiz olduğunda daha doğru teklif alırsınız. Eksik olduğunda ise farklı firmalardan gelen teklifleri karşılaştırmak zorlaşır; çünkü biri yalnızca mobil ekranları, diğeri backend ve bakım dahil gerçek sistemi fiyatlamış olabilir.
İlk hazırlanması gereken şey detaylı bir teknik doküman değil, iş hedefi ve kullanıcı senaryosudur. Uygulamanın kime hizmet edeceği, kullanıcının hangi problemi çözeceği ve işletmeye hangi sonucu üreteceği net olmalıdır. Örneğin “müşteriler randevu alsın” ifadesi başlangıçtır; fakat randevu iptali, saat seçimi, bildirim, admin onayı, ödeme ve raporlama gibi alt akışlar ayrıca yazılmalıdır. Bu bilgiler olmadan alınan teklifler eksik veya birbirinden kopuk olur. En sağlıklı başlangıç; hedef kullanıcı, ana özellikler, MVP kapsamı ve entegrasyon ihtiyaçlarını kısa bir dokümanda toplamaktır.
Fiyat farkının temel nedeni çoğu zaman kapsam farkıdır. Bir firma yalnızca mobil ekranları fiyatlarken, başka bir firma backend, admin paneli, API, test, mağaza yayını, güvenlik ve bakım süreçlerini de dahil edebilir. Ayrıca kullanılan teknoloji, tasarım kalitesi, entegrasyon sayısı, ekip deneyimi ve teslim sonrası destek modeli maliyeti doğrudan etkiler. Örneğin basit bir içerik uygulaması ile ERP entegrasyonlu bayi sipariş uygulaması aynı kategoride görünse de teknik karmaşıklıkları tamamen farklıdır. Bu yüzden teklifleri yalnızca toplam fiyatla değil, kapsam kalemleriyle karşılaştırmak gerekir.
MVP, uygulamanın pazara çıkmak ve temel değeri test etmek için geliştirilen ilk sürümüdür. Tam kapsamlı uygulama ise daha fazla rol, entegrasyon, raporlama, ödeme, gelişmiş güvenlik ve operasyon modülleri içerebilir. Örneğin bir klinik randevu uygulamasında MVP; hasta kaydı, uygun saat seçimi ve admin panelden randevu yönetimiyle sınırlı olabilir. Tam kapsamlı versiyonda doktor paneli, ödeme, SMS bildirimleri, çok şubeli yapı ve detaylı raporlama bulunabilir. MVP yaklaşımı bütçeyi daha kontrollü kullanmayı sağlar; fakat MVP’nin de gerçek kullanıcıya değer sunacak kadar sağlam tasarlanması gerekir.
Bu karar uygulamanın ihtiyacına göre verilmelidir. Çok yoğun grafik, donanım erişimi veya platforma özel deneyim gereken projelerde native geliştirme avantajlı olabilir. Buna karşılık B2B uygulamalar, randevu sistemleri, e-ticaret, sosyal özellikli platformlar ve içerik uygulamaları için React Native gibi cross-platform çözümler çoğu zaman daha hızlı ve ekonomik bir geliştirme süreci sağlar. Tek kod tabanıyla iOS ve Android çıkmak bakım maliyetini de azaltabilir. Ancak teknoloji seçimi yapılırken yalnızca ilk geliştirme hızı değil, uzun vadeli bakım, ekip bulunabilirliği ve entegrasyon ihtiyaçları da değerlendirilmelidir.
Çoğu ticari mobil uygulamada admin paneli şarttır. Çünkü uygulamadaki kullanıcıları, siparişleri, randevuları, içerikleri, bildirimleri veya raporları bir yerden yönetmek gerekir. Admin paneli olmadan her değişiklik için yazılımcıya ihtiyaç duyulabilir. Örneğin bir restoran uygulamasında menü fiyatı değiştiğinde bunu panelden güncellemek gerekir. Bir bayi uygulamasında sipariş durumu, stok bilgisi ve duyurular panelden yönetilmelidir. Basit tanıtım veya tek yönlü içerik uygulamalarında panel daha sınırlı olabilir; fakat operasyonel uygulamalarda panel kapsamı teklifin önemli bir parçası olarak ele alınmalıdır.
Evet, App Store ve Google Play yayın süreci teklif kapsamına açıkça dahil edilmelidir. Yayın süreci yalnızca dosya yüklemekten ibaret değildir. Uygulama ikonları, ekran görüntüleri, açıklama metinleri, gizlilik politikası, veri güvenliği formları, yaş derecelendirmesi, test kullanıcıları ve mağaza inceleme süreçleri gerekir. Apple ve Google bazı uygulamaları eksik gizlilik beyanı, hatalı ödeme akışı, düşük kalite, crash veya yetersiz kullanıcı deneyimi nedeniyle reddedebilir. Bu nedenle yayın desteği, geliştirme hizmetinin doğal bir parçası olarak görülmelidir.
Süre; kapsam, entegrasyon, tasarım ve test detayına göre değişir. Basit bir MVP genellikle 6-10 hafta içinde hazırlanabilir. Orta ölçekli bir uygulama 10-16 hafta sürebilir. ERP, ödeme, çoklu rol, gelişmiş raporlama ve güvenlik gerektiren kurumsal uygulamalarda süre 4-8 aya çıkabilir. En sık yapılan hata, yalnızca kodlama süresini dikkate almaktır. Keşif, UX tasarım, backend geliştirme, test, mağaza hazırlığı ve revizyonlar da takvime dahil edilmelidir. Daha sağlıklı planlama için proje kilometre taşlarına bölünmeli ve her aşamanın teslim kriteri yazılmalıdır.
Evet, bakım almamak uzun vadede risklidir. Mobil işletim sistemleri güncellenir, mağaza politikaları değişir, üçüncü parti servisler yeni sürüm çıkarır ve kullanıcılar beklenmeyen hatalarla karşılaşabilir. Ayrıca uygulama yayına çıktıktan sonra gerçek kullanıcı davranışları görülür; bazı ekranların sadeleştirilmesi, performans iyileştirmesi veya yeni özellik eklenmesi gerekebilir. Bakım yalnızca hata düzeltme değil, uygulamanın çalışır, güvenli ve güncel kalmasını sağlayan süreçtir. Bu nedenle sözleşmede bakım kapsamı, yanıt süresi, hata öncelikleri ve aylık destek modeli net yazılmalıdır.
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.
