Mobil Uygulama Geliştirme Ajansı ile Çalışırken Nelere Dikkat Edilmeli?

Mobil uygulama geliştirme ajansı seçerken teknik yetkinlik, SLA kapsamı, Native/Cross-platform deneyimi ve mağaza onay süreçlerine (ASO) hakimiyet titizlikle değerlendirilmelidir. Şirketinizin dijital varlıklarını emanet edeceğiniz yazılım ortağını belirlerken maliyet, süre, kod mülkiyeti ve güvenlik parametrelerini içeren bütüncül bir değerlendirme yaklaşımı gereklidir.

Mobil Uygulama Geliştirme Ajansı ile Çalışırken Nelere Dikkat Edilmeli? sorusu, dijital ürün stratejisi oluşturan KOBİ'lerden kurumsal işletmelere kadar tüm karar vericilerin yanıtını netleştirmesi gereken stratejik bir yol ayrımıdır. Yanlış ajans tercihi; öngörülemeyen bütçe aşımları, telafisi zor güvenlik açıkları, Apple App Store ve Google Play mağaza retleri ve en nihayetinde teknik borç (technical debt) batağına saplanmış bir dijital ürün anlamına gelir. Bu rehber; teknik mimariden fikri mülkiyet haklarına, proje yönetim metodolojilerinden mağaza optimizasyonuna (ASO) ve bakım anlaşmalarına (SLA) kadar ajans seçim sürecinin tüm dinamiklerini kapsamlı olarak ele almaktadır.

Doğru Teknoloji Ortağını Seçmenin İşletmeniz İçin Kritik Önemi

Mobil uygulama geliştirme süreci, kod yazımından ibaret bir tedarik operasyonu değil; işletmenizin gelir modelini, operasyonel işleyişini ve marka itibarını doğrudan etkileyen stratejik bir ürün mühendisliği sürecidir. Bir mobil uygulamanın yaşam döngüsü, ilk satır kodun yazılmasından çok önce başlar ve mağazaya yüklendikten sonra yıllarca devam eder. Dolayısıyla seçilecek ajans, yalnızca bir taşeron değil; teknik riskleri öngören, ölçeklenebilir sistem mimarileri tasarlayan ve iş hedeflerinize teknolojik çözümler üreten bir iş ortağı olmak zorundadır.

Piyasada yapılan en büyük stratejik hata, ajans seçimini yalnızca birim adam/saat maliyetine indirgemektir. Düşük başlangıç maliyeti vadeden ancak mimari disiplinden yoksun ajanslarla çalışmak; spagetti kod tabanları, bellek sızıntıları (memory leaks), zayıf API entegrasyonları ve ölçeklenemeyen veritabanı yapıları üretir. Bu durum, uygulamanın ilk 10.000 aktif kullanıcıya ulaştığı anda çökmesine, kullanıcı kaybına (churn rate) ve projenin baştan yazılmasına yol açarak ilk maliyetin 3 ila 5 katı büyüklüğünde bir teknik borç doğurur.

Kurumsal ölçekte bir mobil ürün geliştirirken ajansın sunduğu katma değer; kod kalitesi, güvenilirlik, sürdürülebilirlik ve pazar dinamiklerine uyum kapasitesiyle ölçülür. Türkiye (TR), Birleşik Krallık (UK), Amerika Birleşik Devletleri (US) veya Birleşik Arap Emirlikleri (AE) gibi farklı yasal ve operasyonel gereksinimleri olan pazarlarda faaliyet gösteriyorsanız, teknoloji ortağınızın yerel regülasyonlara (KVKK, GDPR, CCPA, UAE Data Protection Law) ve bölgesel ağ altyapısı koşullarına tam uyum sağlayabilecek mühendislik refleksine sahip olması gerekir.

Teknik Yetkinlik ve Teknoloji Yığını (Tech Stack) Analizi

Bir mobil uygulama ajansının yetkinliğini belirleyen en somut parametre, önerdiği ve uzmanlaştığı teknoloji yığınıdır (tech stack). Ajansların "her teknolojiyi en iyi şekilde kullanıyoruz" söylemi gerçekçi değildir. Uzmanlaşmış ekipler belirli platformlarda derinleşir; veritabanı, ön yüz (front-end), sunucu tarafı (back-end), önbellekleme mekanizmaları ve CI/CD süreçlerini standartlaştırılmış kurumsal şablonlarla yönetir.

Ajansın back-end mimarisine yaklaşımı da incelenmelidir. Mobil uygulamanın kendisi kadar, arkasında çalışan RESTful veya GraphQL API mimarisinin verimliliği, microservices veya monolithic yapı tercihi, AWS/Google Cloud/Azure altyapı yönetimi, veri tabanı şemalandırması (PostgreSQL, MongoDB) ve WebSocket gibi gerçek zamanlı iletişim protokollerinin entegrasyonu da ajansın uzmanlık alanında bulunmalıdır.

Native ve Cross-Platform Çözümler Arasında Doğru Karar

Uygulamanızın temel iş mantığı, donanım gereksinimleri ve bütçeniz, platform mimarisi kararını belirler. Ajansın sizi tek bir çözüme zorlamak yerine projenizin gereksinimlerine göre tarafsız bir analiz sunabilmesi şarttır.

Native uygulama geliştirme (iOS için Swift ve SwiftUI; Android için Kotlin ve Jetpack Compose), cihaz donanımıyla (kamera, Bluetooth Low Energy, biyometrik sensörler, GPU, Neural Engine) sıfır gecikmeli iletişim gerektiren, yoğun animasyon barındıran veya yüksek işlem gücü talep eden (video işleme, artırılmış gerçeklik, fintech güvenliği) projeler için altın standarttır. Apple ve Google yeni işletim sistemi sürümlerini (örneğin iOS 18+ veya Android 15+) yayınladığı gün, Native geliştiriciler yeni API'leri hemen entegre edebilir. Ancak iki ayrı platform için iki ayrı kod tabanı yazılması, geliştirme ve bakım bütçesini yaklaşık %60-80 oranında artırır.

Cross-Platform çözümler (Google Flutter veya Meta React Native), tek bir kod tabanı üzerinden hem iOS hem Android için çıktı üretilmesini sağlar. Flutter, Skia ve Impeller grafik motorları aracılığıyla pikselleri doğrudan ekrana çizerek native'e çok yakın 60/120 FPS performans sunarken; React Native, JavaScript köprüsü (veya yeni Fabric mimarisi) üzerinden işletim sisteminin yerel arayüz bileşenlerini çağırır. E-ticaret, pazar yeri, kurumsal portal, lojistik takip ve sosyal ağ uygulamalarının büyük çoğunluğu için Cross-Platform mimariler, pazara çıkış süresini (Time-to-Market) %40'a varan oranda kısaltır ve geliştirme maliyetlerini düşürür. Ajansın bu iki yaklaşım arasındaki teknik ödünleşimleri (trade-offs) açıkça ortaya koyabilmesi gerekir.

UI/UX Tasarım Standartları ve Kullanıcı Deneyimi Beklentileri

Mobil tasarım yalnızca estetik değil; kullanıcı tutundurma (retention rate), dönüşüm oranları (conversion rate) ve erişilebilirlik (accessibility) mühendisliğidir. Çalışacağınız ajansın tasarım ekibi, Apple Human Interface Guidelines (HIG) ve Google Material Design 3 prensiplerine harfiyen hakim olmalıdır.

Birçok kalitesiz ajans, web sitelerinin arayüzlerini doğrudan mobil ekranlara sıkıştırarak veya iOS ile Android tasarım paradigmalarını birbirine karıştırarak kullanıcıyı yabancılaştıran deneyimler üretir. Örneğin iOS'ta yaygın olan kaydırarak geri gitme (swipe-to-back) hareketi, navigation bar yapıları veya Android'in sistem düzeyindeki geri tuşu etkileşimleri ve Floating Action Button (FAB) kullanımları platforma özgü tasarlanmalıdır.

Ajansın teslim edeceği tasarım sürecinde aşağıdaki standartlar aranmalıdır:

• Tasarım Sistemi (Design System): Tipografi hiyerarşisi, renk paletleri, aralık (spacing) ızgaraları ve tekrar kullanılabilir bileşen kütüphaneleri (Figma Auto-layout ve Variables tabanlı).

• Prototipleme ve Kullanılabilirlik Testleri: Statik ekran görüntüleri yerine tıklanabilir, mikro etkileşimleri (micro-interactions) ve durum geçişlerini (loading, empty state, error state) içeren prototipler.

• Erişilebilirlik (WCAG 2.2 AA): Dinamik yazı boyutu (Dynamic Type), ekran okuyucu uyumluluğu (VoiceOver ve TalkBack) ve yeterli kontrast oranları.

Hukuki Çerçeve ve Sözleşme Şartları (Risk Yönetimi)

Mobil uygulama geliştirme projelerinde yaşanan anlaşmazlıkların %80'i teknik aksaklıklardan değil; muğlak hazırlanmış sözleşmelerden, fikri mülkiyet uyuşmazlıklarından ve teslimat kapsamının (Scope Creep) net çizilmemesinden kaynaklanır. Profesyonel bir ajans ile çalışırken, ticari ilişkinin her adımı bağlayıcı sözleşmelerle çerçevelenmelidir.

Sözleşmelerde "anahtar teslim", "çalışır vaziyette" gibi yoruma açık ifadeler yerine; iş gereksinim dokümanı (BRD), teknik şartname ve kabul kriterleri (User Acceptance Testing - UAT) ek protokoller olarak yer almalıdır. Ayrıca projenin gecikmesi, aşamalı ödeme takvimleri (milestone-based payments) ve tarafların fesih hakları net bir şekilde belirlenmelidir.

Kaynak Kod ve Fikri Mülkiyet (IP) Haklarının Devri

Yazılım projelerindeki en kritik risk unsurlarından biri, kaynak kodların ve fikri mülkiyetin (Intellectual Property - IP) kime ait olacağı konusudur. Açıkça düzenlenmemiş sözleşmelerde yerel fikri mülkiyet yasaları gereği kodun yaratıcısı ajans kabul edilebilir ve şirketiniz yalnızca bir "kullanım lisansı" elde etmiş olabilir.

Sözleşmenizde şu maddelerin koşulsuz yer aldığından emin olunmalıdır:

1. Tam Mülkiyet Devri: Geliştirilen tüm kaynak kodlar, arayüz tasarımları, veritabanı şemaları, API dokümantasyonları ve varlıkların (asset), ödemelerin tamamlanmasıyla birlikte hiçbir ek lisans bedeli olmaksızın şirketinize devredileceği.

2. Git Repository Erişimi: Geliştirme süreci boyunca GitHub, GitLab veya Bitbucket depolarına projenin ilk gününden itibaren "Owner" veya "Admin" seviyesinde erişiminizin bulunması. Kodların proje bittiğinde bir ZIP dosyası olarak teslim edilmesi kabul edilemez bir risktir; sürüm geçmişi (commit history) eksiksiz izlenebilir olmalıdır.

3. Üçüncü Parti Kütüphaneler ve Lisanslar: Ajansın kullandığı açık kaynak kütüphanelerin lisans tipleri (MIT, Apache 2.0, BSD vb.) denetlenmelidir. GPL v3 gibi "virütik" (copyleft) lisanslar, şirketinizin ticari kodlarını da açık kaynak yapma zorunluluğu doğurabileceğinden ticari projelerde kesinlikle engellenmelidir.

Kapsamlı Bir SLA (Hizmet Seviyesi Sözleşmesi) Oluşturmak

Uygulamanın yayına alınması sürecin bitişi değil, asıl operasyonun başlangıcıdır. Hizmet Seviyesi Sözleşmesi (Service Level Agreement - SLA), ajansın lansman sonrasında sunacağı teknik desteğin sınırlarını, hızını ve maliyetini yasal olarak bağlar.

Profesyonel bir SLA dokümanında hata seviyeleri ve yanıt süreleri (Response & Resolution Time) milimetrik olarak tanımlanmalıdır:

• Kritik Hata (P1 / Severity 1): Uygulamanın tamamen çökmesi, ödeme altyapısının durması veya ana kullanıcı akışının kilitlenmesi durumudur. Bu seviye için maksimum müdahale süresi 1-2 saat, geçici çözüm (workaround) veya kalıcı çözüm süresi 4-8 saat olarak taahhüt edilmelidir.

• Yüksek Öncelikli Hata (P2 / Severity 2): Belirli bir modülün (örneğin push bildirimleri veya profil güncelleme) çalışmaması ancak uygulamanın ana fonksiyonlarını sürdürebilmesidir. Müdahale süresi 4-8 saat, çözüm süresi 24-48 saat olmalıdır.

• Düşük Öncelikli Hata (P3 / Minor): Arayüz kaymaları, küçük kozmetik hatalar veya performans optimizasyonlarıdır. Bir sonraki planlı sprint veya bakım güncellemesinde çözülmelidir.

SLA anlaşmasında ayrıca aylık sistem çalışma süresi (Uptime) garantisi (genellikle %99.9), sunucu/API izleme (monitoring) sorumluluğu ve taahhütlerin yerine getirilmemesi durumundaki cezai indirimler (Service Credits) açıkça belirlenmelidir.

Gizlilik Sözleşmesi (NDA) ve Veri Güvenliği Protokolleri

Ajans seçim sürecinde iş modelinizi, patent potansiyeli taşıyan algoritmalarınızı, kullanıcı veritabanı yapılarınızı ve ticari sırlarınızı ajansla paylaşırsınız. Bu nedenle herhangi bir teknik detay veya iş akışı paylaşılmadan önce çift taraflı Gizlilik Sözleşmesi (Non-Disclosure Agreement - NDA) imzalanmalıdır.

Veri güvenliği tarafında ise faaliyet gösterilen coğrafyaya göre regülasyon uyumluluğu sözleşmeye bağlanmalıdır:

• TR Pazarı: 6698 sayılı Kişisel Verilerin Korunması Kanunu (KVKK) uyumu, veri işleyen (data processor) sıfatıyla ajansın sorumlulukları ve açık rıza mimarileri.

• AB ve Birleşik Krallık Pazarı: GDPR ve UK Data Protection Act 2018 gereklilikleri, "Privacy by Design" (tasarımdan itibaren gizlilik) yaklaşımı, kullanıcı verilerinin şifrelenmesi (at-rest ve in-transit AES-256 / TLS 1.3), veri silme/anonimleştirme mekanizmaları.

• BAE ve Körfez Pazarı: UAE Federal Decree-Law No. 45 of 2021 on Personal Data Protection ve Dubai International Financial Centre (DIFC) veri koruma kanunlarına tam uyum.

Proje Yönetimi ve Şeffaf İletişim Süreçleri

Mobil uygulama geliştirme sürecinin başarısı, geliştirici ekibin teknik gücü kadar proje yönetim disiplinine ve iletişim şeffaflığına bağlıdır. "Gereksinimleri aldık, 6 ay sonra uygulamayı teslim edeceğiz" diyen geleneksel Waterfall yaklaşımını benimsemiş ajanslar, günümüz mobil pazarında yüksek başarısızlık riski taşır. Değişen pazar koşulları, kullanıcı geri bildirimleri ve işletim sistemi güncellemeleri, sürecin esnek ve iteratif yönetilmesini zorunlu kılar.

Profesyonel bir ajans; Jira, ClickUp, Asana veya Linear gibi kurumsal proje yönetim araçlarını kullanmalı ve bu panolara müşterisine tam erişim yetkisi vermelidir. Hangi yazılımcının hangi görev (task) üzerinde çalıştığı, harcanan adam/saat süreleri, bloklanan işler ve sprint hedefleri şeffaf bir biçimde izlenebilir olmalıdır.

Çevik (Agile) Geliştirme ve Sprint Raporlamaları

Çevik (Agile / Scrum / Kanban) metodolojiler, projenin 1 ila 2 haftalık periyotlara (sprint) bölünerek parça parça geliştirilmesini, test edilmesini ve doğrulanmasını sağlar. Bu sayede her sprint sonunda çalışan, test edilebilir bir uygulama yapısı (build) incelenebilir.

Ajansla kurulacak operasyonel iletişim döngüsünde şu ritüeller bulunmalıdır:

• Sprint Planlama (Sprint Planning): Her sprint başında geliştirilecek özelliklerin iş değerine göre önceliklendirilmesi ve efor puanlaması (Story Points).

• Haftalık İlerleme Raporları: Tamamlanan işler, sonraki haftanın hedefleri, tespit edilen teknik riskler ve bütçe/zaman kullanım durumunu gösteren net raporlar.

• Sprint İnceleme ve Demo (Sprint Review): Müşteriye TestFlight (iOS) veya Firebase App Distribution / Google Play Dahili Test (Android) üzerinden çalışan bir ara sürüm iletilmesi ve geri bildirimlerin toplanması.

• Geriye Dönük Değerlendirme (Retrospective): Süreç içindeki aksaklıkların analiz edilerek bir sonraki sprintte operasyonel verimliliğin artırılması.

Test Süreçleri (QA) ve Güvenlik Açığı Taramaları

Mobil dünyada hatalı (buggy) bir uygulamanın faturası ağırdır; kullanıcıların %80'i ilk kullanımda çöken veya donan bir uygulamayı silmekte ve asla geri dönmemektedir. Bu nedenle Kalite Güvence (Quality Assurance - QA) ve test süreçleri, geliştirme sürecinin sonuna bırakılan bir detay değil; her sprintin ayrılmaz bir parçası olmalıdır.

Ajansın teknik test yetkinliği şu katmanları içermelidir:

• Birim ve Entegrasyon Testleri (Unit & Integration Testing): İş mantığının ve API servislerinin otomatik testlerle doğrulanması (Jest, XCTest, JUnit, MockK).

• Kullanıcı Arayüzü ve Uçtan Uca Testler (UI & E2E Testing): Kritik kullanıcı senaryolarının (üyelik, sepete ekleme, ödeme, rezervasyon) Appium, Maestro veya Detox gibi araçlarla farklı cihaz çözünürlüklerinde otomatik olarak test edilmesi.

• Cihaz Çeşitliliği Matrisi (Device Fragmentation): Uygulamanın yalnızca en son çıkan iPhone modellerinde değil; farklı ekran boyutları, çentik yapıları, düşük donanımlı Android cihazlar ve eski OS sürümlerinde (fiziksel cihaz çiftlikleri - AWS Device Farm veya BrowserStack kullanılarak) test edilmesi.

• Güvenlik Taramaları (SAST / DAST): OWASP Mobile Top 10 güvenlik risklerine karşı statik ve dinamik kod analizi (SonarQube, MobSF), güvenli depolama (Keychain / EncryptedSharedPreferences kullanımı), API anahtarlarının koda gömülmemesi (obfuscation - ProGuard / DexGuard) ve SSL Pinning protokolleri.

Lansman, Mağaza Onayları ve Lansman Sonrası Destek

Bir mobil uygulamanın geliştirilmesinin tamamlanması, projenin sadece ilk yarısıdır. Uygulamanın Apple App Store ve Google Play Console üzerinde sorunsuz şekilde yayınlanması, arama algoritmalarında görünürlük kazanması ve işletim sistemi güncellemelerine karşı ayakta kalması, ajansın lansman ve bakım yetkinliği ile doğrudan ilişkilidir.

Mağaza yayınlama süreci; geliştirici hesaplarının açılması, sertifikasyon ve imzalama (Code Signing / Provisioning Profiles), gizlilik politikası URL'lerinin yapılandırılması ve mağaza listeleme varlıklarının (ekran görüntüleri, tanıtım videoları, açıklamalar) hazırlanmasını içeren çok adımlı teknik bir operasyondur.

App Store ve Google Play Onay Süreçlerine Hakimiyet

Apple ve Google, mağazalarında yayınlanan uygulamalar için katı ve sürekli güncellenen inceleme yönergelerine (Review Guidelines) sahiptir. Deneyimsiz ajansların geliştirdiği uygulamalar, bu yönergelerin ihlali sebebiyle haftalarca süren ret (rejection) döngülerine takılabilir.

Sık karşılaşılan ret nedenleri ve ajansın alması gereken önlemler şunlardır:

• Apple Guideline 2.1 (Performance - App Completeness): Uygulama içinde kırık linkler, boş ekranlar, "Lorem Ipsum" metinleri veya sahte içerik bulunmamalıdır. Ajans, Apple inceleme ekibi için hazır test hesapları ve detaylı demo notları sağlamalıdır.

• Apple Guideline 4.3 (Design - Spam): Şablon tabanlı, sadece bir web sitesini WebView içinde gösteren uygulamalar Apple tarafından doğrudan reddedilir. Uygulamanın yerel platform özelliklerini kullandığı ve özgün bir değer sunduğu kanıtlanmalıdır.

• Apple Guideline 5.1.1 & Google Data Safety (Privacy): Uygulamanın topladığı verilerin (konum, kamera, rehber vb.) neden toplandığı açıkça belirtilmeli ve gereksiz izinler talep edilmemelidir. Özellikle hesap silme (Account Deletion) mekanizmasının uygulama içinden doğrudan erişilebilir olması yasal bir zorunluluktur.

• Uygulama İçi Satın Alma (In-App Purchase): Dijital içerik, abonelik veya oyun içi varlık satışlarında Apple ve Google'ın kendi IAP altyapılarının kullanılması (%15-%30 komisyon yapısı) zorunludur. Harici ödeme linki (Stripe, iyzico) yerleştirmek, mağazadan doğrudan men edilme nedenidir (bölgesel antitröst istisnaları hariç).

App Store Optimizasyonu (ASO) ve Görünürlük Temelleri

Geliştirilen uygulamanın organik olarak indirilmesi, App Store Optimizasyonu (ASO) stratejisinin doğru kurgulanmasına bağlıdır. ASO, mobil uygulamalar için SEO'nun karşılığıdır ve teknik mimariyle doğrudan bağlantılıdır.

Ajansın sağlaması gereken temel ASO çalışmaları:

• Meta Veri Optimizasyonu: Uygulama başlığı (App Title), alt başlık (Subtitle), anahtar kelime alanı (Keyword Field - iOS 100 karakter) ve detaylı açıklama metinlerinin hedef kitle arama hacimlerine göre kurgulanması.

• Görsel Dönüşüm Optimizasyonu: A/B testlerine uygun, uygulamanın ana değer önerisini ilk 3 saniyede anlatan yüksek kaliteli ekran görüntüleri (Screenshots) ve önizleme videoları (App Previews).

• Uygulama Boyutu Optimizasyonu (App Thinning & Dynamic Delivery): Uygulamanın indirme boyutunun hücresel veri indirme limitlerinin (genellikle 200MB) altında tutulması, kullanıcıların Wi-Fi beklemeden anında indirmesini sağlayarak dönüşüm oranlarını artırır.

Sürekli Bakım, Güncelleme ve Hata Giderme (Bug-Fix) Politikası

Mobil işletim sistemleri yaşayan organizmalardır. Apple her yıl Eylül ayında (iOS ana sürümleri), Google ise her yıl sonbaharda (Android ana sürümleri) köklü güncellemeler yayınlar. Bu güncellemeler; kullanım dışı kalan API'leri (deprecated methods), yeni ekran boyutlarını, değişen gizlilik izinlerini ve yeni arayüz standartlarını beraberinde getirir.

Sürdürülebilir bir mobil uygulama için ajans ile yapılacak bakım anlaşması şunları kapsamalıdır:

• Çökme Oranı Takibi (Crash-Free Users): Crashlytics veya Sentry gibi izleme araçlarıyla uygulamanın çökmesiz kullanıcı oranının %99.5'in üzerinde tutulması.

• İşletim Sistemi Uyumluluğu: Yeni iOS ve Android beta sürümlerinin test edilerek, ana sürüm çıktığı gün uygulamanın sıfır hata ile uyumlu hale getirilmesi.

• Üçüncü Parti SDK Güncellemeleri: Firebase, Facebook SDK, ödeme geçitleri ve analitik araçlarının düzenli olarak güncellenerek güvenlik açıklarının ve uyumsuzlukların önlenmesi.

Ajansın Portfolyosu ve Kurumsal Geçmişi

Ajansların pazarlama sunumları ve web sitelerindeki gösterişli görseller yanıltıcı olabilir. Bir ajansın gerçek kapasitesini anlamanın tek yolu, geçmişte geliştirdiği projeleri canlı ortamda derinlemesine test etmek ve kurumsal referanslarıyla doğrudan görüşmektir.

Bir ajansın sadece tasarım ödüllerine veya müşteri logolarına bakarak karar vermek büyük bir yanılgıdır. Yazılım dünyasında aslolan, o tasarımların arkasında çalışan kodun sağlamlığı, uygulamanın canlıdaki performansı ve ajansın kriz anlarındaki çözüm üretme refleksidir.

Sektörel Deneyim ve Tamamlanmış Proje Referansları

Ajans değerlendirmesi yaparken aşağıdaki denetim metodolojisini uygulamanız önerilir:

1. Canlı Uygulama Denetimi: Ajansın geliştirdiğini iddia ettiği uygulamaları App Store ve Google Play'den kendi cihazınıza indirin. Şu soruların yanıtlarını arayın:

• Uygulama ne sıklıkla güncelleniyor (Sürüm geçmişi son 3-6 ayda aktif mi)?

• Mağaza puanı ve kullanıcı yorumları ne durumda (Özellikle 1 ve 2 yıldızlı yorumlar sürekli aynı teknik hatalardan mı bahsediyor)?

• Uygulama açılış hızı (Cold start time) ve ekran geçişlerindeki akıcılık tatmin edici mi?

1. Mimari ve Kod İncelemesi (Code Audit): Mümkünse bağımsız bir teknik danışmandan destek alarak ajansın örnek bir kod tabanını (veya açık kaynak katkılarını) inceletin. Temiz kod (Clean Code) standartlarına, SOLID prensiplerine ve katmanlı mimariye (MVVM, MVI, Clean Architecture) uyulup uyulmadığını değerlendirin.

2. Müşteri Referans Mülakatları: Ajansın geçmişte çalıştığı en az iki farklı müşterinin ürün yöneticisi veya şirket sahibiyle doğrudan iletişime geçin. Projenin bütçesinde ve teslim süresinde sapma olup olmadığını, ajansın kriz anlarında nasıl tepki verdiğini ve sözleşme sonrası destek kalitesini sorgulayın.

3. Ekip Yapısı ve Süreklilik: Projenizde çalışacak yazılımcı, tasarımcı ve QA mühendislerinin kıdem (Seniority) seviyelerini ve şirketteki çalışma sürelerini öğrenin. Bazı ajanslar satış sürecinde Senior ekipleri gösterip projeyi stajyer veya taşeron geliştiricilere devredebilmektedir.