Kurumsal Web Sitesi Maliyeti Neye Göre Değişir?

Web sitesi teklifi isteyen bir işletme çoğu zaman birbirinden çok farklı üç rakamla karşılaşır. Bu fark genellikle firmaların kâr beklentisinden değil, tekliflerin farklı işleri tarif etmesinden kaynaklanır. Aşağıda fiyatı gerçekten belirleyen kalemleri ve iki teklifi doğru karşılaştırmanın yolunu anlatıyoruz.

Kurumsal web sitesi fiyatı neden tek bir rakamla söylenemez?

Çünkü "kurumsal web sitesi" bir ürün adı değil, bir proje tarifidir. Beş sayfalık bir tanıtım sitesi ile çok dilli, insan kaynakları başvurusu alan, bayi girişi olan ve ERP ile konuşan bir site aynı cümleyle isimlendirilir ama aynı iş değildir.

Bu yüzden ciddi bir teklif, rakamdan önce kapsamı yazar: kaç şablon tasarlanacak, kaç sayfa üretilecek, içeriği kim hazırlayacak, hangi sistemlere bağlanılacak, kaç revizyon turu var. Kapsam netleşmeden verilen rakam tahmin, netleştikten sonra verilen rakam tekliftir.

Fiyatı belirleyen ana kalemler neler?

Bir web sitesi projesinde bütçeyi oluşturan altı kalem vardır. Hangisinin ağır bastığı projeden projeye değişir.

Sayfa sayısı maliyeti ne kadar etkiler?

Sayfa sayısı sanıldığı kadar belirleyici değildir; asıl belirleyici farklı şablon sayısıdır. Aynı düzende kurulmuş yirmi hizmet sayfası, birbirinden tamamen farklı beş sayfadan daha ucuza mal olur. Çünkü tasarım ve geliştirme emeği şablon başına harcanır, sayfa başına değil.

Tipik bir kurumsal sitede şu şablonlar bulunur: ana sayfa, hizmet listesi, hizmet detayı, kurumsal sayfa, referans listesi, referans detayı, blog listesi, blog detayı, iletişim. Bu dokuz şablon üzerine yüzlerce sayfa üretilebilir. Teklif alırken "kaç sayfa" yerine "kaç farklı şablon" sorusunu sormak, karşılaştırmayı çok daha anlamlı hâle getirir.

Özel tasarım ile hazır tema arasındaki fark bütçeye nasıl yansır?

Hazır tema, tasarım ve önyüz geliştirme kalemlerinin büyük bölümünü ortadan kaldırır. Buna karşılık temayı markaya uyarlamak, gereksiz özelliklerini temizlemek ve performans sorunlarını gidermek yeni bir emek kalemi yaratır. Ağır bir çok amaçlı temanın hız düzeltmesi, bazen sıfırdan geliştirmeden uzun sürer.

Pratik ayrım şu: markanın görsel dili henüz oturmamışsa ve sitenin görevi öncelikle var olmaksa hazır tema mantıklıdır. Sitenin kendisi satış aracıysa, rakiplerden ayrışması gerekiyorsa ve uzun yıllar üzerine geliştirme yapılacaksa özel tasarım toplamda daha ekonomiktir.

Entegrasyonlar neden ayrı bir kalem olarak yazılır?

Çünkü entegrasyonun maliyeti sizin sisteminizden değil, karşı sistemin durumundan doğar. Belgelenmiş, kararlı bir API sunan bir muhasebe programına bağlanmak birkaç günlük iştir. Belgesi olmayan, yalnızca dosya aktarımıyla veri veren eski bir sisteme bağlanmak haftalar sürebilir.

Bu nedenle teklif aşamasında entegrasyon için üç bilgi istenir: hangi sistem, hangi yöntem (REST API, XML, CSV, veritabanı görünümü) ve hangi yönde veri akacağı. Bu üç bilgi netleşmeden entegrasyona verilen rakam gerçekçi olmaz. Sağlıklı bir yaklaşım, entegrasyonu ayrı bir kalem olarak, gerekirse keşif çalışmasından sonra fiyatlamaktır.

İçerik üretimi kimin işi ve neden bu kadar önemli?

Projelerde gecikmenin en yaygın sebebi tasarım ya da kod değil, içeriktir. Tasarım onaylanır, şablonlar hazır olur ve proje "metinler bekleniyor" durumunda haftalarca durur.

İçerik üretimi teklifin içinde olduğunda maliyet artar ama takvim öngörülebilir olur. Kurum kendi üreteceğini söylediğinde maliyet düşer, buna karşılık sözleşmeye içerik teslim tarihlerinin ve gecikme durumunda ne olacağının yazılması gerekir. Fotoğraf konusu da benzerdir: stok görsellerle kurulan bir kurumsal site, kendi tesisinin ve ekibinin fotoğraflarıyla kurulan bir siteyle aynı etkiyi yapmaz.

Revizyon turları sözleşmede neden yazmalı?

"Memnun kalana kadar revizyon" cümlesi kulağa iyi gelir, pratikte iki tarafı da yıpratır. Revizyonun sınırsız olduğu projelerde karar verme süreci uzar, teslim tarihi kayar ve ajans bunu bir sonraki teklife risk primi olarak yansıtır.

Çalıştığımız yöntem şudur: tasarım aşamasında iki revizyon turu, geliştirme aşamasında bir düzeltme turu tanımlanır. Her turda geri bildirimler tek seferde ve tek kanaldan toplanır. Tur sayısı aşıldığında ek çalışma saat bazında fiyatlanır ve önceden bilinir. Bu yapı hem takvimi hem bütçeyi korur.

Yayın sonrası hangi maliyetler devam eder?

Proje bedeli tek seferliktir; site ise yaşayan bir sistemdir. Yıllık olarak devam eden kalemler şunlardır:

• Alan adı ve sunucu: Trafiğe ve gereken kaynağa göre değişir. Paylaşımlı bir paketle sanal sunucu arasındaki fark bütçede hissedilir.
• SSL sertifikası: Çoğu durumda ücretsiz bir sertifika yeterlidir; kurumsal doğrulama gerektiren durumlar istisnadır.
• Bakım ve güncelleme: Sistem ve eklenti güncellemeleri, yedekleme, güvenlik izleme.
• İçerik güncellemesi: Yeni hizmet, yeni referans, blog yazıları.
• Lisanslar: Kullanılan eklenti, font veya harita servisi lisansları.

Bu kalemler teklifte görünmediğinde proje ucuz görünür, ilk yılın sonunda toplam maliyet beklenenin üzerine çıkar. Teklif alırken birinci yılın toplam sahip olma maliyetini sormak doğru bir alışkanlıktır.

Tipik bir bütçe dağılımı nasıl görünür?

Aşağıdaki dağılım, içeriği kurumun hazırladığı, orta ölçekli ve özel tasarımlı bir kurumsal site projesinde emeğin nasıl bölündüğünü gösterir. Oranlar projeye göre değişir; amacı, hangi kalemin ne kadar ağırlık taşıdığını görünür kılmaktır.

Dikkat edilecek nokta şu: tasarım ve önyüz birlikte bütçenin yarısından fazlasını oluşturur. "Tasarımı biz seçelim, siz sadece kodlayın" yaklaşımı bu yüzden maliyeti gerçekten düşürür ama sonucun sorumluluğunu da paylaştırır.

İki teklifi doğru karşılaştırmak için ne sorulmalı?

Rakamları yan yana koymadan önce şu soruların yanıtını yazılı isteyin:

1. Kaç farklı şablon tasarlanacak ve kaç sayfa üretilecek?
2. Tasarım özgün mü, hazır tema uyarlaması mı? Tema lisansı kime ait?
3. Metin ve görsel içerik kimin sorumluluğunda?
4. Kaç revizyon turu var, tur aşıldığında ne oluyor?
5. Hangi entegrasyonlar dâhil, hangileri opsiyonel?
6. Hız ve erişilebilirlik için hangi ölçütler taahhüt ediliyor?
7. Yayından sonra kaç ay hata düzeltme desteği var?
8. Kaynak kodu, tasarım dosyaları ve panel yönetimi kimde kalıyor?

Son madde çoğu zaman atlanır ve en pahalıya mal olan madde odur. Tasarım dosyaları ve kaynak kodu size devredilmiyorsa, ilerideki her değişiklik için aynı firmaya bağımlı kalırsınız. Bu bağımlılığın bedeli, ilk teklifteki farkı birkaç yılda fazlasıyla kapatır.

Proje süresi bütçeyi nasıl etkiler?

Takvim ile bütçe aynı şeyin iki yüzüdür. Orta ölçekli bir kurumsal site tipik olarak beş ile sekiz hafta arasında sürer ve bu sürenin önemli bir bölümü tasarım ile onay döngülerine gider. Süreyi kısaltmak isteyen projelerde maliyet artar, çünkü aynı iş daha fazla kişiyle paralel yürütülür ve paralel çalışma koordinasyon yükü doğurur.

Takvimi uzatan asıl etken ise beklemedir: onay bekleyen tasarım, gelmeyen içerik, cevabı alınamayan bir entegrasyon sorusu. Bu bekleme süreleri sözleşmede taraflara açıkça bağlandığında hem takvim korunur hem de gecikmenin kime ait olduğu tartışma konusu olmaz. Pratik bir yöntem, geri bildirim için sabit bir süre tanımlamaktır: teslimden sonra beş iş günü içinde toplu geri bildirim, süre dolduğunda onaylanmış sayılma.

Bütçeyi kontrol altında tutmanın pratik yolu

Bütçeyi büyüten şey genellikle başlangıçtaki kapsam değil, yol boyunca eklenen isteklerdir. Bunu önlemenin işe yarayan yolu, projeyi iki aşamaya bölmektir: yayına çıkmak için gerekli olan çekirdek kapsam ve yayından sonra ekleneceklere ait bir liste. Çekirdek kapsam yayına çıktığında elinizde çalışan bir site olur; ikinci listedeki maddeleri ise gerçek kullanım verisine bakarak önceliklendirirsiniz.

Bu yaklaşımın iki faydası vardır. Birincisi, yayına çıkış tarihi kaymaz. İkincisi, ikinci listedeki maddelerin bir bölümünün aslında gerekmediğini görürsünüz; gerçek ziyaretçi davranışı, toplantı masasındaki varsayımlardan daha iyi bir önceliklendirme yapar.