Mobil Web Yazılımı Teklifi Nasıl Değerlendirilir? Kapsam, Maliyet ve Sözleşme Rehberi

Mobil Web Yazılımı Teklifi Neden Kapsamla Başlamalı?

Mobil web yazılımı teklifi, projenin hangi iş ihtiyacını karşılayacağını ve hangi teslimatları içereceğini açıklayarak başlamalıdır. Yalnızca “kurumsal site yapılacaktır” veya “özel yazılım geliştirilecektir” gibi genel ifadeler; ekranları, kullanıcı işlemlerini, entegrasyonları ve tarafların sorumluluklarını karşılaştırmak için yeterli değildir.

Teklif bedelinden önce teslimatları eşitlemek

Bir firma tasarım, içerik girişi ve bakımı dâhil ederken başka bir firma yalnızca yazılım geliştirmeyi fiyatlandırabilir. Bu iki bedel aynı hizmeti temsil etmez. Sağlıklı teklif karşılaştırmasının temeli ortak ihtiyaç belgesi ve eşdeğer teslimatlardır. Teklifte varsayımlar ile kapsam dışında bırakılan işlerin de görünür olması gerekir.

• Projenin iş hedefi ve hedef kullanıcıları
• Kapsam içindeki sayfa ve modüller
• Firma ile müşteri tarafının sorumlulukları
• Hariç tutulan hizmet ve giderler
• Test, yayın ve destek teslimatları

İyi tasarım, mümkün olduğunca az tasarımdır. - Dieter Rams

Karşılaştırılabilir Teklif İçin İhtiyaç Belgesi Nasıl Yazılır?

Karşılaştırılabilir teklifler almak için bütün firmalara aynı ihtiyaç belgesi gönderilmelidir. Bu belge, hazır bir özellik listesi olmaktan çok işletmenin hedeflerini, kullanıcıların gerçekleştireceği işlemleri, yönetim ihtiyaçlarını ve başarı ölçütlerini açıklamalıdır. Firmalar çözüm önerilerini bu ortak gereksinimler üzerinden hazırlamalıdır.

İş gereksinimlerini ölçülebilir kapsama dönüştürmek

İhtiyaç belgesinde sayfa isimlerinin yanında formlar, iş akışları, kullanıcı rolleri, onaylar, raporlar ve entegrasyonlar belirtilmelidir. İçeriklerin kim tarafından sağlanacağı ve mevcut verilerin taşınıp taşınmayacağı da yazılmalıdır. web tasarım firmasından teklif alırken sorulması gerekenler, belirsiz kapsam noktalarını teklif öncesinde görünür kılabilir.

• İş hedefleri ve beklenen kullanıcı davranışları
• Sayfa, modül, form ve kullanıcı rolleri
• İçerik, görsel ve veri sorumlulukları
• Entegrasyon ve raporlama ihtiyaçları
• Performans, güvenlik ve kabul ölçütleri
• Gelecekte planlanan geliştirmeler

UX/UI ve İçerik Kapsamı Teklifte Nasıl Gösterilmelidir?

UX/UI ve içerik kapsamı; tasarlanacak ekranlar, responsive durumlar, prototipler, revizyonlar ve içerik sorumlulukları ayrı ayrı belirtilerek gösterilmelidir. “Özgün tasarım” ifadesi tek başına yeterli değildir; hangi sayfaların özgün hazırlanacağı ve tekrar kullanılacak bileşenlerin nasıl oluşturulacağı açıklanmalıdır.

Tasarım, içerik ve çoklu dil sorumlulukları

Web tasarım teklifinde metin yazımı, görsel üretimi, içerik girişi ve çeviri birbirinden ayrılmalıdır. Çok dilli projelerde sayfaların yanı sıra menüler, formlar, sistem mesajları, meta alanları ve URL yapıları da değerlendirilir. Hazır tema kullanılacaksa lisansı, özelleştirme sınırları ve tasarım dosyalarının teslim durumu belirtilmelidir.

• Bilgi mimarisi ve kullanıcı akışları
• Mobil ve masaüstü ekran tasarımları
• Prototip ve revizyon aşamaları
• Metin, görsel ve içerik girişi
• Çeviri ve çoklu dil uygulaması
• Tasarım kaynak dosyalarının teslimi

Teknoloji ve Yönetim Paneli Kapsamı Nasıl İncelenir?

Teknoloji ve yönetim paneli kapsamı, yalnızca programlama dili veya altyapı adı üzerinden değerlendirilmemelidir. Teklif; mimarinin neden seçildiğini, içeriklerin nasıl yönetileceğini, kullanıcı yetkilerini, sistem bağımlılıklarını ve gelecekte yeni modüller eklenirken izlenecek yaklaşımı açıklamalıdır.

Teknik yeterliliği proje gereksinimleriyle ölçmek

Kurumsal web sitesi teklifi standart bir içerik yönetim sistemi içerebilirken özel uygulama; iş kuralları, rol bazlı yetkilendirme ve özel veri modeli gerektirebilir. web tasarım firmasının teknik yeterliliğini doğrulama yöntemleri, teknoloji isimlerinin ötesinde kod kalitesi, test, dokümantasyon ve sürdürülebilirlik kanıtlarının incelenmesine yardımcı olur.

• Yazılım mimarisi ve seçim gerekçesi
• İçerik ve modül yönetim özellikleri
• Kullanıcı rolleri ve yetki seviyeleri
• Kod standardı ve sürüm yönetimi
• Teknik dokümantasyon kapsamı
• Yeni özellik ekleme kapasitesi

Entegrasyonlar Mobil Yazılım Teklifinde Nasıl Tanımlanır?

Entegrasyonlar teklif içinde servis adıyla değil, aktarılacak veri ve iş akışıyla tanımlanmalıdır. ERP, CRM, ödeme, kargo veya başka bir sistem bağlantısında hangi verinin hangi yönde, ne zaman ve hangi kurallarla aktarılacağı açıklanmadığında geliştirme ve test kapsamı belirsiz kalır.

API, hata yönetimi ve üçüncü taraf bağımlılıkları

Her entegrasyon için API erişiminin kim tarafından sağlanacağı, test ortamının bulunup bulunmadığı, hata durumlarının nasıl yönetileceği ve üçüncü taraf değişikliklerinin bakım kapsamına girip girmediği belirtilmelidir. Servis ücretleri, işlem maliyetleri ve kullanım sınırları yazılım geliştirme bedelinden ayrı gösterilerek toplam işletme giderine dâhil edilmelidir.

• Aktarılacak veri alanları ve yönü
• Senkronizasyon zamanı ve sıklığı
• API erişimi ve test ortamı
• Hata kayıtları ve yeniden deneme kuralları
• Üçüncü taraf servis ücretleri
• Entegrasyon dokümantasyonu ve sorumluluğu

SEO, Performans ve Erişilebilirlik Nasıl Karşılaştırılır?

SEO, performans ve erişilebilirlik teslimatları, tekliflerde ölçülebilir teknik çalışmalar olarak tanımlanmalıdır. Yalnızca “SEO uyumlu” veya “hızlı web sitesi” ifadeleri hangi işlemlerin yapılacağını göstermez. URL mimarisi, metadata, yapılandırılmış veri, Core Web Vitals, görsel optimizasyonu ve erişilebilir arayüz kontrolleri ayrı ayrı açıklanmalıdır.

Genel vaatleri doğrulanabilir kabul kriterlerine çevirmek

Teknik SEO’nun içerik üretimini veya sıralama garantisini kapsamadığı, performans sonuçlarının da içerik, hosting ve üçüncü taraf servislerden etkilenebileceği belirtilmelidir. SEO ve GEO uyumlu web tasarım firmasının sunması gerekenler, tekliflerde arama görünürlüğü ile teknik altyapı sorumluluklarının ayrıştırılmasını kolaylaştırır.

• Taranabilir sayfa ve bağlantı yapısı
• Meta alanları ve yapılandırılmış veri
• Core Web Vitals ve hız ölçümleri
• Görsel ve kod optimizasyonu
• Mobil uyumluluk testleri
• Klavye ve ekran okuyucu erişilebilirliği

Güvenlik, Test ve Kabul Şartları Nasıl Yazılmalıdır?

Güvenlik, test ve kabul şartları; uygulanacak kontrolleri, test sorumlularını ve teslimatın hangi ölçütlerle onaylanacağını belirtmelidir. SSL sertifikası tek başına güvenlik kapsamı değildir. Yetkilendirme, oturum yönetimi, veri doğrulama, yedekleme, loglama ve güncelleme yaklaşımı projenin risk düzeyine göre tanımlanmalıdır.

Yayına geçmeden önce doğrulanacak senaryolar

Fonksiyon testleri, responsive cihaz kontrolleri, tarayıcı uyumluluğu, form doğrulamaları, entegrasyon senaryoları ve yetki testleri kabul planına bağlanmalıdır. KVKK ve çerez süreçlerinde kurumun hukuki sorumlulukları ile firmanın teknik uygulama görevleri ayrılmalıdır. Yayına geçiş, veri aktarımı, yedekleme ve gerektiğinde geri dönüş adımları da teklifte bulunmalıdır.

• Fonksiyon ve kullanıcı kabul testleri
• Cihaz ve tarayıcı uyumluluğu
• Rol ve yetki kontrolleri
• Güvenlik ve veri doğrulama testleri
• Yedekleme ve geri dönüş planı
• Yayın öncesi hata sınıflandırması

Mobil Yazılım Maliyeti ve Düşük Teklif Nasıl Okunur?

Mobil yazılım maliyeti; analiz, tasarım, geliştirme, içerik, entegrasyon, test ve destek kapsamlarının toplamıyla değerlendirilmelidir. Düşük fiyatlı bir teklif otomatik olarak yetersiz değildir; hazır bileşen kullanımı, daha dar teslimat kapsamı, sınırlı revizyon veya farklı bakım modeli nedeniyle bedel daha düşük olabilir.

Fiyat farkının arkasındaki kapsamı bulmak

Düşük teklif incelenirken içerik girişi, veri taşıma, lisanslar, güvenlik testleri, SEO altyapısı, dokümantasyon ve proje sonrası desteğin dâhil olup olmadığı kontrol edilmelidir. özel web yazılımı maliyetinin nasıl hesaplandığı, toplam bedelin işlev, ekip emeği ve uzun vadeli sorumluluklarla birlikte değerlendirilmesini sağlar.

• Hazır tema ve bileşen kullanımı
• İçerik ve veri taşıma kapsamı
• Test ve dokümantasyon teslimatları
• Lisans ve servis giderleri
• Garanti ve bakım koşulları
• Kapsam dışı bırakılan işler

Kaynak Kodu ve Fikrî Mülkiyet Hakları Nasıl Düzenlenir?

Kaynak kodu ve fikrî mülkiyet hakları, tarafların anlaşmasına ve kullanılan bileşenlerin lisanslarına göre sözleşmede açıkça düzenlenmelidir. Her proje için geçerli tek bir sahiplik modeli yoktur. Projeye özel geliştirilen kod, açık kaynak bileşenler, ticari eklentiler, tasarım dosyaları ve içerik hakları ayrı ayrı değerlendirilmelidir.

Teknik teslim ile hukuki hakkı birbirinden ayırmak

Kaynak koduna erişim, kod üzerindeki bütün hakların otomatik devredildiği anlamına gelmeyebilir. Kullanım, değiştirme, çoğaltma ve başka firmaya devretme koşulları yazılı olmalıdır. Alan adı, hosting, veriler, analiz hesapları ve üçüncü taraf servislerin hangi taraf adına açıldığı da kontrol edilmelidir. Sözleşme hükümleri gerektiğinde yetkin hukuk danışmanıyla incelenmelidir.

• Projeye özel geliştirilen kaynak kodu
• Açık kaynak bileşenlerin lisansları
• Ticari tema ve eklenti hakları
• Tasarım kaynak dosyalarının sahipliği
• Veri, alan adı ve hesap erişimleri
• Değiştirme ve başka firmaya devretme koşulları

Takvim, Revizyon ve Ödeme Planı Nasıl Değerlendirilir?

Takvim, revizyon ve ödeme planı birbirini destekleyen teslim aşamalarına bağlanmalıdır. Yalnızca başlangıç ve bitiş tarihi belirtilmesi, içerik teslimi, entegrasyon erişimi, müşteri onayı ve test gibi bağımlılıkları açıklamaz. Her aşamanın çıktısı ve onay sorumlusu tanımlandığında proje ilerlemesi daha nesnel biçimde izlenebilir.

Değişiklik taleplerini kapsamdan ayırmak

Revizyonun mevcut tasarım veya işlev üzerindeki düzeltme mi, yoksa yeni kapsam oluşturan ek geliştirme mi olduğu açıklanmalıdır. “Sınırsız revizyon” gibi ölçülemeyen ifadeler yerine geri bildirim turları, onay yöntemi ve ek iş süreci yazılmalıdır. Ödeme aşamalarının analiz, tasarım, geliştirme, kabul ve yayın teslimatlarıyla ilişkisi kurulmalıdır.

• Aşamalı teslim ve onay planı
• Müşteri ve firma bağımlılıkları
• Geri bildirim ve revizyon turları
• Ek iş tanımı ve onay yöntemi
• Ödeme ile teslimat ilişkisi
• Gecikme ve değişiklik bildirim süreci

Garanti, Bakım ve Teknik Destek Nasıl Ayrılmalıdır?

Garanti, bakım, teknik destek ve yeni geliştirme sözleşmede ayrı hizmetler olarak tanımlanmalıdır. Garanti genellikle kabul edilen kapsamda bulunan yazılım hatalarının ele alınmasını; bakım güncelleme ve önleyici kontrolleri; teknik destek kullanım veya işletim taleplerini; yeni geliştirme ise mevcut kapsamın genişletilmesini ifade eder.

Belirsiz destek vaatlerini ölçülebilir hâle getirmek

Destek kanalları, sorumlu ekip, hizmet saatleri, talep öncelikleri ve müdahale yöntemi belirtilmelidir. Hosting, yedekleme, izleme, güvenlik güncellemeleri ve üçüncü taraf servis değişikliklerinin hangi pakete dâhil olduğu açıklanmalıdır. “Sürekli destek” ifadesi yerine sağlanacak işlemler ve kapsam dışı durumlar yazılı hâle getirilmelidir.

• Garanti kapsamındaki hata tanımı
• Bakım ve güvenlik güncellemeleri
• Destek kanalları ve hizmet saatleri
• Talep sınıflandırma ve müdahale yöntemi
• Yeni geliştirme ücretlendirme süreci
• Yedekleme ve izleme sorumluluğu

Nihai Yazılım Firması Karşılaştırması Nasıl Yapılır?

Nihai yazılım firması karşılaştırması, her teklifin ortak bir değerlendirme tablosuna aktarılmasıyla yapılmalıdır. Toplam bedelin yanında teslimatlar, kapsam dışı işler, teknik standartlar, lisanslar, sahiplik, takvim, garanti, bakım ve devir koşulları birlikte incelenmelidir. Eksik veya belirsiz alanlar satın alma kararından önce yazılı olarak netleştirilmelidir.

Sözleşme öncesi teklif değerlendirme kontrolü

Seçilen teklif, ihtiyaç belgesi ve sözleşme arasında tutarlılık bulunmalıdır. Kaynak kodunun yanında dokümantasyon, veritabanı, kurulum bilgileri, güncel yedekler ve hesap erişimleri de devir planına eklenmelidir. web yazılım sözleşmesinde bulunması gereken konular ile firma değişikliğinde kontrol edilecek devir şartları, sürdürülebilirlik risklerini azaltmaya yardımcı olur.

• Bütün teklifleri ortak kapsamla eşleştirin
• Hariç tutulan işleri ve varsayımları işaretleyin
• Teknik ve ticari teslimatları doğrulayın
• Lisans ve sahiplik koşullarını karşılaştırın
• Garanti, bakım ve desteği ayrı inceleyin
• Devir teslim belgelerini sözleşmeye ekleyin
• Belirsiz maddeleri yazılı olarak netleştirin