Mobil Uygulama Teslim Süreci Nasıl Olmalı?

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 Nedir?

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:

• Uygulama kaynak kodlarının teslimi
• Backend, API ve veritabanı erişimlerinin netleştirilmesi
• Admin paneli veya yönetim paneli kullanımının anlatılması
• Test raporlarının paylaşılması
• App Store ve Google Play yayın hazırlığı
• Kabul kriterlerinin kontrol edilmesi
• Hata, bakım ve güncelleme sorumluluklarının belirlenmesi
• Proje kapanış dokümanlarının teslim edilmesi

Ö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.

Teslim Süreci Neden Kritik?

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:

• Uygulama yayına alınır ama mağaza reddi nedeniyle lansman ertelenir.
• Kaynak kodu paylaşılır ama ortam değişkenleri, API anahtarları veya build dokümanı eksik kalır.
• Kullanıcılar hata bildirir ama sorumluluğun kimde olduğu belirsizdir.
• Backend erişimi müşteride değildir; ajans değişimi mümkün olmaz.
• Admin paneli vardır ama operasyon ekibi kullanamaz.
• Bakım kapsamı konuşulmadığı için küçük hata talepleri bile kriz haline gelir.

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.

Sağlıklı Bir Teslim Sürecinin Aşamaları

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.

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.

Teslimden Önce Kabul Kriterleri Netleşmeli

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:

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, Repository ve Build Süreci Nasıl Devredilmeli?

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:

• Git repository erişimi
• iOS ve Android proje dosyaları
• Backend kaynak kodu
• Admin paneli kaynak kodu
• .env.example veya ortam değişkenleri listesi
• Kurulum komutları
• Build alma adımları
• CI/CD varsa pipeline açıklaması
• Kullanılan paketlerin sürüm bilgileri
• Lisanslı servislerin sahiplik bilgileri

React 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.

App Store ve Google Play Teslim Hazırlığı

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:

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.

Test Raporu Teslimin Ayrılmaz Parçasıdır

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:

• Test edilen cihazlar
• İşletim sistemi sürümleri
• Test edilen kullanıcı rolleri
• Kritik senaryolar
• Bulunan hata sayısı
• Düzeltilen hata sayısı
• Açık kalan düşük öncelikli notlar
• Performans gözlemleri
• Güvenlik kontrolleri
• Yayına engel durum olup olmadığı

Ö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.

Güvenlik, KVKK ve Erişim Devirleri Atlanmamalı

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:

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.

Teslimde Dokümantasyon Nasıl Olmalı?

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:

Ö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.

Mobil Uygulama Tesliminde Maliyet ve Süre Beklentisi

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.

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 Sonrası Bakım ve Destek Nasıl Planlanmalı?

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:

İ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ında Hangi Sorular Sorulmalı?

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:

• Uygulamanın son canlı sürümü hangi commit veya build numarasıyla eşleşiyor?
• iOS ve Android mağaza hesapları kime ait?
• Keystore, sertifika ve imzalama bilgileri güvenli şekilde saklandı mı?
• Backend production ortamı kimin hesabında çalışıyor?
• Sunucu, domain, SSL ve CDN erişimleri kimde?
• Admin panelinde hangi roller var?
• Test kullanıcıları ve test verileri temizlendi mi?
• Kritik senaryolar son kez gerçek cihazda denendi mi?
• Hata bildirimleri hangi kanaldan alınacak?
• Bakım sürecinde yanıt süresi ne olacak?
• İlk 30 gün kullanıcı davranışı hangi metriklerle izlenecek?

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.

Kullanıcı Senaryosu: Teslim Eksik Olursa Ne Yaşanır?

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:

• Repository erişimi müşteride değil.
• Android imzalama anahtarı eski geliştiricide.
• API dokümantasyonu yok.
• Admin panelinde yetki rolleri açıklanmamış.
• Test ortamı kapatılmış.
• Sunucu erişimi tek kişinin hesabında.
• Uygulama mağaza hesabı ajans adına açılmış.

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 Perspektifiyle İdeal Teslim Paketi

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:

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.