Web Tasarım Fiyatları Nasıl Belirlenir? 12 Maliyet Kalemi

Web tasarım fiyatları tek bir sayfa sayısı veya paket adına göre güvenilir biçimde belirlenemez. Projenin fiyatı; araştırma ve planlama, benzersiz şablonlar, içerik, işlevler, entegrasyonlar, veri taşıma, çoklu dil, erişilebilirlik, test, yayın ve teslim kapsamlarının gerektirdiği emek ile doğrudan giderlerin birlikte hesaplanmasıyla oluşur.

Bu rehber güncelliğini kısa sürede kaybedecek sabit bir fiyat listesi vermek yerine, bir teklifin nasıl oluştuğunu ve iki teklif arasındaki farkın nasıl açıklanacağını gösterir. Böylece düşük görünen bir teklifin gerçekten daha avantajlı mı, yoksa yalnızca daha dar kapsamlı mı olduğunu anlayabilirsiniz.

Kısa Cevap: Web Tasarım Fiyatını Neler Belirler?

1. İhtiyaç analizi ve proje yönetimi
2. Benzersiz sayfa şablonları ve tasarım sistemi
3. İçerik üretimi, görseller ve veri girişi
4. Yönetim paneli ve kullanıcı rolleri
5. Formlar, üyelik, ödeme ve özel işlevler
6. CRM, ERP, harita, e-posta ve diğer entegrasyonlar
7. Türkçe–İngilizce gibi çoklu dil kapsamı
8. Mevcut siteden içerik, veri ve URL taşıma
9. Erişilebilirlik, performans, güvenlik ve teknik SEO kontrolleri
10. Tarayıcı, cihaz ve kullanıcı kabul testleri
11. Canlı geçiş, eğitim, dokümantasyon ve devir
12. Garanti, bakım ve destek sınırları

Fiyat karşılaştırmasının anlamlı olması için her teklif bu kalemlerin hangisini, hangi miktarda ve hangi kabul koşuluyla içerdiğini göstermelidir.

Web Tasarım Fiyatı ile Web Sitesinin Toplam Maliyeti Aynı Şey Değildir

Web tasarım fiyatı genellikle ilk projenin analiz, tasarım, geliştirme, içerik girişi, test ve yayın teslimini ifade eder. Toplam sahip olma maliyeti ise alan adı, barındırma, lisans, kullanım bazlı servisler, bakım, içerik operasyonu ve sonraki geliştirmeleri daha uzun bir dönemde değerlendirir.

Bu yazı ilk teklifin kapsamına odaklanır. Canlıya çıktıktan sonraki giderleri planlamak için web sitesinin üç yıllık toplam maliyet tablosunu kullanabilirsiniz. İki kavramı ayırmak, ilk proje ücretine dâhil olmayan yenilemeleri sonradan sürpriz olarak görmenizi engeller.

1. İhtiyaç Analizi ve Proje Yönetimi

Belirsiz bir talep, doğru fiyatlandırılamaz. Proje başında iş hedefleri, hedef kullanıcılar, sayfalar, içerik, işlevler, entegrasyonlar, sorumluluklar ve kabul kriterleri tanımlanır. Karmaşık bir projede paydaş görüşmeleri, mevcut sistem incelemesi, veri ve içerik envanteri, teknik risk çalışması ve aşamalı planlama gerekir.

Proje yönetimi yalnız toplantı yapmak değildir. Kararların kayıt altına alınması, bağımlılıkların izlenmesi, onayların alınması, kapsam değişikliklerinin değerlendirilmesi ve tasarım–yazılım–içerik ekiplerinin aynı teslim planında buluşması da emek gerektirir. Karşılaştırılabilir teklif için önce web sitesi ihtiyaç dokümanını hazırlayın.

2. Sayfa Sayısından Önce Benzersiz Şablon Sayısını Hesaplayın

Yüz ürün sayfası aynı şablon ve veri yapısıyla üretilebiliyorsa tasarım yükü yüz ayrı özgün sayfayla aynı değildir. Ana sayfa, hizmet liste ve detay, ürün liste ve detay, proje, ekip, blog, iletişim ve kampanya sayfası farklı bilgi hiyerarşileri gerektirebilir. Bu nedenle tekliflerde toplam URL sayısının yanında benzersiz şablon sayısı da belirtilmelidir.

Her şablon için masaüstü görünümden fazlası düşünülür: mobil davranış, menüler, boş ve hata durumları, uzun başlıklar, farklı görsel oranları, bileşen varyasyonları ve erişilebilir etkileşimler. Tasarım sistemi hazırlanıyorsa renk ve yazı tipinin yanında buton, form, kart, tablo ve bildirim bileşenlerinin durumları da tanımlanır.

3. Hazır Tema, Özelleştirilmiş Altyapı ve Projeye Özel Geliştirme

Hazır bir tema, standart ihtiyaçlarda başlangıç süresini azaltabilir. Ancak marka, içerik yapısı veya iş akışı temanın sınırlarını aşıyorsa yoğun özelleştirme, performans düzeltmesi ve bakım bağımlılığı doğabilir. Projeye özel geliştirme daha fazla analiz ve üretim gerektirebilir; buna karşılık gereksiz özellikleri taşımadan ihtiyaca göre modellenebilir.

Burada doğru veya yanlış tek bir yöntem yoktur. Teklifte kullanılan yaklaşım, lisanslar, güncellenebilirlik, geliştirici bağımlılığı, kaynak kod teslimi ve ileride değişiklik yapma koşulları açıklanmalıdır. Aynı “kurumsal site” etiketi altında iki farklı teknik yaklaşımın fiyatı bu nedenle karşılaştırılamayabilir.

4. İçerik Üretimi ve Veri Girişi

Metinleri, çevirileri, fotoğrafları ve ürün verilerini kimin hazırlayacağı fiyatı belirler. Ajans; konu araştırması, uzman görüşmesi, metin yazımı, editörlük, fotoğraf çekimi, görsel lisansı, illüstrasyon, video veya veri düzenleme üstleniyorsa bunlar ayrı iş kalemleridir.

“İçerikler müşteri tarafından verilecek” maddesi de teslim biçimini açıklamalıdır. Eksik başlıklar, farklı ölçülerde görseller, yinelenen ürün kayıtları veya onaysız çeviriler proje sırasında ek düzenleme yaratır. Kaç sayfa ve kaydın girileceği, hangi alanların zorunlu olduğu, revize ve onay sayısı teklif öncesinde yazılmalıdır.

5. İşlevler, Kullanıcı Rolleri ve Yönetim Paneli

Bir iletişim formu ile üyelik, yetki, ödeme, rezervasyon veya bayi sipariş sistemi aynı kapsamda değildir. İşlevin ana akışı kadar hata, iptal, yetkisiz erişim, bildirim, raporlama ve yönetim adımları da geliştirilip test edilir.

Yönetim paneli fiyatı yalnız “panel var mı?” sorusuyla belirlenmez. Kaç kullanıcı rolü bulunacağı, hangi içeriği kimin göreceği veya değiştireceği, toplu işlemler, içe/dışa aktarma, onay akışı, sürüm geçmişi ve rapor gereksinimleri kapsamı değiştirir. Kullanılmayan karmaşık panel özellikleri eklemek de, gerekli yetki modelini atlamak da doğru maliyet planı değildir.

6. Entegrasyonlar ve Üçüncü Taraf Servisleri

CRM, ERP, ödeme, kargo, harita, e-posta, mesajlaşma veya kimlik doğrulama entegrasyonunda yalnız bağlantı düğmesi yapılmaz. API erişimi, veri alanları, yetkilendirme, hata ve tekrar deneme davranışı, test ortamı, hız limitleri ve sorumluluklar incelenir.

Üçüncü taraf servislerin kurulum emeği ile lisans veya kullanım bedeli ayrı gösterilmelidir. Hesabın kimin adına açılacağı, faturayı kimin ödeyeceği ve servis değiştiğinde ne yapılacağı da teklifte yer almalıdır. Belirsiz veya belgelenmemiş bir eski sistemle bağlantı kurulacaksa teknik keşif ya da küçük bir doğrulama çalışması fiyatlandırmadan önce gerekebilir.

7. Çoklu Dil Gerçekte Neleri Çoğaltır?

İkinci dil yalnız menüye dil düğmesi eklemek değildir. Çeviri, editörlük, sayfa eşleştirme, kategori ve form seçenekleri, URL'ler, SEO alanları, görsellerin alt metinleri, e-posta şablonları ve dil değiştirici testleri gerekir. Her dilde tüm sayfalar bulunmayacaksa eşleşme ve yönlendirme kuralları ayrıca tasarlanır.

Türkçe ve İngilizce içerikler bağımsız kayıtlar olarak yönetilirken bağlantılı kalmalıdır. Canonical, hreflang, sitemap ve dil geçişleri iki yönde kontrol edilir. İçerik miktarı ve onay akışı arttığı için çoklu dil kapsamı yalnız geliştirmeyi değil, içerik ve test yükünü de etkiler.

8. Mevcut Sitenin Taşınması ve URL Koruması

Yenileme projesinde eski sitedeki sayfalar, bloglar, ürünler, medya, kullanıcılar veya formlar incelenir. Verinin biçimi, kalitesi, tekrarları ve eksik alanları otomatik taşımanın mümkün olup olmadığını belirler. Kaynak kod, veri tabanı veya güncel yedek eksikse taşıma riski artar ve önce erişimlerin tamamlanması gerekir.

Adresler değişirse eski URL'ler ilgili yeni sayfalara 301 ile eşlenmelidir. Türkçe ve İngilizce adreslerin yönlendirme listeleri ayrı hazırlanır. Taşıma fiyatında envanter çıkarma, dönüştürme, deneme aktarımı, yönlendirme, doğrulama ve geri alma planının bulunup bulunmadığını sorun.

9. Erişilebilirlik, Performans, Güvenlik ve Teknik SEO

Bu başlıklar tek bir “uyumlu” etiketiyle geçiştirilmemelidir. Erişilebilirlik için renk karşıtlığı, klavye kullanımı, odak, başlıklar, form etiketleri ve hata mesajları tasarım ve test kapsamına girer. W3C WCAG 2.2, erişilebilir web içeriği için test edilebilir başarı ölçütleri tanımlar. (WCAG 2.2)

Performans çalışması; görseller, yazı tipleri, önbellek, sunucu yanıtı, JavaScript ve üçüncü taraf kodların incelenmesini gerektirebilir. Google'ın Core Web Vitals ölçüleri LCP, INP ve CLS'dir; gerçek kullanıcı koşullarındaki 75. yüzdelik dilim değerlendirmesi önerilir. (Web Vitals)

Güvenlik kapsamı üyelik, veri, ödeme ve yönetim işlevlerine göre değişir. OWASP ASVS, web uygulaması güvenlik gereksinimlerini ve doğrulama seviyelerini yapılandırmak için kullanılabilir. (OWASP ASVS) Teknik SEO tarafında ise taranabilir yapı, meta alanları, canonical, yönlendirmeler, sitemap ve yapılandırılmış veri sorumluluğu belirtilmelidir.

10. Test, Yayın, Eğitim ve Devir

Test kapsamı; desteklenecek cihaz ve tarayıcıları, kullanıcı rollerini, formları, entegrasyonları, içerik kontrolünü, performansı ve kullanıcı kabulünü açıklamalıdır. Hata önem sınıfları, düzeltme süreci ve canlıya çıkış koşulu tanımlanmazsa tekliflerin kalite kapsamı eşit değildir.

Yayın sırasında DNS, SSL, sunucu, e-posta, analiz, yönlendirme ve yedekler kontrol edilir. Teslimde kaynak kod, veri tabanı, medya, hesap erişimleri, lisans listesi, kurulum dokümanı ve yönetim eğitimi bulunmalıdır. Eski sağlayıcıdan geçişte kısa paralel çalışma ve müşteri onaylı kesin geçiş ayrıca planlanabilir.

11. Revizyon, Kapsam Değişikliği ve Risk Payı

Revizyon, kararlaştırılan teslimatın geri bildirimle düzeltilmesidir; yeni sayfa türü, yeni rol veya entegrasyon eklemek kapsam değişikliğidir. Teklifte tasarım onay aşamaları, geri bildirim süresi, revize turu ve değişiklik talebinin nasıl fiyatlandırılacağı yazılmalıdır.

Henüz belgelenmemiş entegrasyon, belirsiz veri kalitesi veya bekleyen içerik gibi riskler tahmini etkiler. Bunlar gizli bir ek ücret yerine varsayım, hariç madde, keşif aşaması veya kontrollü risk payı olarak görünür kılınmalıdır.

Web Tasarım Teklifi Hesaplama Şablonu

Aşağıdaki tutarsız çalışma tablosu fiyat teklifi değildir; adayların aynı kapsamı hesaplayıp hesaplamadığını kontrol etmek için kullanılan özgün bir çerçevedir.

Her satır için miktar, teslimat, sorumlu ve kabul kriteri yazılmadan yalnız toplam rakamları karşılaştırmayın.

Teklifleri Karşılaştırırken Sorulacak 8 Soru

1. Teklif hangi ihtiyaç dokümanına ve varsayımlara dayanıyor?
2. Toplam sayfa değil, kaç benzersiz şablon ve bileşen tasarlanacak?
3. İçerik, çeviri, görsel ve veri girişini kim yapacak?
4. Entegrasyonların kapsamı ve üçüncü taraf ücretleri ayrı mı?
5. Taşıma, URL envanteri ve TR/EN 301 yönlendirmeleri dâhil mi?
6. Test ve kabul kriterleri ölçülebilir mi?
7. Kaynak kod, veri, hesaplar ve dokümantasyon nasıl teslim edilecek?
8. Garanti, bakım, destek ve yeni geliştirme nasıl ayrılıyor?

Farklı teklifleri daha ayrıntılı puanlamak için web sitesi teklifi karşılaştırma puan kartını kullanın.

Sonuç

Web tasarım fiyatını anlamanın en güvenilir yolu, tek bir piyasa rakamı aramak değil; projenizi ölçülebilir iş paketlerine ayırmaktır. Benzersiz şablonlar, içerik, roller, işlevler, entegrasyonlar, diller, taşıma, kalite ve devir tanımlandığında teklifler gerçek anlamda karşılaştırılabilir.

Sabit fiyat listesi yerine ihtiyaç dokümanı hazırlayın, miktarları ve varsayımları yazın, kabul kriterlerini belirleyin. İlk proje fiyatını uzun vadeli işletme maliyetinden ayırın ve kapsam değişikliklerinin nasıl yönetileceğini sözleşmeden önce netleştirin.