Web Yazılım Fiyatları Neye Göre Belirlenir? Kapsam ve Bütçe Rehberi

Web yazılım fiyatı; sayfa veya ekran sayısından değil, çözülmesi gereken iş süreci, kullanıcı rolleri, iş kuralları, veri, entegrasyonlar, kalite koşulları ve yayın sonrası sorumlulukların toplamından oluşur. Aynı görünen iki portal; birinde tek rol ve manuel veri girişi, diğerinde farklı yetkiler, ERP bağlantısı, veri taşıma ve kritik işlem kaydı bulunduğu için tamamen farklı emek ve risk içerebilir.

Bu nedenle ihtiyaçlar anlaşılmadan verilen tek rakam çoğu zaman kesin fiyat değil, varsayımlara dayalı ilk tahmindir. Sağlıklı bir teklif şu üç şeyi birlikte göstermelidir:

1. Hangi sonuç ve teslimler fiyatın içinde?
2. Hangi varsayımlar, bağımlılıklar ve işler fiyatın dışında?
3. Değişiklik, işletim ve yayın sonrası maliyetler nasıl yönetilecek?

Bu rehber piyasa fiyatı veya Kumsal Ajans fiyat tarifesi sunmaz. Her projenin kapsamı, ekip yapısı, ticari modeli ve zamanı farklıdır. Amaç, gelen teklifin hangi işi satın aldığını ve toplam bütçenin hangi kalemlerden oluştuğunu değerlendirebileceğiniz bir çerçeve vermektir.

Web yazılım fiyatını belirleyen 10 ana unsur

1. Keşif ve gereksinim belirsizliği

“Bayi portalı istiyoruz” veya “mevcut süreci dijitalleştireceğiz” bir başlangıçtır; teklif için yeterli kapsam değildir. Kullanıcılar, akışlar, kurallar ve entegrasyonlar henüz bilinmiyorsa ekip önce keşif ve analiz yapar.

Keşif çalışması şunları içerebilir:

• iş hedefi ve başarı ölçütleri,
• mevcut süreç ve sorunlar,
• kullanıcı görüşmeleri veya paydaş toplantıları,
• roller ve yetkiler,
• temel kullanıcı akışları,
• veri ve mevcut sistem incelemesi,
• entegrasyon uygunluğu,
• ilk sürüm önceliklendirmesi,
• teknik risk ve bağımlılıklar,
• gereksinim ve kabul kriterleri.

Belirsizlik yüksekken sabit geliştirme fiyatı istenirse sağlayıcı ya riski fiyata ekler ya da teklifi dar varsayımlarla sınırlar. Ayrı ve sınırlı bir keşif aşaması, önce kapsamı tanımlayıp ardından daha güvenilir geliştirme planı oluşturmayı sağlayabilir.

2. Kullanıcı rolleri ve yetki modeli

Bir giriş ekranı bulunması tek başına karmaşıklığı göstermez. Müşteri, bayi, çalışan, yönetici, finans, operasyon ve destek rollerinin farklı verileri görmesi veya farklı işlemler yapması gerekiyorsa analiz, arayüz, geliştirme ve test kapsamı büyür.

Maliyeti etkileyen sorular:

• Kullanıcılar nasıl kayıt olur veya davet edilir?
• Bir kişi birden fazla kuruluş veya role bağlı olabilir mi?
• Yetki sayfa, işlem, alan veya kayıt düzeyinde mi?
• Onay ve vekâlet akışları var mı?
• Kritik işlemler kaydedilecek mi?
• Erişim verme ve kaldırma sorumluluğu kimde?

“Yönetim paneli dahil” ifadesi bu ayrıntıları cevaplamaz. Panelde hangi rollerin hangi işi yapacağı modül bazında yazılmalıdır.

3. İş akışları ve iş kuralları

Bir form verisini kaydetmek ile sipariş, başvuru, rezervasyon veya onay sürecini yönetmek aynı kapsam değildir. Durum geçişleri, hesaplamalar, limitler, fiyat öncelikleri, bildirimler, iptaller ve istisnalar geliştirme ile test süresini etkiler.

Örneğin bir talep sürecinde şunlar ayrı işlerdir:

• talebi oluşturma,
• zorunlu alan ve iş kuralı kontrolleri,
• yetkili kişiye yönlendirme,
• onay veya ret,
• değişiklik geçmişi,
• kullanıcı bildirimi,
• dış sisteme aktarım,
• başarısız aktarımın yeniden işlenmesi,
• raporlama ve dışa aktarma.

Teklifte yalnızca modül adı değil, kapsanan uçtan uca senaryolar ve önemli istisnalar görülmelidir.

4. UX/UI ve tasarım kapsamı

Hazır bir tasarım sistemini sınırlı uyarlamak, markaya özel arayüz dili ve karmaşık işlem deneyimi tasarlamakla aynı değildir.

Tasarım bütçesini etkileyen unsurlar:

• kullanıcı araştırması ve akış tasarımı,
• bilgi mimarisi,
• wireframe ve prototip,
• özgün görsel yön,
• bileşen ve tasarım sistemi,
• masaüstü, tablet ve mobil davranışlar,
• veri tablosu, filtre, grafik ve form yoğunluğu,
• farklı roller için arayüzler,
• erişilebilirlik gereksinimleri,
• içerik, boş durum, hata ve yardım metinleri,
• tasarım onayı ve revizyon sınırları.

Ekran sayısı tek başına doğru ölçü değildir. On benzer liste ekranı, tek bir karmaşık planlama veya veri görselleştirme ekranından daha az tasarım ve test gerektirebilir.

5. Entegrasyonlar ve üçüncü taraf servisler

ERP, CRM, ödeme, kargo, harita, kimlik, e-posta, mesajlaşma veya muhasebe entegrasyonu fiyatı yalnızca “API bağlantısı” kadar artırmaz. Bağlanacak sistemin hazır oluşu ve hata davranışı belirleyicidir.

Her entegrasyon için şu kapsamı arayın:

• veri yönü ve alan eşleştirmesi,
• gerçek zamanlı veya zamanlanmış çalışma,
• kimlik doğrulama ve erişim,
• test ortamı ve örnek veri,
• işlem ve kullanım sınırları,
• zaman aşımı, yeniden deneme ve yinelenen işlem önleme,
• hata kaydı ve bildirim,
• üçüncü taraf değişikliklerinde bakım sorumluluğu,
• lisans, işlem veya abonelik bedeli.

API belgesi bulunmaması, eski sistemin değişmesi veya veri kalitesinin zayıf olması keşif ve uygulama riskini artırır. Üçüncü taraf ücretlerinin ajans teklifine dahil mi yoksa doğrudan müşteri tarafından mı ödeneceği ayrıca yazılmalıdır.

6. Veri modeli, taşıma ve temizleme

Yeni uygulamanın veri yapısını kurmak, mevcut veriyi taşımak ve veriyi düzeltmek farklı işlerdir.

Veri kapsamı şunları etkiler:

• varlık ve alan sayısı,
• ilişkiler ve geçmiş kayıtları,
• içe/dışa aktarma,
• eski sistemden eşleştirme,
• eksik veya yinelenen kayıtların temizlenmesi,
• dosya ve medya taşıma,
• kişisel/hassas veri sınıflandırması,
• saklama ve silme kuralları,
• taşıma denemesi ve mutabakat,
• geçiş sırasında veri dondurma veya paralel çalışma.

“Veri taşıma dahil” ifadesi kaynak, kayıt hacmi, format, temizlik sorumluluğu ve kaç deneme yapılacağını açıklamıyorsa bütçe belirsiz kalır.

7. Teknik mimari ve altyapı

Uygulamanın beklenen kullanım hacmi, kritikliği ve entegrasyon yapısı mimariyi etkiler. Küçük bir iç araç ile yüksek işlem hacmine sahip, kesintisi operasyonu durduran sistem aynı altyapıyı gerektirmez.

Değerlendirilmesi gerekenler:

• kullanım ve trafik varsayımları,
• veri ve dosya hacmi,
• ölçekleme yaklaşımı,
• ortamlar: geliştirme, test, ön izleme, canlı,
• sunucu veya bulut hizmetleri,
• alan adı, TLS ve ağ ayarları,
• hata ve performans izleme,
• yedek ve geri yükleme,
• yayın otomasyonu,
• üçüncü taraf bileşen ve lisanslar,
• teknik dokümantasyon ve devir.

Altyapı giderlerini ilk geliştirme bedeliyle karıştırmayın. Aylık/yıllık hizmetler, kullanım bazlı giderler ve yönetim sorumluluğu ayrı gösterilmelidir.

8. Güvenlik, erişilebilirlik ve kalite doğrulaması

Güvenlik ve test sonradan eklenen isteğe bağlı “ekstra” işler değildir; gereken derinlik uygulamanın riskine göre değişir. NIST Secure Software Development Framework, güvenlik gereksinimlerinin yazılım yaşam döngüsü boyunca bilinmesini, tasarım ve geliştirmede dikkate alınmasını önerir (NIST SSDF SP 800-218).

Bütçede şu çalışmalar ayrıştırılabilir:

• güvenlik gereksinimleri ve tehdit değerlendirmesi,
• rol/yetki kontrolleri,
• kod ve bağımlılık kontrolleri,
• fonksiyon ve entegrasyon testleri,
• tarayıcı ve cihaz testleri,
• erişilebilirlik tasarım ve doğrulaması,
• performans ve yük testleri,
• kullanıcı kabul testi desteği,
• bağımsız güvenlik testi veya sızma testi,
• bulunan sorunların düzeltilmesi ve yeniden test.

Her projede bütün test türlerinin aynı kapsamda yapılması gerekmez. Teklif; hangi kalite çalışmalarının dahil olduğunu, ortamı, sorumluyu ve kabul ölçütünü açıklamalıdır.

9. Yayın, eğitim ve devir

Kodun tamamlanması canlı sistemin kullanıma hazır olduğu anlamına gelmez. Yayın bütçesi şu kalemleri içerebilir:

• canlı ortam kurulumu,
• veri taşıma ve son senkronizasyon,
• alan adı/DNS/TLS işlemleri,
• kullanıcı ve yetki açılışları,
• temel analitik ve olay ölçümü,
• yayın öncesi kontrol,
• geri dönüş planı,
• yönetici/kullanıcı eğitimi,
• kullanım ve teknik dokümantasyon,
• kaynak kod, veri, hesap ve erişim teslimi,
• yayın sonrası yakın takip dönemi.

Bu kalemlerin müşteri ve sağlayıcı arasındaki sahipliği teklif aşamasında yazılmalıdır.

10. Bakım, destek ve yeni geliştirme

Yazılım yayınlandıktan sonra tarayıcılar, işletim ortamı, bağımlılıklar, servisler ve iş ihtiyaçları değişebilir. İlk geliştirme bedelinin bakım, destek ve sınırsız yeni özellik içerdiği varsayılmamalıdır.

Üç işi ayırın:

• Hata düzeltme: Onaylı kapsamın beklenen davranışı göstermemesi.
• Bakım/işletim: Güncelleme, izleme, yedek, servis devamlılığı ve rutin teknik çalışma.
• Yeni geliştirme: Yeni özellik, rol, entegrasyon, tasarım veya değişen iş kuralı.

Destek saatleri, yanıt hedefleri, kritik olay tanımı, dahil edilen çalışma sınırı ve ek geliştirme fiyatlama yöntemi sözleşmede görünmelidir.

Web yazılım bütçesini yedi bölümde planlayın

Teklifleri aynı yapıda karşılaştırmak için aşağıdaki bütçe kırılımını kullanın:

Her satır için “dahil”, “hariç”, “müşteri sorumluluğu”, “üçüncü taraf gideri” veya “keşif sonrası” işaretleri kullanın.

Sabit fiyat, zaman-malzeme ve aşamalı model

Sabit kapsam ve sabit fiyat

Teslimler, kabul kriterleri, bağımlılıklar ve değişiklik yöntemi yeterince açık olduğunda anlamlıdır. Bütçe öngörülebilirliği sağlar; ancak bilinmeyen işlerin görünmez biçimde dahil olduğu anlamına gelmez.

Dikkat edilmesi gerekenler:

• kapsam ve kapsam dışı maddeler,
• müşteri sorumlulukları,
• varsayımlar,
• revizyon ve onay sınırları,
• değişiklik talebi fiyatlama yöntemi,
• geciken içerik/erişim/onayın etkisi.

Zaman ve malzeme

İhtiyaçların öğrenildikçe şekillendiği, ürün kararlarının sık değişebildiği veya teknik belirsizliğin yüksek olduğu çalışmalarda esneklik sağlayabilir. Ancak süre ve harcama kontrolü için görünür backlog, düzenli raporlama, öncelik sahibi ve bütçe sınırı gerekir.

Sorulacaklar:

• rol veya ekip bazında ücretlendirme,
• zaman kaydının nasıl paylaşılacağı,
• tahmin ve fiili karşılaştırması,
• aylık/sprint bütçe sınırı,
• öncelik ve durdurma kararı,
• tamamlanan işin kabul yöntemi.

Aşamalı veya hibrit model

Keşif sabit ve sınırlı kapsamla yapılabilir; ardından MVP için sabit veya kontrollü zaman-malzeme modeli seçilebilir. Sonraki sürümler kullanım kanıtına göre planlanır. Belirsiz projelerde bütün yatırım için erken kesinlik iddiası yerine karar noktaları oluşturur.

Hiçbir ticari model otomatik olarak en ucuz veya en güvenli değildir. Uygunluk; kapsam olgunluğu, değişim sıklığı, karar kapasitesi ve tarafların risk paylaşımına bağlıdır.

Neden en düşük teklif toplamda en düşük maliyet olmayabilir?

Fiyat farkının nedeni aynı iş için farklı ücret olabileceği gibi, farklı kapsam da olabilir. Düşük teklifte şu kalemler bulunmayabilir:

• gereksinim analizi,
• özel tasarım veya mobil detaylar,
• veri taşıma ve temizleme,
• entegrasyon hata senaryoları,
• güvenlik ve erişilebilirlik doğrulaması,
• gerçekçi test verisi hazırlığı,
• eğitim ve dokümantasyon,
• kaynak kod veya hesap devri,
• yayın sonrası destek,
• üçüncü taraf lisans ve kullanım bedelleri.

Teklifleri yalnızca toplam rakamla değil, teslim-kapsam-varsayım matrisiyle karşılaştırın. Aynı olmayan tekliflerin toplamını doğrudan karşılaştırmak yanıltıcıdır.

Toplam sahip olma maliyetini değerlendirin

İlk geliştirme bütçesi ürünün yaşam döngüsünün yalnızca bir bölümüdür. ABD Government Accountability Office maliyet tahmin rehberi; tahminin amacının tanımlanmasını, yaşam döngüsü maliyetlerinin kapsanmasını, varsayımların belgelenmesini ve risk-belirsizlik analizini güvenilir tahminin parçaları arasında sayar (GAO Cost Estimating and Assessment Guide). Bu rehber Kumsal Ajans fiyatlandırma kuralı değildir; bütçe bileşenlerini görünür kılmak için kullanılan genel bir maliyet planlama ilkesidir.

Değerlendirilecek tekrar eden veya gelecekteki kalemler:

• sunucu/bulut ve trafik,
• alan adı, TLS, e-posta ve depolama,
• üçüncü taraf lisansları ve işlem ücretleri,
• izleme ve yedekleme,
• güvenlik ve bağımlılık güncellemeleri,
• destek ve olay müdahalesi,
• içerik veya yönetim operasyonu,
• yeni tarayıcı/cihaz/servis uyarlamaları,
• yeni modüller ve entegrasyonlar,
• veri dışa aktarma, devir veya başka sisteme geçiş.

Üç veya beş yıllık tablo kullanılabilir; süre bir SEO veya finans kuralı değil, seçenekleri aynı dönem üzerinden karşılaştırma aracıdır. Gelecek tutarlar kesin öngörülemiyorsa varsayım, fiyat değişim mekanizması ve kullanım birimi yazılmalıdır.

Belirsizlik ve risk bütçede nasıl gösterilir?

Belirsizliği gizlemek yerine sınıflandırın:

• doğrulanmış kapsam,
• tahmine dayalı kapsam,
• üçüncü tarafa bağlı,
• teknik araştırma gerektiriyor,
• müşteri verisi/erişimi bekliyor,
• kapsam dışında.

Her belirsizlik için olası etki, doğrulama adımı, sahibi ve karar tarihi belirleyin. Evrensel bir “risk yüzdesi” eklemek yerine belirsizliği yaratan işi çözmek veya senaryolu aralıkla göstermek daha açıklayıcı olabilir.

Örnek senaryolar:

• Temel senaryo: API ve veri doğrulanmış, tanımlı MVP akışları.
• Koşullu senaryo: Eski sistem veri temizliği veya ek yetki kuralı gerekiyor.
• Genişletilmiş senaryo: Yeni entegrasyon, yüksek hacim ya da bağımsız güvenlik testi ekleniyor.

Teklif almadan önce hazırlamanız gereken bilgiler

• iş hedefi ve temel kullanıcı sonucu,
• kullanıcı grupları ve rolleri,
• temel iş akışları ve önemli istisnalar,
• ilk sürüm ve kapsam dışı maddeler,
• mevcut sistem ve veri kaynakları,
• entegrasyonlar ve erişim durumu,
• içerik, tasarım ve marka materyalleri,
• beklenen kullanım ve veri hacmi,
• güvenlik, erişilebilirlik ve uyum ihtiyaçları,
• hedef tarih ve dış bağımlılıklar,
• test ve kabul sahibi,
• yayın, eğitim, devir, bakım ve destek beklentisi,
• bütçe aralığı veya yatırım sınırı açıklanabiliyorsa bu bilgi.

Kapsam yeterince net değilse önce web yazılım ihtiyaç dokümanı ve MVP karar çalışmasını tamamlamak, tekliflerin karşılaştırılabilirliğini artırır.

Web yazılım teklifi kontrol listesi

Teklifi kabul etmeden önce şu soruları yanıtlayın:

• Hedef sonuç ve ilk sürüm açık mı?
• Modül adlarının altında iş akışları tanımlı mı?
• Roller ve yetkiler dahil mi?
• Tasarım, içerik ve revizyon sınırı ne?
• Entegrasyonların veri ve hata kapsamı yazıyor mu?
• Veri taşıma ve temizleme kimin sorumluluğunda?
• Test türleri ve kabul ölçütleri neler?
• Güvenlik, erişilebilirlik ve performans kapsamı belli mi?
• Üçüncü taraf ücretleri ayrılmış mı?
• Yayın, eğitim ve dokümantasyon dahil mi?
• Kod, veri ve hesapların sahipliği nasıl düzenlenmiş?
• Hata düzeltme, bakım ve yeni geliştirme ayrılmış mı?
• Değişiklik talebi nasıl fiyatlanacak?
• Tekrarlanan maliyet ve yenileme koşulları neler?
• Varsayım, bağımlılık ve kapsam dışı maddeler görünür mü?

Bütçeyi tek başına okumayın. Önce hazır ve özel yazılım kararını ve MVP kapsamını doğrulayın; teklif kalemlerini gereksinim dokümanıyla eşleştirin. Entegrasyon planı üçüncü taraf ve hata yönetimi emeğini, güvenlik ve bakım planı ise yayın sonrası yaşam döngüsü sorumluluğunu görünür kılar.

Sonuç

Web yazılım fiyatı, yalnızca yazılacak kodun bedeli değildir. İşin anlaşılması, kullanıcı deneyimi, iş kuralları, veri, entegrasyonlar, kalite doğrulaması, yayın, devir ve ürünün çalışmaya devam etmesi birlikte bütçeyi oluşturur.

Tek bir toplam rakam istemeden önce aynı kapsamı tanımlayın. Teklifleri yedi bütçe bölümünde karşılaştırın, üçüncü taraf ve tekrar eden giderleri ayırın, belirsizlikleri varsayım olarak kaydedin ve ticari modeli kapsamın olgunluğuna göre seçin. Böylece “hangi teklif daha ucuz?” sorusunun yanında “hangi işi, hangi sınır ve yaşam döngüsü sorumluluğuyla satın alıyoruz?” sorusunu da yanıtlayabilirsiniz.