Web Sitesi Teslim Süresi Ne Kadar Olmalı? [Rehber]

Web sitesi teslim süresi, küçük bir landing page için günlerle; içerik, özel akış ve entegrasyon içeren projeler için haftalarla ölçülür. Asıl mesele “kaç günde biter?” sorusuna verilen sayı değil, o sayının hangi kapsam ve sorumluluklara dayandığıdır.

“Tahminen üç hafta” tek başına bir teslim planı değildir. İçeriği kimin sağlayacağı, tasarımın kaç tur revize edileceği, yeni isteklerin nasıl ele alınacağı ve yayına alma sorumluluğunun kimde olduğu belli değilse üç hafta birkaç aya çıkabilir.

Öne Çıkanlar

• Web sitesi teslim süresi, tasarım ve kodlama kadar içerik teslimi ile onay hızına bağlıdır.
• Net kapsamı olmayan projelerde sonradan eklenen her sayfa, özellik ve entegrasyon takvimi değiştirir.
• Sözleşmede hedef tarih, müşteri sorumlulukları ve kapsam dışı taleplerin süreci yer almalıdır.
• “Tahminen” ifadesi yerine, aşamaları ve teslim koşulları yazılı olan bir proje planı gerekir.
• Geciken bir site; reklam, sezon, satış fırsatı ve ekip zamanı açısından gerçek maliyet yaratır.

Web Sitesi Yapım Süreci Hangi Aşamalardan Oluşur?

Bir web sitesi, tek seferde hazırlanıp gönderilen bir dosya değildir. Brief, tasarım, geliştirme, içerik girişi, test ve yayına alma birbirini takip eden aşamalardır.

Süreyi doğru hesaplamak için her aşamanın kime bağlı olduğunu bilmek gerekir. Ajansın geliştirme süresi ile müşterinin içerik hazırlama ve onay süresi aynı şey değildir.

Brief ve kapsamın netleşmesi

İlk adım, sitenin ne yapacağını netleştirmektir. Sayfa sayısı, hedef kullanıcı, içerik türleri, form ihtiyaçları, dil seçenekleri ve varsa entegrasyonlar bu aşamada belirlenir.

Bu aşama aceleye gelirse sorun sonradan çıkar. “Hizmetler sayfası da olsun” ya da “bir teklif hesaplama alanı ekleyelim” gibi istekler geliştirme başladıktan sonra gelirse ilk takvim geçerliliğini yitirir.

Net bir kapsam şu konuları yazılı hale getirir:

• Hangi sayfaların hazırlanacağı
• Her sayfanın temel amacı ve içerik ihtiyacı
• Tasarım onayının nasıl alınacağı
• Form, harita, çok dil, üyelik veya ödeme gibi teknik gereksinimler
• Müşterinin sağlayacağı metin, görsel ve erişimler
• Kapsam dışı taleplerin nasıl fiyatlanacağı ve takvime nasıl ekleneceği

Kapsam belgesinin uzun olması gerekmez. Ancak “kurumsal site yapılacaktır” kadar belirsiz de olmamalıdır.

Tasarım ve onay süreci

Tasarım aşamasında yalnızca sayfanın görünümü değil, kullanıcı akışı da belirlenir. Ziyaretçinin ne göreceği, hangi noktada iletişime geçeceği ve mobilde hangi bilgiyi önce alacağı burada planlanır.

Onay süreci açıkça tanımlanmazsa proje bekler. Tasarım gönderilir, geri bildirim günler sonra gelir, ardından yeni karar vericiler sürece dahil olur. Her tur, yalnızca tasarımı değil geliştirme başlangıcını da geciktirir.

Bu yüzden geri bildirim tek kanaldan ve belirlenen süre içinde gelmelidir. Dağınık WhatsApp mesajları, e-posta zincirleri ve farklı kişilerden gelen çelişkili notlar takvimi korumaz.

Geliştirme ve içerik yerleşimi

Onaylanan tasarım daha sonra teknik olarak geliştirilir. Özel WordPress geliştirme işinde bu aşama, hazır bir temanın rengini değiştirerek bitmez. Sayfa yapısı, performans, mobil davranış ve içerik yönetimi birlikte kurulmalıdır.

İçerik bu aşamadan ayrı düşünülmemelidir. Metinler, ürün bilgileri, ekip fotoğrafları ya da hizmet açıklamaları gecikirse geliştirilmiş sayfalar boş kalır.

İşletme sitelerinde sık görülen durum şudur: Tasarım onaylanır, kod tamamlanır, fakat hakkımızda metni ve hizmet açıklamaları hazır değildir. Site teknik olarak bitmiş görünür, ancak yayına alınacak materyal olmadığı için teslim edilemez.

Test, revizyon ve yayına alma

Yayın öncesi test, projenin sonunda alelacele tamamlanacak bir kontrol listesi değildir. Formlar, mobil ekranlar, tarayıcı uyumu, yönlendirmeler, SSL, sayfa hızı ve temel SEO ayarları kontrol edilir.

Son revizyonlar bu aşamada uygulanır. Ancak test sırasında yeni bir sayfa fikri ya da baştan tasarım değişikliği gelirse bu test değil, kapsam değişikliğidir.

Yayına alma aşamasında domain, hosting ve gerekli hesap erişimlerinin de hazır olması gerekir. Erişim bilgileri eksikse teknik olarak tamamlanan site yine bekler.

Site Türüne Göre Teslim Süresi Değişir

Landing page ile çok sayfalı kurumsal site aynı sürede hazırlanmaz. E-ticarette ürün verileri, kategori yapısı, ödeme, kargo ve sipariş akışları süreyi doğrudan etkiler.

Site türü	Takvimi belirleyen başlıca unsur
Landing page	İçeriğin hazır olması, tasarım onayı, form ve takip kurulumu
Kurumsal tanıtım sitesi	Sayfa sayısı, içerik üretimi, çok dil ve özel modüller
WooCommerce mağazası	Ürün verisi, kategori yapısı, ödeme ve kargo entegrasyonları
Shopify mağazası	Ürün taşınması, tema kapsamı, uygulama seçimi ve analiz kurulumu
Özel entegrasyonlu proje	Harici sistemler, API erişimi, test senaryoları ve veri yapısı

Bir projeyi kısa sürede bitirmek, aşamaları atlamak anlamına gelmemelidir. Mobil test yapılmadan, içerik kontrol edilmeden veya form akışları denenmeden yayına alınan site hızlı teslim edilmiş sayılmaz. Sorun yalnızca teslim sonrasına bırakılmış olur.

Özellikle e-ticarette yanlış kurulan bir ürün yapısı veya eksik ödeme akışı, tasarım revizyonundan çok daha pahalıdır. Bu nedenle WooCommerce e-ticaret ve Shopify site kurulumu projelerinde takvim, yalnızca mağazanın görünümüne göre değil, satış operasyonuna göre planlanmalıdır.

Teslim Süresini Uzatan Beş Yaygın Neden

Web sitesi gecikmelerinin çoğu teknik bir felaketten kaynaklanmaz. Daha sık görülen sorun, başta tanımlanmayan işlerin proje ortasında karara bağlanmasıdır.

1. İçerikler hazır değildir

“Metinleri sonra göndeririz” sözü sık duyulur. Oysa içerik, site kurulduktan sonra eklenecek küçük bir ayrıntı değildir. Sayfa hiyerarşisini, tasarımı ve ziyaretçinin alacağı mesajı doğrudan etkiler.

Logo, hizmet açıklamaları, ekip bilgileri, görseller ve iletişim verileri proje başlamadan toplanmalıdır. Mükemmel metni beklemek yerine, yayın için yeterli ve onaylanmış içerik hazırlamak daha doğrudur.

Temsili bir senaryo düşünün; gerçek bir müşteri değil, tipik bir durumu göstermek için kurgulandı. Bir işletme ana sayfa için kısa bir metin hazırlıyor, ancak hizmet sayfalarını “ileride yazarız” diyerek bırakıyor. Geliştirme tamamlandıktan sonra hizmetlerin kapsamı yeniden tanımlanıyor. Sayfa yapısı, menü ve çağrı alanları yeniden düzenleniyor. İlk bakışta gecikmenin nedeni metin eksikliği gibi görünür; aslında kapsam kararı henüz verilmemiştir.

2. Kapsam sürekli genişler

Kapsamın genişlemesi kötü niyet anlamına gelmez. İşletme siteyi gördükçe yeni fikirler üretir. Sorun, her yeni fikrin ilk teklifin ve ilk teslim tarihinin içine dahil edilmesidir.

Aşağıdaki isteklerin her biri ayrı ayrı değerlendirilmelidir:

• Yeni bir hizmet veya ürün sayfası
• Çok dil desteği
• Özel teklif formu
• Üyelik alanı
• Blog veya kaynak merkezi
• Harici yazılım entegrasyonu
• Ödeme, kargo veya stok akışı

İyi proje yönetimi “hayır” demek değildir. Talebin etkisini açıkça söyler: Bu ekleme yapılabilir, ancak ek geliştirme ve yeni bir teslim tarihi gerekir.

3. Onaylar dağınık ilerler

Tasarım kararı bir kişiden, metin kararı başka bir kişiden, logo kararı üçüncü kişiden geliyorsa proje yönetilemez hale gelir. Herkesin görüşü alınabilir, fakat son onayı verecek kişi belli olmalıdır.

Yazılı geri bildirim, görsel yorumdan daha değerlidir. “Daha kurumsal olsun” yeterli bir revizyon notu değildir. Hangi bölümün değişeceği, sorunun ne olduğu ve beklenen sonucun ne olduğu yazılmalıdır.

Bu yöntem hem müşteri tarafını hem geliştirme tarafını korur. Revizyonun ne olduğu anlaşılır ve aynı konu her turda yeniden açılmaz.

4. Teknik erişimler geç paylaşılır

Domain paneli, hosting erişimi, mevcut site yönetimi, Google hesapları veya ödeme sağlayıcı bilgileri geç verilirse yayına alma süreci uzar. Bunlar projenin son gününde istenecek bilgiler değildir.

Özellikle mevcut bir siteden geçiş yapılacaksa erişim planı erken hazırlanmalıdır. Eski sitenin yönlendirmeleri, iletişim formları ve e-posta düzeni yayın günü çözülecek konular değildir.

5. Teslim tanımı belirsizdir

“Site bitti” ifadesi herkes için aynı anlama gelmeyebilir. Bir taraf tasarımın onaylanmasını yeterli görür. Diğer taraf ise tüm içeriklerin girilmesini, domainin bağlanmasını ve sitenin yayında olmasını bekler.

Bu yüzden sözleşmede teslimin ne anlama geldiği açıkça yazılmalıdır. Örneğin:

• Tasarımların onaylanması
• Geliştirmenin tamamlanması
• İçeriklerin girilmesi
• Testlerin yapılması
• Domain üzerinde yayına alınması

Teslim tarihi tek başına yeterli değildir. Teslimin kapsamı da tanımlanmalıdır.

Sözleşmede Teslim Takvimi Nasıl Yazılmalı?

Teslim tarihi “yaklaşık” denilerek bırakılacak bir satır değildir. Ancak müşteri tarafının yükümlülüklerini yok sayan tek taraflı bir tarih de gerçekçi olmaz.

İyi bir sözleşme, takvimi karşılıklı sorumluluklarla birlikte yazar. Takvim dışında ajans sözleşmesinde bulunması gereken diğer maddeleri de teklif aşamasında netleştirin.

Başlangıç koşulu belirlenmelidir

Takvim hangi gün başlar? İlk ödeme alındığında mı, brief onaylandığında mı, yoksa içerikler teslim edildiğinde mi?

Bu sorunun cevabı yoksa taraflar süreyi farklı tarihlerden başlatır. Proje başlamış görünür, fakat çalışmak için gereken materyal henüz gelmemiştir.

Müşteri sorumlulukları açık olmalıdır

Müşteri tarafının sağlayacağı unsurlar ayrı bir maddede yer almalıdır. Bunlar genellikle şunlardır:

• Logo ve marka dosyaları
• Sayfa metinleri
• Görseller ve kullanım izinleri
• Domain ve hosting erişimleri
• Gerekli üçüncü taraf hesapları
• Yazılı tasarım ve içerik onayları

Bu materyaller gecikirse teslim tarihinin nasıl güncelleneceği de önceden yazılmalıdır. Böylece gecikme sonradan kişisel bir tartışmaya dönüşmez.

Revizyon sınırı ve yöntemi tanımlanmalıdır

Revizyon hakkı vardır, ancak “istediğimiz kadar değişiklik yaparız” şeklinde açık uçlu olmamalıdır. Tasarım onayından sonra yapılan yön değişiklikleri ile küçük metin düzeltmeleri aynı kategoride değildir.

Kapsamı baştan netleştiren bir ajans revizyondan kaçmaz. Yalnızca revizyonun hangi aşamada, hangi kapsamda ve ne kadar sürede ele alınacağını belirler.

Kapsam dışı talepler için süreç kurulmalıdır

Proje sırasında yeni fikirlerin çıkması normaldir. Yeni bir talep geldiğinde yapılacak iş, bunu görünmeden takvime sıkıştırmak değildir.

Talep yazılı olarak alınır. Teknik ve zaman etkisi değerlendirilir. Ardından yeni iş için ayrı onay, gerekiyorsa yeni bir takvim oluşturulur. Bu yöntem bütçe ve teslim tarafındaki sürprizleri azaltır.

Teslim tarihi vaat değildir. Kapsam, onay ve erişim koşullarıyla desteklenmiş proje planıdır.

Bu yaklaşım, özel WordPress geliştirme işinde de temel farkı yaratır. Siteyi kuracak kişinin baştan kapsamı anlaması gerekir. İş, satış aşamasında başka; geliştirme aşamasında başka birine devredildiğinde belirsizlik büyür.

Projeyi Geciktirmeden Başlatmak İçin Hazırlık Listesi

Müşteri tarafındaki hazırlık, teslim süresini kontrol etmenin en pratik yoludur. Proje başlamadan önce aşağıdaki listeyi tamamlayın.

• Logo dosyalarını hazırlayın. Mümkünse vektör formatı, değilse yüksek çözünürlüklü dosyalar sağlayın.
• Sayfa listesini onaylayın. Ana sayfa, hizmetler, hakkımızda, iletişim ve varsa diğer sayfalar baştan belli olsun.
• Metinleri toplayın. Mükemmel olmadıkları için bekletmeyin; eksik olan alanları açıkça işaretleyin.
• Görsel kaynaklarını belirleyin. Kendi fotoğraflarınız, ürün görselleriniz veya kullanılabilecek lisanslı kaynaklar hazır olsun.
• Karar vericiyi belirleyin. Son tasarım ve içerik onayını kimin vereceği netleşsin.
• Teknik erişimleri kontrol edin. Domain, hosting, eski site ve gerekli hesaplara erişim baştan doğrulansın.
• Önceliği söyleyin. Sezon, kampanya, fuar veya reklam başlangıcı gibi sabit bir tarih varsa ilk briefte paylaşın.

Bir başka temsili senaryo: Bir butik konaklama işletmesi, yeni sezon öncesinde sitesini yenilemek istiyor, ancak oda fotoğraflarını ve fiyat bilgisini son haftaya bırakıyor. Tasarım tamamlanıyor, fakat oda sayfaları gerçek içerik olmadan yayına alınamıyor. Sezon tarihi değişmez; değişen yalnızca sitenin hazır olacağı tarihtir. Takvim baskısı teknik ekipten değil, geç gelen materyallerden kaynaklanır.

Geciken Web Sitesinin Maliyeti Sadece Zaman Değildir

Web sitesi gecikmesi can sıkıcı bir operasyon sorunu gibi görünür. Ancak çoğu zaman satış ve pazarlama planını da durdurur.

Reklam hesabı hazır olabilir, sosyal medya kampanyası planlanmış olabilir, satış ekibi yeni hizmeti duyurmaya başlamış olabilir. Fakat ziyaretçinin gideceği sayfa yoksa bu çalışmaların büyük bölümü boşa gider.

Sezon ve kampanya dönemleri kaçabilir

Sezonluk işletmeler için teslim tarihi özellikle önemlidir. Tatil dönemi, kampanya haftası veya ürün lansmanı gibi sabit tarihlerin telafisi yoktur.

Bir başka temsili senaryo: Bir e-ticaret girişimi reklam kampanyasını açıyor, ancak mağazadaki ürün sayfaları ve ödeme akışı henüz yayına hazır değil. Reklam çalışıyor, fakat ziyaretçi güven veren bir satın alma akışı bulamıyor. Sorun reklam performansı değildir. Trafiğin geldiği mağaza hazır değildir.

Ekip zamanı tekrar tekrar harcanır

Belirsiz bir proje yalnızca müşteriyi bekletmez. İşletme tarafında da sürekli takip ihtiyacı yaratır: “Ne durumda?”, “Ne zaman biter?”, “Bu değişiklik yapıldı mı?” soruları operasyonel yük oluşturur.

Bu yüzden açık bir takvim ve tek iletişim noktası gerekir. Her hafta yeni bir durum sorusu sormak yerine, hangi aşamanın tamamlandığı ve sırada ne olduğu görülebilmelidir.

Takvimi belirsiz bir teklif aldıysanız, işe başlamadan kapsamı ve teslim koşullarını yazılı isteyin. Projenizin ihtiyaçlarını anlatmak için bize ulaşın; kapsamı e-postayla netleştirelim.

Sık Sorulan Sorular

Web sitesi kaç günde yapılır?

Süre, sitenin türüne ve kapsamına göre değişir. Basit bir landing page daha kısa sürede tamamlanabilir. Çok sayfalı kurumsal siteler, e-ticaret mağazaları ve özel entegrasyonlar daha uzun planlama ister.

Sayfa sayısı, içerik hazırlığı, tasarım onayı ve teknik gereksinimler görülmeden doğru bir süre verilemez.

Web sitesi teslim süresini en çok ne uzatır?

En sık nedenler içeriklerin geç gelmesi, onayların uzaması, proje sırasında kapsamın büyümesi ve gerekli teknik erişimlerin paylaşılmamasıdır.

Kodlama süresi önemlidir, ancak tek belirleyici değildir. Proje yönetimi zayıfsa en basit iş bile bekler.

Web sitesi bir haftada hazırlanabilir mi?

Sınırlı kapsamlı bir landing page için bu mümkün olabilir. Fakat çok sayfalı bir kurumsal site veya e-ticaret mağazası için bir hafta, test ve içerik kalitesini riske atabilir.

Kısa teslim vaadinin hangi işleri dışarıda bıraktığını mutlaka sorun. Mobil kontrol, form testi, içerik girişi ve yayına alma dahil mi, netleştirin.

Teslim tarihi sözleşmede yer almalı mı?

Evet. Teslim tarihiyle birlikte başlangıç koşulları, müşteri sorumlulukları, revizyon yöntemi ve kapsam dışı taleplerin süreci de yazılmalıdır.

Yalnızca tarih yazmak yeterli değildir. Tarihin hangi koşullarda geçerli olduğu da belirtilmelidir.

Kapsam değişirse teslim tarihi değişir mi?

Yeni sayfa, yeni özellik veya entegrasyon gibi kapsam değişiklikleri süreyi etkileyebilir. Bu normaldir.

Önemli olan, değişikliğin sözlü olarak araya sıkıştırılmaması ve zaman etkisinin yazılı olarak onaylanmasıdır.

Ajans seçerken teslim süresi konusunda ne sormalıyım?

Şu soruları sorun:

• Takvim hangi tarihte başlıyor?
• Hangi teslimatlar hangi aşamada bekleniyor?
• İçerikleri kim hazırlıyor?
• Kaç revizyon turu dahil?
• Yeni istekler nasıl ele alınıyor?
• Yayına alma, domain bağlantısı ve testler kapsamda mı?
• Proje boyunca tek iletişim noktası kim?

Bu sorulara açık cevap verilmiyorsa verilen teslim tarihi de açık değildir.

Teslim Tarihi, Net Kapsamla Anlam Kazanır

Web sitesi teslim süresi yalnızca ajansın hızını göstermez. Projenin ne kadar iyi tanımlandığını da gösterir. Kapsam belirsizse, içerikler hazır değilse ve onay sürecinin sorumlusu yoksa hiçbir tarih güvenilir değildir.

İyi bir proje planı basittir: Ne yapılacağı yazılır, kimden ne beklendiği bellidir, yeni isteklerin etkisi saklanmaz ve yayın kriterleri baştan tanımlanır. Böylece takvim, karşılıklı bir çalışma planına dönüşür.