Mobil Uygulama Sadece Kod Değildir: Görünmeyen 15 İş

Mobil Uygulama Sadece Kod Değildir: Görünmeyen 15 İş

Kısaca: Müşterinin telefonda gördüğü ekranlar, mobil uygulama projesinin yalnızca görünen yüzüdür. Analiz, kullanıcı deneyimi, backend, admin paneli, veri modeli, güvenlik, entegrasyon, test, geliştirici hesapları, mağaza beyanları, yayınlama, izleme ve bakım doğru yönetilmezse iyi yazılmış arayüz bile sürdürülebilir bir ürüne dönüşmez.

Bir uygulama teklifini yalnızca ekran sayısına veya “iOS + Android” ifadesine göre karşılaştırmak, bir binanın maliyetini sadece dış cepheye bakarak hesaplamaya benzer. Kullanıcının görmediği işler projenin güvenliğini, yayınlanabilirliğini ve işletilebilirliğini belirler.

Görünen Uygulama ile Gerçek Ürün Arasındaki Fark

Kullanıcı giriş yapar, ürün arar, ödeme yapar veya randevu alır. Bu basit görünen işlemin arkasında kimlik doğrulama, yetki, veritabanı, iş kuralı, bildirim, hata kaydı, güvenlik ve yönetim araçları çalışır.

Kullanıcının Gördüğü	Arka Plandaki İş
Giriş ekranı	Şifre politikası, doğrulama, oturum, hesap kurtarma, saldırı önleme
Ürün listesi	Veritabanı, arama, stok, fiyat, önbellek ve API
Ödeme butonu	Ödeme kuruluşu, hata/iade akışı, güvenlik ve kayıt
Bildirim	İzin, segment, gönderim altyapısı ve teslim takibi
Profil silme	Veri ilişkileri, saklama politikası ve mağaza kuralı
“Yayında” etiketi	Hesap doğrulama, sertifika, test, mağaza incelemesi

Mobil Uygulamadaki Görünmeyen 15 İş

1. İş Hedefinin ve Başarı Ölçütünün Tanımlanması

Uygulama indirme sayısı tek başına başarı değildir. Sipariş, randevu, tekrar kullanım, saha işlemi süresi veya müşteri hizmetleri yükü gibi iş sonucu belirlenmelidir. Hedef yoksa özellik listesi büyür ama ürünün neden yapıldığı belirsizleşir.

2. Kullanıcı ve Süreç Araştırması

Kimin hangi problemi, hangi ortamda çözeceği anlaşılır. Depoda eldivenle kullanılan uygulama ile evde alışveriş yapılan uygulamanın arayüzü aynı tasarım varsayımına dayanamaz.

3. Kapsam ve MVP Önceliklendirmesi

Zorunlu kullanıcı akışı ile sonraki sürüme bırakılabilecek özellikler ayrılır. MVP “kalitesiz küçük uygulama” değil, değeri en düşük riskle doğrulayan ilk ürün sürümüdür.

4. Kullanıcı Deneyimi ve Prototip

Ekran çizmeden önce bilgi mimarisi, görev akışları ve hata durumları tasarlanır. Tıklanabilir prototip, pahalı kodlama başlamadan yanlış varsayımları ortaya çıkarır.

5. Tasarım Sistemi ve Erişilebilirlik

Renk, yazı, boşluk ve bileşen kuralları farklı ekranlarda tutarlı davranır. Büyük yazı, ekran okuyucu, kontrast ve dokunma alanı kriterleri tasarım sistemine işlenir; sonradan tek tek onarılmaz.

6. Teknik Mimari ve Teknoloji Seçimi

Native, cross-platform, backend teknolojisi, veri saklama, çevrimdışı çalışma ve ölçekleme kararları verilir. En popüler teknoloji değil, ürün riskine ve ekibin sürdürülebilirliğine uygun çözüm seçilir.

7. Backend ve API Geliştirme

Mobil ekranların kullandığı veri, iş kuralı ve yetkiler sunucu tarafında yönetilir. API sürümleme, hata yanıtı, hız sınırı ve güvenli kimlik doğrulama planlanmadığında uygulama büyüdükçe kırılganlaşır.

8. Admin Paneli ve Operasyon Araçları

İşletme kullanıcı, içerik, sipariş, kampanya, rol ve raporları nereden yönetecek? Her küçük değişiklik için geliştiriciye ihtiyaç duyulan uygulama işletme açısından tamamlanmış sayılmaz. Panel rolleri ve denetim kayıtları özellikle önemlidir.

9. Üçüncü Taraf Entegrasyonlar

Ödeme, kargo, harita, SMS, e-posta, CRM, ERP ve analitik servisleri dokümantasyon, kota, güvenlik ve hata yönetimi gerektirir. Karşı sistemin API'si hazır değilse entegrasyon planı değişebilir.

10. Güvenlik ve Kişisel Veri Yönetimi

Yetkilendirme, şifreleme, güvenli saklama, loglama, anahtar yönetimi, açık rıza ve veri silme yalnızca hukuki metin değildir. Uygulamanın teknik davranışıyla uyumlu olmalıdır. Üçüncü taraf SDK'ların topladığı veriler de envantere katılır.

11. Test Mühendisliği

Olumlu senaryonun çalışması yeterli değildir. Yanlış şifre, kesilen internet, başarısız ödeme, yinelenen istek, izin reddi, küçük ekran, eski sürüm ve yüksek trafik gibi durumlar test edilir. Kritik akışlar için regresyon testi hazırlanır.

12. Geliştirici Hesapları ve Dijital Sahiplik

Apple ve Google hesapları, imzalama anahtarları, alan adı, bulut hesabı, analitik ve bildirim servislerinin sahipliği düzenlenir. Hesapların ajans çalışanlarının kişisel e-postalarında kalması ciddi işletme riskidir.

13. Mağaza Kurallarına Uyum

Uygulama açıklaması, ekran görüntüsü, gizlilik beyanı, yaş derecelendirmesi, izin gerekçesi, ödeme yöntemi ve hesap silme akışı mağaza kurallarına uygun olmalıdır. Apple'ın App Review Guidelines dokümanı, inceleme erişiminden iş modeli ve kullanıcı verisine kadar birçok alanı kapsar.

Google Play'de hedef kitle, reklam, uygulama erişimi, hassas izinler ve içerik derecelendirmesi gibi bildirimler yayın öncesi tamamlanır. İncelemeye hazırlık rehberi kod dışındaki bu yükümlülüklerin kapsamını gösterir.

14. Yayınlama ve Ret Yönetimi

Test sürümleri hazırlanır, mağaza materyalleri yüklenir, inceleyici için demo hesabı verilir ve kademeli yayın planlanır. Ret gelirse ürün hatası, eksik bilgi veya kural uyumsuzluğu ayrıştırılır. “Yükleme” bir tuşa basmak değil, kontrollü bir teslim sürecidir.

15. İzleme, Destek ve Sürekli Bakım

Yayından sonra çökme, performans, API hatası ve kullanıcı davranışı izlenir. İşletim sistemi, mağaza ve üçüncü taraf servis değişiklikleri için güncelleme yapılır. Kullanıcı geri bildirimi ürün yol haritasına dönüştürülür.

Neden Bazı Teklifler Çok Daha Ucuz Görünür?

İki teklif aynı ekranları vaat ederken aşağıdaki işler birinde kapsam dışı olabilir:

• Ürün analizi ve prototip
• Özgün tasarım sistemi
• Backend ve admin paneli
• Gerçek cihaz testi
• Bulut kurulumu ve izleme
• Gizlilik/veri beyanı envanteri
• Mağaza hesap kurulumu
• Ret sonrası düzeltme
• Kaynak kod ve hesap devri
• Yayın sonrası garanti ve bakım

Bu fark her zaman kötü niyet değildir; firmalar farklı teslim modeli sunabilir. Sorun, kapsamın müşterinin karşılaştırabileceği açıklıkta yazılmamasıdır.

Müşterinin Proje Başında Hazırlaması Gerekenler

Ajans teknik işleri üstlense de işletme bilgisinin müşteriden gelmesi gerekir:

1. Uygulamanın çözeceği problem ve hedef kullanıcı
2. Mevcut iş süreci ve istisnalar
3. İçerik, ürün, fiyat ve yasal metin sorumluları
4. Entegrasyon yapılacak sistemlerin erişimi
5. Şirket bilgileri ve geliştirici hesabı doğrulamaları
6. Kişisel veri işleme amaçları ve saklama kararları
7. Onay verecek proje sahibi
8. Lansman ve destek ekibi

Geciken karar ve erişimler, geliştirme ekibi çalışsa bile takvimi durdurabilir.

Sağlıklı Bir Teslim Paketinde Neler Bulunur?

Teslimat	Neden Gerekli?
Kaynak kod deposu	Bakım, denetim ve tedarikçi bağımsızlığı
Tasarım dosyaları	Yeni ekran ve pazarlama üretimi
API ve mimari dokümanı	Entegrasyon ve ekip devri
Hesap/rol envanteri	Dijital varlık sahipliği
İmzalama ve sertifika prosedürü	Gelecek sürümleri yayınlayabilme
Test ve bilinen durum raporu	Kalite sınırını görünür kılma
Mağaza materyalleri	Güncelleme ve lokalizasyon
Yedekleme/geri dönüş planı	Operasyon sürekliliği
Bakım ve müdahale koşulları	Yayın sonrası beklenti yönetimi

Şifreleri düz metin belgeyle paylaşmak yerine güvenli parola yöneticisi ve rol tabanlı erişim kullanılmalıdır.

Mağaza Kuralları Neden Tasarımı Baştan Etkiler?

Hesap oluşturan uygulamalarda silme akışı, veri yapısı ve kullanıcı deneyimiyle birlikte planlanır. Apple, hesap oluşturmayı destekleyen uygulamalarda silme işleminin uygulama içinden başlatılabilmesini ister. Google Play, buna ek olarak uygulama dışından erişilebilen web kaynağı talep eder. Yani mağaza uyumu yayın gününde doldurulan bir form değil, ürün gereksinimidir.

Benzer biçimde dijital içerik satışı, hassas izinler veya çocuklara yönelik özellikler ödeme ve tasarım kararlarını en baştan etkileyebilir.

Sıkça Sorulan Sorular

Mobil uygulama geliştirmek sadece yazılımcının işi mi?

Hayır. Ürün yöneticisi, UX/UI tasarımcısı, mobil ve backend geliştirici, test uzmanı, DevOps/güvenlik uzmanı ve gerektiğinde hukuk/pazarlama ekipleri birlikte çalışır. Küçük ekiplerde roller birleşebilir ama işler ortadan kalkmaz.

Admin paneli mobil uygulamaya dâhil midir?

Otomatik olarak değildir. Panelin kullanıcı, rol, içerik, rapor ve iş akışı kapsamı teklifte ayrı yazılmalıdır. Mobil uygulamanın çalışması için gerekli backend ile işletme paneli farklı teslimatlardır.

Mağaza yayını geliştirme fiyatına dâhil midir?

Firmaya göre değişir. Hesap kurulumu, mağaza görselleri, veri beyanları, test kanalları, ilk gönderim ve ret yönetimi maddeler halinde belirtilmelidir. Sadece “mağazaya yükleme” ifadesi yeterli değildir.

Uygulama yayınlanınca proje biter mi?

Hayır. Çökme ve performans izleme, güvenlik güncellemeleri, işletim sistemi uyumu, kullanıcı desteği ve ürün geliştirme devam eder. En azından ilk dönem için bakım ve müdahale modeli belirlenmelidir.

Kaynak kodu almak neden önemli?

Kaynak kod, uygulamanın bakım ve geliştirme temelidir. Kod deposu, bağımlılık bilgileri, derleme yönergesi ve gerekli hesap erişimleri olmadan yalnızca dosya almak gerçek bir devir sayılmaz.

Gizlilik politikasını kopyalamak yeterli mi?

Hayır. Politika, uygulamanın gerçekten topladığı veriler, üçüncü taraf SDK'lar, işleme amaçları, saklama ve silme süreciyle uyumlu olmalıdır. Mağaza beyanı ile uygulama davranışının çelişmesi inceleme ve güven riski oluşturur.

Sonuç

Mobil uygulama yatırımı; ekran, kod, altyapı, hesap, mağaza ve operasyonun birlikte çalışan bir ürün sistemine dönüştürülmesidir. Teklifleri “kaç ekran?” sorusuyla değil, bu 15 işin hangilerinin kim tarafından teslim edileceğiyle karşılaştırın.

Bütçe kalemlerini görmek için 2026 mobil uygulama fiyatları rehberini, yayın sorumluluklarını görmek için App Store ve Google Play rehberini inceleyin. Uçtan uca bir plan için mobil uygulama geliştirme hizmetimizi ziyaret edebilir veya ön görüşme talep edebilirsiniz.