Mobil Uygulama Teklifi Alırken Sorulacak 12 Soru

Aynı uygulama fikri için aldığınız iki teklif arasında büyük fark olabilir. Bu farkın nedenini yalnızca toplam fiyatı karşılaştırarak anlayamazsınız. Bu rehberde mobil uygulama teklifinde hangi teslimleri, sorumlulukları ve kabul koşullarını aramanız gerektiğini somut bir kontrol listesiyle açıklıyoruz.

Teklifler gerçekten aynı uygulamayı mı kapsıyor?

Bir bakım işletmesinin müşterilerine arıza kaydı açtırmak istediğini düşünün. İlk tedarikçi yalnızca müşteri ekranlarını, diğeri müşteri ekranlarıyla birlikte çalışan panelini ve sunucu hizmetlerini fiyatlandırmış olabilir. Başlıkta ikisi de “mobil uygulama geliştirme” yazar, fakat teslim edilen ürün farklıdır.

Karşılaştırmaya başlamadan önce tek sayfalık ihtiyaç belgesi hazırlayın. Kullanıcı türleri, tamamlanacak işler, hedef platformlar ve mevcut sistem bağlantıları bu belgede bulunsun. Ekran sayısından önce temel akışın başlangıcını ve bitişini tanımlayın.

Örneğimizde müşteri fotoğraf ekleyecek, servis adresini seçecek ve talebini gönderecek olsun. Çalışan talebi görecek, görev atayacak ve sonucu kapatacak. Bu zincirin hangi parçalarının teklifte bulunduğunu kontrol edin; eksik parça için sonradan ayrı iş çıkabilir.

Mobil uygulama teklifinde kontrol edilecek 12 madde

Ürün ve tasarım kapsamı: İlk dört soru

1. Kim ne yapacak? Müşteri, çalışan ve yönetici rolleri ayrı tanımlanmış mı; her rolün tamamladığı işler yazılı mı?
2. Hangi platformlar var? Android, iOS, tablet ve web panelinden hangileri dahil; desteklenecek cihazlar nasıl seçilecek?
3. Tasarım teslimi nedir? Tıklanabilir prototip, ekran tasarımları ve tasarım dosyaları verilecek mi; geri bildirim turları nasıl işleyecek?
4. Kapsam dışında ne var? Ödeme, çoklu dil, çevrimdışı kullanım ve yeni kullanıcı rolleri gibi ertelenen işler açıkça listelenmiş mi?

Yalnızca “modern tasarım” gibi ifadeler somut teslim tanımlamaz. Prototipte talep oluşturma yolculuğunu görebilmeli, hata ve boş ekran davranışlarını konuşabilmelisiniz. İçeriklerin kim tarafından sağlanacağı da belli olmalı; hazır olmayan metin ve görseller onay sürecini durdurabilir.

Tasarım revizyonunu sınırsız bir hak gibi düşünmek de sorun yaratabilir. Geri bildirimlerin tek kişide toplanması, kararın yazılı verilmesi ve onaylı ekranın nasıl değiştirileceğinin belirlenmesi işleri düzenler. Bu yöntem her iki tarafın da takvimi daha doğru izlemesine yardımcı olur.

Teknik kapsam ve yayın: Sonraki dört soru

1. Sunucu ve panel dahil mi? Verilerin tutulacağı yapı, yönetim ekranları, yedekleme ve izleme sorumlulukları tanımlanmış mı?
2. Entegrasyonun sınırı belli mi? Hangi sistemle hangi veriler paylaşılacak; bağlantı, test ortamı ve dış hizmet ücretini kim sağlayacak?
3. Test nasıl yapılacak? Temel akışların yanında yetki hataları, kesinti ve tekrar gönderim senaryoları kontrol edilecek mi?
4. Yayın neyi ifade ediyor? Mağazaya paket yüklemek mi, inceleme geri bildirimlerini ele almak mı, indirilebilir ürün teslimi mi?

Güvenlikte “giriş ekranı var” ifadesi yeterli değildir. Başka müşterinin kaydına erişme girişiminin de engellenmesi gerekir. OWASP, erişim izinlerinin her istekte kontrol edilmesini ve açıkça izin verilmeyen erişimin varsayılan olarak reddedilmesini önerir: Yetkilendirme rehberi, erişim 28 Ekim 2026.

Bu kontrolü teklifte teknik terimler yığınına çevirmek zorunda değilsiniz. “Müşteri yalnızca kendi servis kayıtlarını görür; çalışan yalnızca yetkili olduğu şubenin görevlerini açar” gibi doğrulanabilir örnekler yazın. Tedarikçiden bu koşulların nasıl test edileceğini açıklamasını isteyin.

Sahiplik ve destek: Son dört soru

1. Hesapların kontrolü kimde? Mağaza, sunucu, alan adı ve dış hizmet hesaplarında işletmenizin erişim ve yönetim yetkileri belli mi?
2. Hangi dosyalar teslim edilecek? Kaynak kod, tasarım dosyası, kurulum belgesi ve veri dışa aktarımı tanımlanmış mı?
3. Hata ile yeni istek ayrılmış mı? Garanti kapsamındaki düzeltme ve ek geliştirme talebi hangi ölçütle değerlendirilecek?
4. Destek hizmeti nasıl işleyecek? İletişim kanalı, çalışma saatleri, önem dereceleri ve yanıt hedefleri yazılı mı?

Kaynak kodun paylaşılması, sistemi başka bir ekibin hemen çalıştırabileceği anlamına gelmez. Bağımlılıklar, kurulum adımları ve dış hizmet bağlantıları da teslimin parçasıdır. Kullanılan üçüncü taraf lisansları ve devredilemeyen bileşenler konusunda da açıklama isteyin.

Teklifleri tek tabloda nasıl karşılaştırırsınız?

Her satıra bir teslim yazıp tedarikçilerden “dahil”, “hariç” veya “ek açıklama gerekli” yanıtı alın. “Anahtar teslim” gibi genel ifadeleri bu tabloyla somutlaştırın. Bir kalem dahil görünüyorsa kapsamını ve kabul ölçütünü de not edin.

Bu tabloyu yalnızca satın alma aşamasında kullanmayın. Proje boyunca yapılan gösterimlerde ilgili satırları gözden geçirin. Böylece teslim haftasında “bu özellik konuşulmamıştı” tartışması yerine üzerinde anlaşılmış listeye dönersiniz.

Fiyat, ödeme ve takvim koşullarını nasıl okumalı?

Toplam tutarın para birimini, vergi durumunu ve geçerlilik tarihini kontrol edin. Aylık altyapı ile tek seferlik geliştirme bedelini ayırın. Kullanıma bağlı SMS, depolama veya harita giderlerinin hangi hesaptan ödeneceğini sorun.

Örnek olarak tamamen varsayımsal iki teklif düşünün: Biri 180.000 TL karşılığında yalnızca mobil ekranları, diğeri 280.000 TL karşılığında mobil ekran, sunucu ve paneli kapsıyor olsun. Bu tutarlar piyasa verisi veya Navdion fiyatı değildir. KDV ve dış giderler ayrıca açıklanmadan, yalnızca düşük toplamı seçmek sağlıklı bir karşılaştırma olmaz.

Ödemeleri inceleyebileceğiniz çıktılarla ilişkilendirmek isteyebilirsiniz: onaylı prototip, çalışan temel akış, kabul sürümü ve devir gibi. Takvimde sizin sağlamanız gereken bilgi ve onayların tarihleri de bulunsun. Entegrasyon erişimi gecikirse planın nasıl güncelleneceğini önceden konuşun.

Teslim ve kabulü gerçek senaryolarla tanımlayın

Örneğimizde müşteri aynı talebi zayıf bağlantı nedeniyle iki kez gönderebilir. Beklenen davranışın iki ayrı servis kaydı açmak mı, mevcut kaydı göstermek mi olduğunu kararlaştırın. Bu tür senaryolar, yalnızca ekranın görünmesine bakarak kabul yapmanın eksik kaldığını gösterir.

Bir diğer senaryo çalışan değişikliğidir. Ayrılan kişinin erişimi kapatılabilmeli, yeni kişi yetkisine uygun görevleri görebilmelidir. Sonradan müdahale gerektirmeden işletmenin bunları yönetip yönetemediğini test edin.

Kabul için planlama örneği olarak bir hafta ayırabilir; günlük çalışmada kullanılan temel senaryoları önceden hazırlayabilirsiniz. Bu süre sabit bir standart değildir, kapsamınıza göre değişir. Kritik hata bulunursa düzeltmenin ardından ilgili akışı ve etkilediği işlemleri yeniden kontrol edin.

Yeni istek gelirse ne yapılmalı?

Proje sırasında yeni ihtiyaç çıkması doğaldır. Örneğin arıza kaydına sonradan online ödeme eklemek, yalnızca bir düğme çizmek değildir. Başarılı ve başarısız ödeme, iptal, iade ve kayıt eşleştirme işleri doğabilir.

Yeni isteği kısa bir değişiklik formuna yazın: Beklenen davranış, gerekçe, ek iş yükü, bedel ve teslim tarihine etkisi. Onay verilene kadar hangi kapsamın geçerli olduğunu belirtin. İlk sürüme eklemek yerine sonraki sürüme bırakmak da değerlendirilmelidir.

Seçenekleri değerlendirmek için hazır altyapı ve özel yazılım karşılaştırmasına bakabilirsiniz. Web tarafıyla ortak panel veya içerik altyapısı kullanılacaksa kurumsal site kontrol listesindeki yönetim ihtiyaçlarını da kapsam belgesine ekleyin.

Teklif görüşmesinde nasıl bir gösterim istemelisiniz?

Tedarikçiden yalnızca başarılı ekranları göstermesini istemeyin. Örnek bir kaydı açıp değiştirerek, işlemi iptal ederek ve farklı kullanıcı rolüyle tekrar görüntüleyerek ilerleyin. Hazır ürün demosu yapılıyorsa sizin senaryonuzda hangi adımların mevcut olduğunu, hangilerinin geliştirme gerektirdiğini not edin.

Özel geliştirilecek üründe henüz çalışan ekran bulunmayabilir. Bu durumda tıklanabilir prototip, akış çizimi ve kabul senaryosu üzerinden aynı görüşme yapılabilir. Görsel prototipin gerçek ödeme, veri saklama veya yetki denetimi yaptığı varsayılmamalıdır; hangi kısmın yalnızca taslak olduğunu netleştirin.

Görüşme sonrasında kısa bir karar notu hazırlayın. Yanıtsız soruları, sorumluları ve hangi belgeyle açıklığa kavuşacaklarını yazın. Sözlü olarak konuşulan önemli bir teslimin son teklif sürümünde bulunup bulunmadığını kontrol edin; eski dosya üzerinden karar vermeyin.

Karşılaştırmayı tamamladığınızda ekibinizde uygulamayı yönetecek kişinin de listeyi incelemesini sağlayın. Satın alma açısından açık görünen bir teklif, günlük operasyon için gerekli izin veya dışa aktarım işini atlamış olabilir. Kullanacak kişinin katılması bu eksikleri daha erken görünür kılar.

Sonuç: Önce teslimleri netleştirin

Teklif almadan önce temel akışınızı ve kapsam dışı işleri yazın. Gelen teklifleri bu listedeki teslim, test, sahiplik ve destek koşullarıyla karşılaştırın. Navdion ile ihtiyaç belgenizi ve uygulamanızın ilk sürüm kapsamını değerlendirmek için ücretsiz proje analizi talep edebilirsiniz.