Bir mobil uygulama projesinde en riskli an çoğu zaman geliştirme değil, teslim aşamasıdır. Çünkü uygulama ekranda çalışıyor gibi görünse bile kaynak kodu, mağaza hesapları, API erişimleri, test senaryoları, bakım sorumluluğu ve yayın sonrası izleme net değilse proje fiilen tamamlanmış sayılmaz.
Özellikle mobil uygulama geliştirme hizmeti alan işletmeler için teslim süreci; teknik, operasyonel ve hukuki bir kapanış kontrolüdür. Bu aşamada amaç “uygulamayı aldık” demek değil, uygulamayı güvenli şekilde yönetebilir, güncelleyebilir ve büyütebilir hale gelmektir.
Atalay Tech’in mobil uygulama, web platformu ve AI entegrasyonu projelerinde gördüğü en kritik ayrım şudur: Başarılı teslim, son gün yapılan dosya paylaşımı değildir. Başarılı teslim; keşif notlarından canlı mağaza sürümüne, admin panelinden bakım planına kadar tüm parçaların ölçülebilir şekilde devredilmesidir.
Mobil uygulama teslim süreci; geliştirilen iOS ve Android uygulamasının müşteri tarafından kullanılabilir, yayınlanabilir, denetlenebilir ve sürdürülebilir hale getirilmesi için yapılan son proje aşamasıdır.
Bu süreç genellikle şu parçaları kapsar:
Örneğin bir saha satış uygulamasında yalnızca mobil uygulama ekranlarının çalışması yeterli değildir. Satış temsilcisi sipariş oluşturduğunda stok düşüyor mu, yönetici panelinde rapor görünüyor mu, internet kesilince veri kayboluyor mu, bildirimler doğru kullanıcıya gidiyor mu ve yeni cihazda kurulum yapılabiliyor mu? Teslim süreci bu sorulara net cevap vermelidir.
Mobil uygulama pazarı büyüdükçe kullanıcıların kalite beklentisi de yükseliyor. Sensor Tower’ın 2026 raporuna göre kullanıcılar 2025’te uygulamalarda 5,3 trilyon saat geçirdi ve oyun dışı uygulamalar ilk kez oyunlardan daha fazla tüketici harcaması üretti. Bu veri, mobil uygulamaların yalnızca “ekran tasarımı” değil, sürekli çalışan dijital ürünler olduğunu gösteriyor. Kaynak: Sensor Tower State of Mobile 2026
Teslim süreci eksik yönetildiğinde şu problemler görülür:
Bu yüzden mobil uygulama yaptırmak isteyen bir işletme, sözleşme ve teklif aşamasında teslim kriterlerini en baştan sormalıdır. Teslim süreci proje sonunda konuşulursa genellikle geç kalınmış olur.
Teslim süreci tek bir toplantıdan ibaret değildir. Projenin başından itibaren planlanır ve canlı yayına kadar parça parça doğrulanır.
| Aşama | Teslimde Kontrol Edilecek Çıktı | Sorumlu Taraf | Risk |
|---|---|---|---|
| Keşif | Kapsam, kullanıcı rolleri, ana akışlar | Müşteri + ajans | Eksik kapsam, sonradan ek iş |
| Tasarım | Figma, ekran akışları, UX notları | Ajans | Onaysız ekranların geliştirilmesi |
| MVP | Çekirdek özelliklerin çalışan sürümü | Ajans | Gereksiz özellik yükü |
| Test | Hata listesi, cihaz testi, API kontrolü | Ajans + müşteri | Canlıda kritik hata |
| Yayın | Store hesapları, build, açıklamalar | Ajans + müşteri | Mağaza reddi |
| Bakım | SLA, hata öncelikleri, güncelleme planı | Ajans | Sorumluluk belirsizliği |
Bu tablo, teslimin “bitti” denilen son gün değil, projenin her aşamasında hazırlanan bir sistem olduğunu gösterir. Özellikle MVP yaklaşımında teslim kriterleri net değilse müşteri “ürün eksik”, ajans ise “kapsam dışı” diyebilir.
Kabul kriteri, projenin hangi şartlarda tamamlanmış sayılacağını belirleyen ölçülebilir kurallar bütünüdür. “Uygulama güzel çalışsın” kabul kriteri değildir. “Kullanıcı e-posta ile kayıt olabilmeli, telefon doğrulaması yapabilmeli, profilini düzenleyebilmeli ve sipariş geçmişini görebilmeli” daha somut bir kriterdir.
Bir teslim dokümanında kabul kriterleri şu şekilde yazılabilir:
| Modül | Kabul Kriteri | Test Yöntemi | Başarılı Sayılma Şartı |
|---|---|---|---|
| Üyelik | E-posta ve şifre ile kayıt | iOS + Android cihaz testi | Kullanıcı hesabı oluşur |
| Bildirim | Sipariş güncellemesinde push gider | Test kullanıcı senaryosu | Bildirim 30 sn içinde gelir |
| Ödeme | Başarılı tahsilat sonrası sipariş açılır | Sandbox ödeme testi | Sipariş durumu “ödendi” olur |
| Admin panel | Kullanıcı listesi filtrelenir | Yönetici hesabı testi | Arama ve filtre çalışır |
| API | Yetkisiz istek engellenir | Token testi | 401/403 yanıtı döner |
Atalay Tech tarafında mobil uygulama teslimlerinde kabul kriterlerini yalnızca ekran bazlı değil, kullanıcı senaryosu bazlı ele almak daha sağlıklı bulunur. Çünkü kullanıcı uygulamayı ekran ekran değil, hedefe ulaşmak için kullanır.
Örneğin “Ayşe, 28 yaşında freelance tasarımcı, uygulamadan randevu oluşturuyor” senaryosu sadece butonların çalışmasını değil; kayıt, takvim, ödeme, bildirim ve e-posta akışını birlikte test etmeyi sağlar.
Kaynak kodu teslimi, ZIP dosyası göndermekten ibaret olmamalıdır. Profesyonel teslimde repository geçmişi, branch yapısı, ortam dosyaları, build komutları ve kurulum dokümanı birlikte teslim edilir.
Teslimde minimum şu başlıklar yer almalıdır:
.env.example veya ortam değişkenleri listesiReact Native veya native mobil uygulama projelerinde build süreci ayrıca önemlidir. Örneğin iOS tarafında sertifika, provisioning profile, App Store Connect erişimi; Android tarafında keystore, package name, Play Console erişimi ve imzalama ayarları mutlaka kontrol edilmelidir.
Yanlış yönetilen bir teslimde uygulama çalışıyor olabilir ama yeni sürüm alınamaz. Bu durum, ileride küçük bir metin değişikliği için bile eski ajansa bağımlı kalma riski doğurur.
Mobil uygulama teslim sürecinde mağaza yayın adımı ayrı bir kontrol listesi ister. Apple, App Store Review Guidelines içinde güvenlik, performans, iş modeli, tasarım ve hukuki uygunluk başlıklarını açıkça ayrı bölümler halinde ele alır. Kaynak: Apple App Review Guidelines
Google tarafında ise uygulama kalitesi, teknik stabilite, gizlilik, güvenlik ve Android Vitals takibi öne çıkar. Google’ın Android kalite rehberinde, yayın öncesi pre-launch report ve yayın sonrası Android Vitals takibinin kullanılması önerilir. Kaynak: Android Core App Quality Guidelines
Mağaza tesliminde aşağıdaki materyaller hazır olmalıdır:
| Teslim Öğesi | iOS | Android | Not |
|---|---|---|---|
| Geliştirici hesabı | Apple Developer | Google Play Console | Müşteri adına olması önerilir |
| Uygulama ikonu | 1024x1024 | 512x512 | Marka kılavuzuna uygun |
| Ekran görüntüleri | Cihaz ölçülerine göre | Telefon/tablet kırılımları | Metinsiz veya lokalize olabilir |
| Gizlilik politikası | Zorunlu | Zorunlu | Web URL gerekir |
| Veri güvenliği formu | App Privacy | Data Safety | Toplanan veriyle tutarlı olmalı |
| Test hesabı | Gerekirse | Gerekirse | İnceleme ekibi için |
| Sürüm notu | Gerekli | Gerekli | Kısa ve anlaşılır |
| Build imzası | Sertifika/profil | Keystore/AAB | Güvenli saklanmalı |
Bu noktada kritik detay şudur: Mağaza hesapları mümkünse müşteriye ait olmalıdır. Ajans hesabından yayınlanan uygulamalarda ileride sahiplik, ödeme, abonelik, marka ve hesap devri konularında ek risk oluşabilir.
Bir mobil uygulama tesliminde test raporu yoksa teslim eksiktir. Çünkü müşteri uygulamanın hangi cihazlarda, hangi senaryolarda ve hangi hata seviyelerinde test edildiğini göremez.
Test raporunda en az şu başlıklar bulunmalıdır:
Örneğin bir e-ticaret mobil uygulamasında yalnızca “sepete ekle” test etmek yeterli değildir. Kupon, stok, kargo, ödeme, iade, kullanıcı adresi, fatura bilgisi ve push bildirimi birlikte denenmelidir. Bir restoran sipariş uygulamasında ise yoğun saat senaryosu, konum izni, kurye ekranı ve sipariş iptali ayrıca kontrol edilmelidir.
Teslim sürecinde güvenlik sadece teknik ekibin konusu değildir. Müşteri tarafında da hangi kullanıcıların hangi panele erişeceği, kimlerin yönetici yetkisine sahip olacağı ve eski test kullanıcılarının temizlenip temizlenmediği kontrol edilmelidir.
OWASP Mobile Application Security Verification Standard, mobil uygulama güvenliği için sektör standardı kabul edilen doğrulama başlıkları sunar. Özellikle kimlik doğrulama, veri saklama, kriptografi, ağ iletişimi ve platform etkileşimleri teslim öncesi kontrol edilmelidir. Kaynak: OWASP MASVS
Teslimde güvenlik açısından şu başlıklar kapatılmalıdır:
| Güvenlik Başlığı | Teslimde Kontrol | Örnek Risk |
|---|---|---|
| Yetkilendirme | Rol bazlı erişim testleri | Kullanıcının başkasının verisini görmesi |
| Veri saklama | Hassas verinin cihazda tutulmaması | Token sızıntısı |
| API güvenliği | Token, rate limit, yetkisiz istek kontrolü | Yetkisiz veri çekme |
| Log yönetimi | Production loglarında hassas veri olmaması | KVKK riski |
| Admin panel | 2FA veya güçlü şifre politikası | Panel ele geçirilmesi |
| Test hesapları | Yayın öncesi temizlenmesi | Sahte veri görünmesi |
KVKK açısından teslim dokümanı; hangi verilerin toplandığını, verilerin hangi amaçla işlendiğini, üçüncü taraf servislerin ne olduğunu ve kullanıcıdan hangi izinlerin istendiğini net göstermelidir. Özellikle konum, kamera, mikrofon, rehber ve sağlık verisi gibi izinler gereksiz istenmemelidir.
Dokümantasyon, projeyi devralacak kişinin ilk gün okuyacağı rehberdir. Sadece geliştirici için değil; operasyon, yönetim, pazarlama ve müşteri destek ekipleri için de yazılmalıdır.
İyi bir teslim dokümanı üç seviyede hazırlanabilir:
| Doküman Türü | Hedef Kişi | İçerik | Format |
|---|---|---|---|
| Teknik kurulum | Geliştirici | Repo, ortam, build, deployment | Markdown/PDF |
| Yönetim paneli rehberi | Operasyon ekibi | Kullanıcı, sipariş, içerik yönetimi | Video + kısa metin |
| Yayın ve bakım rehberi | İş sahibi | Store, sürüm, hata bildirimi, SLA | PDF/Notion/Docs |
Örneğin bir rezervasyon uygulamasında operasyon ekibi “randevu iptali nasıl yapılır?” sorusunun cevabını geliştiriciye sormadan bulabilmelidir. Bir üyelik uygulamasında yönetici, kullanıcıyı askıya alma veya içerik kaldırma işlemini panel rehberinden takip edebilmelidir.
Atalay Tech projelerinde teslim dokümantasyonunun sade, uygulanabilir ve rol bazlı olması önemlidir. 80 sayfalık okunmayan doküman yerine, doğru kişiye doğru işlemi gösteren kısa ve güncel rehber daha değerlidir.
Teslim süreci genellikle toplam proje süresinin küçük ama kritik bir bölümüdür. Fakat test, mağaza onayı, revizyon ve bakım planı dahil edildiğinde birkaç günlük işlem gibi düşünülmemelidir.
Aşağıdaki aralıklar Türkiye pazarı için 2026’da gerçekçi tahmini aralıklardır. Kapsama, entegrasyon sayısına, kullanıcı rolüne, ödeme altyapısına, AI entegrasyonuna ve backend karmaşıklığına göre değişebilir.
| Proje Tipi | Geliştirme Maliyeti | Teslim Hazırlığı | Tipik Teslim Süresi | Uygun Senaryo |
|---|---|---|---|---|
| MVP mobil uygulama | 200.000 - 450.000 TL + KDV | Temel test, store yayın, kısa doküman | 3-7 iş günü | Startup doğrulama, pilot ürün |
| Orta ölçek uygulama | 450.000 - 1.200.000 TL + KDV | Çoklu cihaz testi, admin rehberi, API kontrol | 7-15 iş günü | E-ticaret, randevu, saha operasyonu |
| Kurumsal uygulama | 1.200.000 - 3.500.000 TL + KDV | Güvenlik, rol bazlı test, CI/CD, SLA | 15-30 iş günü | ERP entegrasyonu, finans, büyük operasyon |
| AI destekli uygulama | 750.000 - 4.000.000 TL + KDV | Model/API testi, veri güvenliği, hata senaryoları | 10-30 iş günü | Görsel analiz, chatbot, otomasyon |
Burada dikkat edilmesi gereken nokta, teslim hazırlığının ayrı bir “ekstra masraf” gibi değil, projenin kalite sigortası gibi görülmesidir. Uygulama canlıya çıktıktan sonra üretim ortamında hata düzeltmek, teslim öncesi testten daha maliyetlidir.
Detaylı bütçe çalışması için mobil uygulama fiyatları aracını kullanarak kapsamınıza göre daha net bir ilk tahmin çıkarabilirsiniz.
Teslim tamamlandığında proje bitmiş gibi görünür; fakat mobil uygulamalar yaşayan ürünlerdir. iOS ve Android sürüm güncellemeleri, paket bağımlılıkları, güvenlik yamaları, mağaza politika değişiklikleri, kullanıcı geri bildirimleri ve yeni cihaz ölçüleri uygulamayı sürekli etkiler.
Bu nedenle teknik destek ve bakım kapsamı teslimden önce netleşmelidir.
Bakım planında şu ayrım yapılmalıdır:
| Talep Türü | Bakım Kapsamında mı? | Örnek | Öncelik |
|---|---|---|---|
| Kritik hata | Evet | Kullanıcı giriş yapamıyor | Acil |
| Güvenlik açığı | Evet | Yetkisiz erişim riski | Acil |
| Mağaza uyumluluğu | Genelde evet | Yeni SDK zorunluluğu | Yüksek |
| Küçük metin değişikliği | Sözleşmeye bağlı | Buton metni güncelleme | Düşük |
| Yeni özellik | Hayır, ek kapsam | Sadakat modülü ekleme | Projelendirilir |
| Entegrasyon değişikliği | Kapsama bağlı | Ödeme sağlayıcı API değişimi | Orta/Yüksek |
İyi bakım modeli, müşteri ile ajans arasındaki beklenti gerilimini azaltır. “Bu hata mı, yeni özellik mi?” sorusu teslimden sonra değil, bakım sözleşmesinde cevaplanmalıdır.
Teslim toplantısı sadece demo izlemek için yapılmamalıdır. Bu toplantı, teknik ve operasyonel sahipliği netleştiren son kontrol oturumudur.
Sorulması gereken kritik sorular şunlardır:
Bu sorular, teknik detay gibi görünse de iş sürekliliğini doğrudan etkiler. Örneğin keystore kaybolursa Android tarafında yeni sürüm yayınlamak ciddi problem haline gelebilir. Production veritabanına kimlerin eriştiği bilinmiyorsa güvenlik ve KVKK riski oluşur.
Diyelim ki bir işletme saha ekibi için mobil uygulama yaptırdı. Ekipler uygulama üzerinden müşteri ziyareti oluşturuyor, fotoğraf yüklüyor ve merkez ofise rapor gönderiyor.
Teslim günü uygulama telefonda açılıyor. Demo başarılı görünüyor. Fakat üç hafta sonra şirket yeni bir özellik istiyor: saha personeli ziyaret notuna ses kaydı eklemek istiyor. Bu noktada şu problemler ortaya çıkıyor:
Bu tablo, “teslim aldık” sanılan projenin aslında devralınmadığını gösterir. Sağlıklı teslimde uygulama yalnızca kullanılabilir değil, geliştirilebilir ve taşınabilir olmalıdır.
Atalay Tech’in mobil uygulama, web platformu ve AI entegrasyonu projelerinde ideal teslim paketi şu mantıkla ele alınır: Müşteri ürünü kullanmalı, operasyon ekibi yönetebilmeli, teknik ekip sürdürebilmeli ve iş sahibi riskleri görebilmelidir.
İdeal teslim paketi şunları içermelidir:
| Teslim Kalemi | Minimum Seviye | İdeal Seviye |
|---|---|---|
| Kaynak kodu | Repo erişimi | Branch, commit, build dokümanı |
| Mobil build | iOS/Android canlı sürüm | TestFlight/Internal testing geçmişi |
| Backend | API ve veritabanı çalışır | Kurulum, deployment, log rehberi |
| Admin panel | Giriş bilgileri | Rol bazlı kullanım rehberi |
| Test | Manuel kontrol | Senaryo bazlı test raporu |
| Güvenlik | Temel erişim kontrolü | OWASP/MASVS odaklı kontrol listesi |
| Mağaza | Yayınlanmış uygulama | Store metadata, privacy/data safety notları |
| Bakım | Sözlü destek | SLA, hata önceliği, bakım kapsamı |
Bu yapı özellikle orta ve kurumsal ölçekli projelerde ajans bağımlılığını azaltır. Müşteri, projeyi Atalay Tech ile büyütmeye devam edebilir; fakat teknik olarak kapalı kutuya mahkûm olmaz.
Mobil uygulama teslim süreci projenin karmaşıklığına göre genellikle 3 ila 30 iş günü arasında değişir. Basit bir MVP uygulamada temel test, mağaza hazırlığı, kısa dokümantasyon ve kaynak kodu devri 3-7 iş gününde tamamlanabilir. Orta ölçekli bir uygulamada ödeme, bildirim, admin paneli, API ve cihaz testleri nedeniyle bu süre 7-15 iş gününe çıkabilir. Kurumsal uygulamalarda güvenlik kontrolü, rol bazlı yetki testi, veri taşıma, entegrasyon doğrulama ve bakım planı da eklendiği için teslim 15-30 iş gününü bulabilir.
Hayır. App Store veya Google Play’e yükleme, teslim sürecinin yalnızca bir parçasıdır. Gerçek teslim için kaynak kodu, backend erişimleri, admin paneli, test raporu, mağaza hesap sahipliği, gizlilik politikası, veri güvenliği bilgileri ve bakım sorumlulukları da netleşmelidir. Uygulama mağazada yayında olabilir; fakat imzalama anahtarı, repository erişimi veya sunucu bilgileri müşteride değilse proje teknik olarak devralınmış sayılmaz. Bu yüzden teslimi sadece “uygulama yayında mı?” sorusuyla değil, “ürün sürdürülebilir mi?” sorusuyla değerlendirmek gerekir.
Bu, sözleşmedeki fikri mülkiyet ve lisans modeline bağlıdır; ancak özel yazılım projesi olarak geliştirilen mobil uygulamalarda kaynak kodu devri genellikle beklenen ve sağlıklı olan yaklaşımdır. Müşteri kodu devralmazsa ileride ajans değişimi, yeni özellik geliştirme, güvenlik denetimi veya yatırım süreci zorlaşabilir. Kaynak kodu teslim edilirken sadece dosyalar değil; kurulum adımları, ortam değişkenleri, build komutları, paket sürümleri ve imzalama süreçleri de paylaşılmalıdır. Aksi halde kod vardır ama çalıştırılamaz.
Teslimden önce fonksiyonel test, cihaz testi, API testi, yetkilendirme testi, performans kontrolü ve mağaza uygunluk kontrolü yapılmalıdır. Örneğin üyelik uygulamasında kayıt, giriş, şifre sıfırlama, profil düzenleme, bildirim ve hesap silme akışları test edilmelidir. E-ticaret uygulamasında sepet, ödeme, stok, kargo ve iade senaryoları ayrıca denenmelidir. Testler yalnızca simülatörde değil, gerçek iOS ve Android cihazlarda yapılmalıdır. Kritik hatalar kapatılmadan teslim onayı verilmemelidir.
Bu sorunun cevabı bakım ve garanti kapsamına göre değişir. Teslim öncesi kapsamda yer alan bir özelliğin hatalı çalışması genellikle hata desteği kapsamında değerlendirilir. Ancak müşteri teslimden sonra yeni özellik isterse, bu ayrı iş kapsamı olabilir. Örneğin “bildirim gitmiyor” hata sayılabilir; fakat “bildirime kampanya segmentasyonu ekleyelim” yeni geliştirmedir. Bu ayrım sözleşmede net yazılmalıdır. Hata öncelikleri, yanıt süreleri ve bakım kapsamı teslimden önce belirlenirse sonradan gerilim azalır.
Evet, mağaza reddi teslim sürecini doğrudan etkiler. Uygulama teknik olarak hazır olsa bile Apple veya Google politikalarına uymuyorsa canlı yayına geçemez. Ret nedeni bazen eksik gizlilik politikası, hatalı izin açıklaması, bozuk test hesabı, crash, düşük kalite veya veri güvenliği formundaki tutarsızlık olabilir. Bu nedenle teslim planında mağaza inceleme süresi ve olası revizyon payı bırakılmalıdır. Yayın garantisi verirken mağazaların bağımsız inceleme süreçleri olduğu unutulmamalıdır.
Evet, admin paneli olan projelerde eğitim teslimin önemli parçasıdır. Çünkü uygulama yayına çıktıktan sonra içerik, kullanıcı, sipariş, randevu, bildirim veya rapor yönetimi genellikle müşteri ekibi tarafından yapılır. Eğitim verilmezse her küçük işlem için teknik ekibe ihtiyaç duyulur. İdeal yaklaşım kısa bir canlı eğitim, ekran kaydı ve rol bazlı kullanım dokümanı hazırlamaktır. Örneğin operasyon ekibi sipariş durumunu değiştirmeyi, pazarlama ekibi bildirim göndermeyi, yönetici ise raporları görüntülemeyi öğrenmelidir.
Kesinlikle yazılmalıdır. Teslim sürecinin sözleşmede yer alması hem müşteri hem ajans için güvenlik sağlar. Sözleşmede teslim edilecek materyaller, kabul kriterleri, revizyon hakkı, hata destek süresi, kaynak kodu devri, fikri mülkiyet, mağaza hesap sahipliği ve bakım kapsamı netleşmelidir. Böylece proje sonunda “ben bunu da bekliyordum” veya “bu kapsam dışıydı” tartışması azalır. Mobil uygulama projelerinde teslim maddesi, ödeme planı kadar kritik bir bölümdü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.