Aydınlatma metni yükleniyor…
Mobil uygulama firması seçerken yalnız fiyatı, sunumdaki ekranları veya referans logosunu karşılaştırmak yeterli değildir. Doğru ekip; kullanıcı problemini sorgular, kapsamı ölçülebilir teslimatlara dönüştürür, teknik riskleri erken doğrular ve koddan mağaza hesaplarına kadar proje sahipliğini açık bırakır.
Bu rehber belirli firmaları sıralamaz. Türkiye'de veya uzaktan çalışacağınız mobil uygulama şirketlerini aynı kriterlerle değerlendirmeniz için teknik ve ticari bir kontrol listesi sunar.
Önce Bir Firmaya ve Uygulamaya İhtiyacınızı Netleştirin
Tekrarlanan kullanıcı görevi, cihaz entegrasyonu, çevrimdışı çalışma veya mağaza dağıtımı gerekmiyorsa mobil web daha uygun olabilir. Teklif istemeden önce mobil uygulama uygunluk rehberini kullanın. İç ekip ürün, tasarım, geliştirme, test, mağaza ve bakım sorumluluklarını karşılayamıyorsa dış firma bu kapasiteyi tamamlayabilir; ürün sahipliği yine kurumda kalmalıdır.
Teklif Öncesi Kısa Proje Özeti Hazırlayın
- Hedef kullanıcı ve çözülmek istenen görev
- Mevcut süreç ve veri kaynakları
- İlk sürümün kritik akışı ve başarı ölçütü
- iOS, Android, web ve yönetim paneli beklentisi
- Ödeme, harita, ERP/CRM, bildirim veya donanım entegrasyonları
- Güvenlik, gizlilik, erişilebilirlik ve mevzuat gereksinimleri
- Hedef tarih, karar vericiler ve yaklaşık bütçe aralığı
Aynı özeti bütün adaylara vermek, birbirinden farklı kapsamları yanlışlıkla fiyat karşılaştırmasına sokmanızı önler. Ürün kararları belirsizse 10 kritik ürün kararı ile başlayın.
Mobil Uygulama Firması Seçiminde 12 Kriter
1. Problem ve kapsamı sorgulama biçimi
İyi aday doğrudan ekran ve fiyat vermek yerine kullanıcıyı, kritik akışı, veriyi, entegrasyonu ve başarı ölçütünü sorar. Her talebi onaylamak yerine riskli veya gereksiz kapsamı gerekçesiyle tartışabilmelidir.
2. Benzer problem deneyimi
Sektör logosundan çok çözülen teknik ve operasyonel probleme bakın. Referansın aday tarafından hangi kapsamda yapıldığını, halen canlı olup olmadığını ve ekipte kimlerin çalıştığını sorun. Gizlilik nedeniyle ayrıntı verilemiyorsa süreç ve sorumluluk kanıtı istenebilir.
3. Gerçek proje ekibi
Satış görüşmesindeki kişilerle projeyi yürütecek ürün, UX/UI, mobil, backend, kalite ve proje sorumlularını ayırın. Dış kaynak kullanılacaksa hangi işin kimde olduğu ve iletişim zinciri açık olmalıdır.
4. Ürün ve UI/UX yaklaşımı
Yalnız görsel ekran değil; kullanıcı akışı, prototip, hata/boş/çevrimdışı durumları, erişilebilirlik ve kullanılabilirlik testi bekleyin. mobil UI/UX kontrol listesi teklif kapsamını karşılaştırmak için kullanılabilir.
5. Teknoloji gerekçesi
Native, cross-platform veya hibrit önerisinin cihaz API'leri, performans, ekip ve bakım ihtiyaçlarına nasıl dayandığını sorun. “Her projede kullandığımız teknoloji” tek başına gerekçe değildir. Kritik Bluetooth, ödeme, çevrimdışı senkronizasyon veya arka plan işini prototiple doğrulama planı isteyin.
6. Backend ve entegrasyon yetkinliği
Mobil ekranların ötesinde API, kimlik doğrulama, rol/yetki, yönetim paneli, veri geçişi, loglama ve üçüncü taraf servislerin sorumluluğunu netleştirin. Entegrasyon sahibi kurum veya başka tedarikçiyse bağımlılık ve kabul koşulları plana yazılmalıdır.
7. Güvenli geliştirme yaklaşımı
“Güvenli kod yazarız” yerine tehdit modelleme, kod inceleme, bağımlılık takibi, gizli anahtar yönetimi, test ve hata kapatma sürecini sorun. NIST SSDF güvenli geliştirme uygulamalarını hazırlık, yazılımı koruma, güvenli üretim ve zafiyetlere yanıt başlıklarında toplar. (NIST SSDF) Mobil kontroller için OWASP MASVS; depolama, kimlik doğrulama, ağ, platform, kod, dayanıklılık ve gizlilik alanlarını ayrı değerlendirir. (OWASP MASVS)
8. Test ve kabul kriterleri
Hangi cihaz ve işletim sistemi sürümlerinin, hangi kritik senaryoların ve erişilebilirlik koşullarının test edileceğini sorun. “Test edilmiştir” yerine kabul kriteri, hata önceliği, düzeltme ve yeniden test sorumluluğu bulunmalıdır.
9. Proje yönetimi ve görünürlük
Toplantı sıklığı, görev takibi, demo ritmi, karar kaydı, risk yönetimi ve değişiklik talebi sürecini öğrenin. İlerlemeyi yalnız yüzdeyle değil, çalışan ve kabul edilmiş teslimatlarla izleyin.
10. Kod, hesap ve veri sahipliği
Kaynak kod deposu, alan adı, sunucu, analitik, bildirim, harita, ödeme ve mağaza hesaplarının kimin adına açılacağını sözleşmede belirtin. Apple hesap rollerinde Account Holder hukuki anlaşmalar ve üyelik dahil en geniş yetkilere sahiptir; bu rolün kurum kontrolünde olması devir riskini azaltır. (Apple Developer rolleri)
Apple Developer/App Store Connect, Google Play Console, kaynak kodu deposu, bulut, alan adı, e-posta/SMS, bildirim, harita, analitik, hata izleme, ödeme ve diğer servis hesaplarını tek sahiplik matrisinde gösterin. Ortak parola paylaşmak yerine kişisel kullanıcı ve gerekli en düşük yetkiyi kullanın. Apple ve Google, uygulama aktarımı için belirli koşullar ve hazırlık adımları tanımlar; işletme sahipliğini başlangıçta kurmak devir riskini azaltır. (Apple uygulama aktarımı; Google Play uygulama aktarımı)
11. Teslim ve devir planı
Kaynak kod, tasarım kaynakları, veri tabanı şeması, API dokümantasyonu, kurulum/yayın talimatı, imzalama süreci, üçüncü taraf servis listesi ve erişim envanterini teslimat olarak yazın. Devir yalnız ZIP dosyası almak değildir; yeni ekibin sistemi kurup temel sürümü çıkarabilmesiyle doğrulanmalıdır.
Devir envanteri ayrıca sürüm geçmişini, ortamları, derleme ve dağıtım adımlarını, gizli anahtarların güvenli devrini, açık hataları ve teknik borcu kapsamalıdır.
12. Bakım ve olay müdahalesi
Garanti ile bakımın farkını, yanıt sürelerini, kritik hata tanımını, işletim sistemi güncellemelerini, bağımlılık bakımını ve yeni özellik ücretlendirmesini ayırın. “Sürekli destek” ifadesi süre, kanal ve kapsam olmadan ölçülemez.
Garanti kapsamındaki hata düzeltme, rutin bakım, işletim desteği ve yeni geliştirme ayrı tanımlanmalıdır. Destek saatleri, olay önem düzeyleri, ilk yanıt, iletişim kanalı, izleme, yedek, SDK güncellemeleri, üçüncü taraf değişiklikleri ve mağaza politika uyarlamaları teklifte görünmelidir.
Teklifleri Aynı Tabloda Karşılaştırın
| Başlık | Ağırlık örneği | Aranacak kanıt |
|---|---|---|
| Problem ve kapsam | %15 | Varsayım, kapsam dışı ve kabul kriterleri |
| Ekip ve deneyim | %15 | Atanmış kişiler, benzer problem açıklaması |
| Teknik yaklaşım | %20 | Mimari gerekçe ve risk prototipi |
| UX ve test | %15 | Akış, durumlar, cihaz/test matrisi |
| Güvenlik ve sahiplik | %15 | Kontrol planı, hesap ve kod maddeleri |
| Teslim, bakım ve maliyet | %20 | Teslim envanteri, SLA, değişiklik ve toplam maliyet |
Ağırlıkları projenize göre değiştirin. Puanın yanına mutlaka kanıt ve risk notu yazın; yüksek sunum kalitesini teknik yeterlilik yerine koymayın.
Adayları yalnız toplam puanla değil, sundukları kanıtın düzeyiyle karşılaştırın. Her satır için 0 “kanıt yok”, 1 “sözlü açıklama”, 2 “örnek veya doküman”, 3 “projeye özel doğrulanmış kanıt” kullanılabilir. Kod, hesap, veri ve devir gibi kritik sahiplik koşulları puanlanmamalı; sözleşmede açık kabul şartı olmalıdır.
| Alan | İstenecek kanıt | Kritik soru | Zayıf sinyal |
|---|---|---|---|
| Problem ve kapsam | Varsayım, kullanıcı ve ilk sürüm özeti | Neyi neden yapmayacağız? | Doğrudan ekran ve süre vaadi |
| Ekip | İsim, rol, kıdem ve ayrılacak kapasite | İşi kim yapacak? | Yalnız satış ekibiyle görüşme |
| Teknik sistem | Mimari, backend, veri ve entegrasyon taslağı | Ana kayıtlar ve hata davranışı ne? | Teknoloji adıyla sonuç garantisi |
| Kalite ve güvenlik | Test kapsamı ve örnek kabul kaydı | Hangi cihaz, rol ve risk test edilir? | “Test edilir” şeklinde tek satır |
| Mağaza yayını | Hesap, paket, metadata ve ret akışı | Yayın kararının sahibi kim? | Onay garantisi |
| Sahiplik ve devir | Kod, hesap, erişim ve doküman envanteri | Tedarikçi değişirse ne teslim edilir? | Ajans hesabında kapalı kontrol |
| İşletme | Destek seviyesi, bakım ve çıkış planı | Olay, güncelleme ve yeni iş nasıl ayrılır? | Belirsiz “ömür boyu destek” |
Fiyat Teklifinde Neler Ayrı Görünmeli?
- Keşif, ürün analizi ve UX/UI
- Mobil istemciler, backend, yönetim paneli ve entegrasyonlar
- Test, güvenlik kontrolü ve mağaza teslimi
- Bulut, lisans ve üçüncü taraf servis giderleri
- Garanti, bakım, destek ve yeni geliştirme yöntemi
- Vergi, ödeme takvimi, kapsam dışı işler ve değişiklik fiyatlandırması
En düşük ilk fiyat en düşük toplam sahip olma maliyeti olmayabilir. Eksik kapsam, kurum adına açılmayan hesaplar ve belgesiz sistemler daha sonra devir ve bakım maliyeti yaratabilir.
Görüşmede Sorulacak 16 Soru
- Bu projedeki en riskli üç varsayım nedir?
- İlk sürümden hangi işleri çıkarırdınız ve neden?
- Teknoloji öneriniz hangi gereksinimlere dayanıyor?
- Kritik entegrasyonu nasıl doğrulayacaksınız?
- Projeyi fiilen kimler yürütecek?
- Test ve kabul matrisi nasıl hazırlanacak?
- Kod, hesaplar, anahtarlar ve veriler kimde olacak?
- Bir güvenlik açığı veya kritik çökmede süreç nedir?
- Teslim ve olası sağlayıcı değişimi nasıl yapılacak?
- İki yıllık bakımın tahmini kapsamı nedir?
- Benzer projede firmanın gerçek rolü neydi?
- Mobil uygulama dışında backend ve yönetim panelini kim sağlayacak?
- API ve entegrasyon hata senaryoları tanımlı mı?
- Mağaza yayın hazırlığı ve ret düzeltmesi teklife dâhil mi?
- Bulut ve üçüncü taraf hesaplarını kim kontrol edecek?
- Tedarikçiden çıkış ve devir envanteri sözleşmede mi?
Uyarı İşaretleri
- İhtiyaçları anlamadan kesin fiyat ve süre garantisi
- Kaynak kod veya mağaza hesabının verilmemesi
- Referansın kapsamını ve ekip rolünü açıklayamama
- Test, güvenlik ve bakımın tek satır “dahil” yazılması
- Her projeye aynı teknoloji ve paket
- Kanıtsız satış, indirme veya performans garantisi
- Kapsam değişikliğinin yazılı sürecinin olmaması
Firma mağaza paketini, metadata bilgilerini, test erişimini ve ret yanıtını hazırlayabilir; ancak Apple veya Google onayını garanti edemez. Teklifte hazırlık, ret analizi, düzeltme, yeniden gönderim ve sonradan gelen politika değişikliklerinin kapsamı ayrı gösterilmelidir. (Apple App Review Guidelines)
Sonuç
Mobil uygulama firması seçimi, ajans adı veya saatlik ücret seçimi değil; ürünün riskini, sahipliğini ve uzun vadeli işletimini kimin nasıl yöneteceğine karar vermektir. Aynı proje özetiyle teklif alın, kanıt temelli puanlama yapın ve teslim/devir koşullarını başlamadan yazın.
Projenizin kullanıcı, teknik sistem, teslimat ve bakım kapsamını değerlendirmek için Kumsal Ajans mobil uygulama geliştirme hizmetini inceleyebilir ve ekibimizle görüşebilirsiniz.