Mobil uygulama teklifleri, yalnızca toplam bedel veya teslim süresi yan yana getirilerek sağlıklı biçimde karşılaştırılamaz. Firmalar aynı özellik adlarını farklı kapsam, kalite ve sorumluluklarla yorumlayabilir; tasarım, backend, entegrasyon, test ya da yayın desteği bazı tekliflerde ayrıca fiyatlandırılabilir. Doğru değerlendirme için bütün adaylara ortak ihtiyaç belgesi verilmeli; teslimatlar, kabul kriterleri, teknik yaklaşım, ekip, güvenlik, sahiplik ve bakım koşulları birlikte incelenmelidir. Bu yöntem, görünürde düşük bir teklifin sonradan oluşturabileceği maliyetleri ve yüksek bir teklifin gerçekten hangi ek değeri sunduğunu ortaya çıkarır.
Mobil Uygulama Teklifleri Hangi Kapsamda Karşılaştırılır?
Mobil uygulama teklifleri; aynı ihtiyaçlar, teslimatlar, kabul kriterleri ve sorumluluklar üzerinden karşılaştırılmalıdır. Tekliflerden biri yalnızca mobil arayüzü, diğeri backend, yönetim paneli, test ve yayın desteğini içeriyorsa toplam bedeller anlamlı bir karşılaştırma sunmaz. İlk adım, tüm firmaların cevaplayacağı ortak bir değerlendirme çerçevesi oluşturmaktır.
Teklif karşılaştırma matrisi hangi alanları içermelidir?
Karşılaştırma matrisi her ana kalem için kapsamı, teslim edilecek çıktıyı, sorumlu tarafı, bağımlılıkları ve kapsam dışı işleri göstermelidir. “Ödeme entegrasyonu dahildir” ifadesi tek başına yeterli değildir; sağlayıcı seçimi, test ortamı, hata yönetimi ve lisans giderleri açıklanmalıdır. Belirsiz satırlar, sözleşme öncesinde yazılı sorularla netleştirilmelidir.
- İş hedefleri, kullanıcı rolleri ve temel ürün özellikleri
- Platform, tasarım, backend ve yönetim paneli kapsamı
- Entegrasyon, güvenlik, test ve yayın sorumlulukları
- Teslimatlar, kabul kriterleri ve müşteri yükümlülükleri
- Garanti, bakım, destek ve devam eden giderler
Gecikmiş bir yazılım projesine insan gücü eklemek, projeyi daha da geciktirir. - Fred Brooks
İhtiyaç Analizi Ortak Teklif Kapsamını Nasıl Oluşturur?
İhtiyaç analizi, firmaların aynı problemi ve ürün beklentisini fiyatlandırmasını sağlayarak karşılaştırılabilir bir teklif kapsamı oluşturur. İş hedefi, hedef kullanıcı, kullanıcı rolleri, özellikler, veri kaynakları ve entegrasyonlar belgelenmeden hazırlanan teklifler varsayımlara dayanır. Farklı varsayımlar ise fiyat farkının hizmet kalitesinden mi yoksa kapsam farkından mı kaynaklandığını belirsizleştirir.
Firmalara gönderilecek kapsam belgesinde neler bulunmalıdır?
Kapsam belgesi yalnızca özellik listesinden oluşmamalıdır. Her işlevin temel kuralları, kullanıcı durumları, veri akışları, hata senaryoları ve diğer sistemlerle ilişkisi açıklanmalıdır. MVP planlanıyorsa ilk sürüm ile sonraki fazlar ayrılmalı; çok dillilik, çevrimdışı çalışma, performans ve ölçeklenebilirlik gibi gereksinimler ayrıca belirtilmelidir.
- Ürünün çözeceği problem ve beklenen iş sonuçları
- Kullanıcı türleri, yetkiler ve kritik işlem akışları
- İlk sürüm özellikleri ile sonraki ürün fazları
- Mevcut sistemler, veri kaynakları ve entegrasyon ihtiyaçları
- Teknik, operasyonel ve kurumsal kabul kriterleri
Fiyat, Teslimat ve Kapsam Dışı İşler Nasıl Kıyaslanır?
Mobil uygulama fiyat teklifi değerlendirilirken toplam bedel, teslim edilen işin sınırları ve sonradan oluşabilecek giderlerle birlikte ele alınmalıdır. Düşük teklif analiz, özel tasarım, yönetim paneli, güvenlik testi veya mağaza yayınını dışarıda bırakabilir. Yüksek teklif ise ancak ek kapsam, uzman ekip, kalite kontrolleri veya destek sorumluluğu açıkça gösteriliyorsa anlamlıdır.
Teklifte hangi belirsizlikler ek maliyet oluşturabilir?
Revizyon sayısı, içerik veya veri girişi, üçüncü taraf servisleri, sunucu kurulumu, mağaza hesapları ve kaynak kodu devri açık değilse proje sırasında ek maliyetler doğabilir. Teklifte varsayımlar ve hariç işler ayrı başlıklarla gösterilmelidir. Ödeme planı da yalnızca takvim tarihlerine değil, ölçülebilir teslimat ve kabul noktalarına bağlanmalıdır.
- Tek seferlik geliştirme bedeli ve ödeme kilometre taşları
- Varsayımlar, kapsam dışı işler ve müşteri sorumlulukları
- Revizyon hakları ve değişiklik talebi fiyatlandırma yöntemi
- Lisans, sunucu ve üçüncü taraf kullanım giderleri
- Vergi, para birimi ve teklif geçerlilik koşulları
Teknik Yaklaşım ve Uygulama Mimarisi Nasıl Değerlendirilir?
Teknik yaklaşım, yalnızca programlama dili veya framework adıyla değil; ürünün performans, güvenlik, ölçeklenebilirlik ve bakım gereksinimlerini nasıl karşıladığıyla değerlendirilmelidir. Firma, önerdiği mimarinin iş hedefleriyle ilişkisini açıklayabilmelidir. Popüler bir teknoloji kullanılması tek başına doğru karar veya sürdürülebilirlik garantisi oluşturmaz.
Native ve cross-platform teklifleri nasıl karşılaştırılır?
Native mobil uygulama ile cross-platform yaklaşım; platform sayısı, cihaz özelliklerine erişim, kullanıcı deneyimi, ekip yetkinliği ve uzun vadeli bakım açısından karşılaştırılmalıdır. Flutter veya React Native ortak kod avantajı sunabilir; ancak özel donanım, yoğun animasyon veya platforma özgü işlevler ek çalışma gerektirebilir. Firma, seçimini ürün yol haritasıyla gerekçelendirmelidir.
- Hedeflenen iOS ve Android platformlarının kapsamı
- Performans, çevrimdışı kullanım ve cihaz entegrasyonları
- Backend mimarisi, veri tabanı ve API yaklaşımı
- Ölçeklenebilirlik, izleme, yedekleme ve hata yönetimi
- Teknoloji bağımlılıkları, dokümantasyon ve bakım kapasitesi
UX/UI, Backend ve Entegrasyon Kapsamı Nasıl Kontrol Edilir?
UX/UI, backend ve entegrasyon kapsamları birbirinden ayrı teslim kalemleri olarak kontrol edilmelidir. Mobil uygulama tasarımı yalnızca görsel ekranlardan; backend ise yalnızca veri tabanı kurulumundan oluşmaz. Kullanıcı araştırması, işlem akışları, iş kuralları, yönetim araçları ve sistemler arası veri alışverişi teklif içinde açıkça tanımlanmalıdır.
Entegrasyon tekliflerinde hangi ayrıntılar sorgulanmalıdır?
Ödeme, harita, bildirim, analitik, CRM veya ERP bağlantılarında servis adının yazılması yeterli değildir. Kimlik doğrulama, veri eşleştirme, hata senaryoları, test ortamı ve kullanım limitleri değerlendirilmelidir. Geliştirme bedeli ile servis sağlayıcının lisans veya işlem ücretleri ayrılmalı; kesinti hâlindeki davranış ve sağlayıcı değiştirme imkânı açıklanmalıdır.
- Kullanıcı araştırması, wireframe, prototip ve tasarım sistemi
- Mobil ekranların boş, dolu, hata ve çevrimdışı durumları
- Backend servisleri, iş kuralları ve veri modeli
- Rol bazlı yönetim paneli ve operasyon araçları
- Entegrasyon kapsamı, servis ücretleri ve teknik bağımlılıklar
Ekip Yetkinliği ve Proje Yönetimi Nasıl İncelenir?
Ekip yetkinliği, şirketin genel tanıtımından çok projede fiilen görev alacak kişilerin deneyimi ve sorumlulukları üzerinden incelenmelidir. Ürün yöneticisi, UX/UI tasarımcısı, mobil geliştirici, backend geliştirici ve test uzmanının katkıları farklıdır. Yeterli rol dağılımı, gereksiz kalabalıktan ziyade kararların ve kalite kontrollerinin sahiplerini görünür kılmalıdır.
Portföy, referans ve çalışma modeli ne gösterir?
Portföy yalnızca arayüz estetiği üzerinden değerlendirilmemelidir. Benzer iş modeli, kullanıcı rolleri, entegrasyonlar, uygulamanın yayında olup olmadığı ve firmanın bakım sorumluluğu sorgulanmalıdır. Proje yönetiminde toplantı düzeni, ilerleme raporları, görev takibi, geri bildirim süreleri, onay mekanizması ve kapsam değişikliği prosedürü yazılı biçimde açıklanmalıdır.
- Projede görev alacak ekip üyeleri ve sorumlulukları
- Benzer teknik kapsam ve iş modeline sahip referanslar
- Yayındaki uygulamalar ve devam eden bakım deneyimi
- Raporlama, toplantı, görev ve risk yönetimi yaklaşımı
- Geri bildirim, onay ve değişiklik talebi süreçleri
Güvenlik, Test ve Mağaza Yayını Nasıl Karşılaştırılır?
Güvenlik, test ve mağaza yayın kapsamı, “dahildir” ifadesiyle değil uygulanacak kontroller ve sorumluluklarla karşılaştırılmalıdır. Kişisel veya finansal veri işleyen uygulamalarda kimlik doğrulama, yetkilendirme, veri saklama ve loglama yaklaşımı önem kazanır. Bütçe kısıtlandığında kaliteyi azaltmak yerine temel olmayan özelliklerin sonraki fazlara ertelenmesi daha güvenli bir karardır.
Test ve kabul süreçlerinde hangi ölçütler aranmalıdır?
Fonksiyon, regresyon, cihaz uyumluluğu, performans, güvenlik ve kullanıcı kabul testleri farklı riskleri hedefler. Hataların sınıflandırılması, düzeltilme sorumluluğu ve yeniden test süreci belirlenmelidir. KVKK gereksinimleri gerektiğinde hukuk ve veri koruma uzmanlarıyla değerlendirilmelidir. Mağaza hesabı sahipliği, başvuru belgeleri ve inceleme düzeltmeleri de açıklanmalıdır.
- Kimlik doğrulama, yetkilendirme ve veri güvenliği yaklaşımı
- Fonksiyon, regresyon ve cihaz uyumluluk testleri
- Performans, ağ kesintisi ve hata senaryosu kontrolleri
- Kullanıcı kabul kriterleri ve hata düzeltme sorumluluğu
- App Store ve Google Play hazırlığı ile yayın desteği
Sözleşme ve Dijital Varlık Sahipliği Nasıl Düzenlenir?
Mobil uygulama sözleşmesi; kapsam, teslimat, kabul, ödeme, değişiklik, garanti, bakım, gizlilik, fesih ve devir koşullarını açıkça düzenlemelidir. Kaynak kodunun teslim edileceğinin belirtilmesi tek başına yeterli değildir. Kod depoları, tasarım dosyaları, dokümantasyon, bağımlılıklar ve kurulum bilgilerinin hangi aşamada aktarılacağı ayrıca tanımlanmalıdır.
Hesaplar ve fikrî mülkiyet hakları kime ait olmalıdır?
Veri, mağaza, sunucu, alan adı, analitik ve üçüncü taraf servis hesaplarının sahipliği ayrı ayrı kontrol edilmelidir. Operasyonel bağımsızlık için hesapların mümkün olduğunda kurum adına açılması ve firmaya gerekli yetkilerin verilmesi tercih edilebilir. Fikrî mülkiyet, lisanslı bileşenler, açık kaynak yükümlülükleri ve yeniden kullanım hakları uzman sözleşme incelemesiyle netleştirilmelidir.
- Kaynak kodu, tasarım dosyaları ve teknik dokümantasyon
- Veri tabanı, yedekler ve veri dışa aktarma imkânı
- Mağaza, sunucu, analitik ve servis hesapları
- Fikrî mülkiyet, lisans ve üçüncü taraf bileşenleri
- Fesih, devir desteği ve erişim bilgilerinin teslimi
Bakım Maliyeti ve Doğru Firma Seçimi Nasıl Yapılır?
Doğru mobil uygulama geliştirme firması, yalnızca en düşük teklifi veren değil; kurumun kapsamını, risklerini ve yaşam döngüsü ihtiyaçlarını şeffaf biçimde yönetebilen çözüm ortağıdır. İlk geliştirme bedeline sunucu, lisans, üçüncü taraf hizmetleri, bakım, güvenlik güncellemeleri ve yeni fazlar eklendiğinde toplam sahip olma maliyeti ortaya çıkar.
Nihai firma kararında hangi kriterler kullanılmalıdır?
Nihai seçim; kapsam uyumu, teknik yeterlilik, ekip deneyimi, proje yönetimi, sahiplik koşulları ve destek kapasitesinin birlikte puanlanmasına dayanmalıdır. Garanti, mevcut kapsamdaki hataların giderilmesini; bakım ise güncelleme ve devam eden teknik hizmetleri ifade edebilir. Ankara merkezli bir firmayla yüz yüze çalışma kolaylık sağlayabilir, ancak belirleyici ölçüt doğrulanabilir yetkinlik olmalıdır.
- Ortak ihtiyaç kapsamına verilen eksiksiz ve şeffaf yanıt
- Teknik yaklaşımın ürün hedefleriyle tutarlı gerekçesi
- Ekip, referans, iletişim ve proje yönetimi yeterliliği
- Sahiplik, sözleşme, garanti ve devir koşulları
- Bakım kapsamı, destek düzeyi ve müdahale yöntemi
- İlk yatırım ile devam eden giderlerin açık ayrımı