Web Tasarım Sözleşmesinde Hangi Maddeler Olmalı? İmza Öncesi Kontrol Listesi

Bir web projesine başlamadan önce imzaladığınız metin, işin sonunda kimin neyi sahiplendiğini belirler. Bu rehberde web tasarım sözleşmesi hazırlarken ya da size gönderilen taslağı okurken hangi maddelere bakmanız gerektiğini, sahada en sık gördüğümüz boşluklarla birlikte anlatıyoruz. Not: Bu yazı hukuki danışmanlık değildir; imzadan önce metni mutlaka bir avukata okutun.

Web tasarım sözleşmesi nedir ve neden imzadan önce okumalısınız?

Web tasarım sözleşmesi, bir işletme ile tasarım ekibi arasında kapsamı, teslim takvimini, ödeme aşamalarını, fikri mülkiyeti, hesap sahipliğini, garanti süresini ve fesih koşullarını yazılı hale getiren anlaşmadır. Amacı iki tarafın beklentisini proje başlamadan aynı sayfaya getirmek ve sonradan çıkacak anlaşmazlığı önlemektir.

Sözlü anlaşmayla başlayan projelerde sorun genellikle teslimden sonra çıkar. Örneğin işletme sahibi alan adını kendi malı sanar, oysa kayıt ajansın hesabındadır. Ya da ekip üç revizyon hakkı verdiğini sanır, müşteri ise sınırsız düzeltme beklemektedir. Bu yüzden metni imzadan önce satır satır okumanızı öneriyoruz.

Ayrıca sözleşme yalnızca bir güvence belgesi değildir; aynı zamanda projenin yol haritasıdır. Net bir metin, kimin hangi gün neyi teslim edeceğini netleştirir ve böylece iki taraf da işi rahatça planlar. Biz de web tasarım hizmetimizde her projeye bu maddeleri tek tek konuşarak başlıyoruz.

Teklif, brief ve sözleşme arasındaki fark nedir?

Bu üç belgeyi pek çok kişi karıştırıyor, ama her biri farklı bir işi görür. Brief, sizin ne istediğinizi anlatan girdidir; teklif, ekibin bu isteğe karşı önerdiği çözüm ve bedeldir; sözleşme ise ikisinin üzerine kurulan bağlayıcı anlaşmadır. Dolayısıyla sözleşme, teklifteki kapsamı ek olarak içine almalı ya da açıkça ona atıf yapmalıdır.

Brief hazırlığını web projesi brief rehberimizde, teklifleri karşılaştırmayı ise web tasarım teklifi nasıl değerlendirilir rehberinde ayrıntılı anlattık. Burada yalnızca sözleşme maddelerine odaklanıyoruz.

Web tasarım sözleşmesinde kapsam maddesine neler girmeli?

Kapsam, web tasarım sözleşmesi içindeki en önemli maddedir; çünkü diğer bütün maddeler ona dayanır. Belirsiz bir kapsam, ödeme ve takvim tartışmasının da kaynağı olur. Bu nedenle sayfa sayısını, dil sayısını ve işlevleri tek tek listeleyen bir ek isteyin.

• Sayfa listesi: ana sayfa, hizmet sayfaları, iletişim, blog şablonu gibi.
• Dil sayısı ve çeviriyi kimin yapacağı.
• İşlevler: iletişim formu, rezervasyon, ödeme, üyelik, arama.
• Yönetim paneli ve içeriği kendiniz güncelleyip güncelleyemeyeceğiniz.
• Temel SEO ayarları, site haritası ve yönlendirmeler.
• Kapsam DIŞI kalan işler, ayrı bir başlık altında.

Özellikle son madde gözden kaçar. Örneğin logo tasarımı, fotoğraf çekimi ya da metin yazarlığı çoğu teklifte yer almaz. Kapsam dışı işleri yazılı görmek, sonradan sürpriz fatura riskini azaltır. Hazır tema ile özel tasarım arasındaki seçim de kapsamı doğrudan değiştirir; bu kararı hazır tema mı özel web tasarım mı yazımızda ele aldık.

Web tasarım sözleşmesinde revizyon hakkını nasıl tanımlamalısınız?

Revizyon maddesi, kaç tur düzeltme hakkınız olduğunu ve bir turun neyi kapsadığını söylemelidir. Yalnızca "makul revizyon" yazan bir metin iki taraf için de yoruma açıktır. Bunun yerine her aşama için tur sayısını ve geri bildirimin hangi biçimde toplanacağını yazın.

Bizim önerimiz şu ayrımı yapmanızdır: düzeltme ile değişiklik aynı şey değildir. Yazım hatası, renk tonu ya da boşluk ayarı düzeltmedir; yeni bir sayfa eklemek ya da onayınızı alan tasarımı baştan değiştirmek ise kapsam değişikliğidir. Ayrıca toplu geri bildirim kuralı koymak işi hızlandırır; yani her tur için tek bir listede, tek kişiden yorum gelir.

• Her aşamada kaç revizyon turu olduğu (tasarım, geliştirme, içerik).
• Bir turda geri bildirimin hangi süre içinde iletileceği.
• Onay verdiğiniz bir aşamaya dönüşün ücreti.
• Geri bildirimi kimin vereceği ve kimin son onayı vereceği.

Son onay yetkisi kritik bir ayrıntıdır. Öte yandan işletmede birden fazla karar verici varsa, sözleşmede tek bir yetkili kişi belirlemek gecikmeyi büyük ölçüde engeller.

Teslim takvimini hangi aşamalara bölmelisiniz?

Tek bir teslim tarihi yazmak yerine projeyi aşamalara bölmek iki tarafı da korur. Tipik bir web tasarım sözleşmesi keşif, tasarım, geliştirme, içerik girişi, test ve yayın aşamalarını ayrı ayrı sıralar. Her aşamanın sonunda yazılı bir onay noktası yer alır.

1. Keşif ve brief onayı.
2. Tasarım taslakları ve onayı.
3. Geliştirme ve test ortamında inceleme.
4. İçerik girişi ve son kontroller.
5. Yayına alma ve teslim tutanağı.

Takvim maddesinde en çok unutulan nokta, gecikmenin kimden kaynaklandığıdır. Metinler ekip gecikmesini hep anlatır, ama müşteri içerik ya da onay vermediğinde takvimin nasıl kayacağı genellikle boş bırakılır. Bu yüzden "müşteri kaynaklı gecikmede takvim aynı süre kadar ileri kayar" gibi bir cümle ekleyin. Gün sayısı vermiyoruz; çünkü süre proje büyüklüğüne göre tamamen değişir.

Yayın aşamasının kontrol listesini merak ediyorsanız web sitesi oluşturma ve yayına alma kontrol listesi yazımıza göz atabilirsiniz.

Web tasarım sözleşmesinde ödeme aşamalarını neye bağlamalısınız?

Ödeme maddesi, bedelin hangi aşamada ve hangi koşulla ödeneceğini yazmalıdır. En sağlıklı yapı, her ödemeyi somut bir teslime bağlamaktır. Örneğin başlangıç ödemesi sözleşme imzasında, ikinci ödeme tasarım onayında, son ödeme yayına almada gelir gibi bir sıralama kurabilirsiniz.

Yüzde oranı vermiyoruz; çünkü oran projeye ve tarafların anlaşmasına göre değişir. Ancak şu soruların cevabını metinde mutlaka görmelisiniz:

• Fiyata vergiler dahil mi, değil mi?
• Fatura hangi para birimi ve kurla geliyor?
• Geç ödemede ne oluyor, iş duruyor mu?
• Ek işlerin fiyatını hangi yöntem belirliyor?
• Üçüncü taraf ücretleri (tema lisansı, eklenti, hosting) kimin ödemesinde?

Fiyat seviyesini etkileyen etkenleri kurumsal web sitesi fiyatları yazımızda anlattık. Vergi hesabı için KDV hesaplama aracımızı kullanabilirsiniz; yine de güncel oranı ve faturalama şeklini mali müşavirinize danışın. Bu yazı vergi danışmanlığı değildir.

Fikri mülkiyet ve kaynak kod kime ait olmalı?

Fikri mülkiyet maddesi, tasarımın, yazılımın ve içeriklerin kullanım hakkının kime geçtiğini söyler. Pek çok işletme sahibi parasını ödediği sitenin her parçasına sahip olduğunu sanar; oysa durum metinde ne yazdığına bağlıdır. Bu nedenle tasarım dosyalarının, özel yazılan kodun ve kaynak dosyaların teslimini açıkça yazdırın.

Burada üç katmanı ayırmak gerekir. Birincisi, size özel üretilen tasarım ve kod; bunun hakları normalde tam ödemeyle size geçer. İkincisi, ekibin birçok projede kullandığı hazır bileşenler; bunlar için ekip genellikle kullanım lisansı verir. Üçüncüsü, üçüncü taraf tema, eklenti, yazı tipi ve görseller; bunlar kendi lisans koşullarına tabidir.

• Hakların hangi anda geçtiği (çoğu zaman son ödemede).
• Kaynak kodun ve tasarım dosyalarının hangi formatta teslim edileceği.
• Üçüncü taraf lisanslarının kimin adına alındığı.
• Ekibin işi portföyünde gösterip gösteremeyeceği.

Kısacası "tüm haklar müşteriye aittir" gibi tek cümle yetmez; hangi parçanın hangi koşulla devredildiği yazılmalıdır.

Alan adı ve hosting hesaplarını kimin adına açmalısınız?

Alan adı ve hosting hesaplarının işletme adına, işletmenin kendi e-postasıyla açılmasını öneriyoruz. Ekip bu hesaplara yetkili kullanıcı olarak erişebilir; ama sahiplik sizde kalır. Sözleşmede bu durumu açık bir maddeyle yazmak, ileride ekip değiştirdiğinizde işinizi çok kolaylaştırır.

Alan adı kayıt sahipliğinin neden önemli olduğunu ICANN, alan adı sahiplerine yönelik kayıt sahibi bilgi sayfasında anlatır. Kendi alan adınızın kayıt bilgilerini WHOIS sorgulama aracımızla kontrol edebilirsiniz.

• Alan adı kaydının sahibi (registrant) işletme mi?
• Hosting, e-posta ve DNS panellerinin ana hesabı kimde?
• Google Search Console, Analytics ve reklam hesaplarında sahip kim?
• Ekip şifreleri teslimde hangi güvenli yolla aktarıyor?

Eğer bu hesaplar bugün eski bir ekibin elindeyse, süreci adım adım web sitesi ve alan adını eski ajanstan geri alma yazımızda anlattık; burada tekrar etmiyoruz.

İçerik sorumluluğunu sözleşmede nasıl paylaştırmalısınız?

İçerik maddesi; metinlerin, görsellerin ve ürün bilgilerinin kimin tarafından, hangi tarihe kadar ve hangi formatta sağlanacağını belirler. Projelerin en sık takıldığı yer burasıdır. Tasarım hazırdır, ama metinler gelmediği için site yayına çıkamaz.

Ayrıca içeriğin hukuki sorumluluğu da yazılmalıdır. Sizin sağladığınız görselin telif hakkı ya da metindeki iddiaların doğruluğu genellikle sizin sorumluluğunuzdadır. Ekip stok görsel ya da metin yazarlığı sağlıyorsa, bunların lisansı ve kapsamı ayrı bir satırda yer almalıdır.

• İçeriği kim yazıyor ve kim onaylıyor?
• Görseller kimden geliyor, lisansı kimin adına?
• İçerik girişini ekip mi yapıyor, siz mi?
• İçerik gecikirse takvim ve ödemeye ne olacak?

Örneğin şöyle bir cümle işe yarar: "Müşteri, içerikleri tasarım onayından sonra belirlenen tarihe kadar iletir; içerik gelmezse ekip geçici metinle yayına almayı önerebilir." Böylece proje süresiz beklemez.

Garanti ve hata düzeltme süresi ne kadar olmalı?

Garanti maddesi, teslimden sonra ortaya çıkan hataların hangi süre içinde ücretsiz düzeltileceğini anlatır. Burada iki ayrım önemlidir: hata ile yeni istek farklıdır, ve sizin ya da üçüncü bir tarafın yaptığı değişiklik sonrası çıkan sorun garanti dışında kalabilir.

Gün sayısı yazmıyoruz; çünkü makul süre projeye göre değişir. Ancak metinde süre mutlaka rakamla yer almalı, "bir süre" gibi muğlak ifadeden kaçınmalısınız. Ayrıca hatanın nasıl bildirileceği ve ekibin hangi süre içinde dönüş yapacağı da metinde yer almalı.

• Garanti süresinin başladığı an: yayın tarihi mi, teslim tutanağı mı?
• Garantinin kapsadığı şeyler: kod hataları, tarayıcı uyumsuzlukları, form arızaları.
• Garanti dışı durumlar: müşteri değişiklikleri, eklenti güncellemeleri, sunucu sorunları.
• Bildirim kanalı ve dönüş süresi.

Teslim öncesi test sürecini sözleşmeye bağlamak da garantiyi güçlendirir. Örneğin SSL sertifikasının kurulu olduğunu SSL sorgulama aracımızla teslim günü birlikte kontrol edebilirsiniz.

Bakım hizmeti neden ayrı bir madde olmalı?

Bakım, garantiden farklı bir hizmettir ve sözleşmede ayrı yazılmalıdır. Garanti, teslim edilen işteki hataları kapsar; bakım ise sistemin zaman içinde güncel ve güvenli kalmasını sağlar. Bu ikisini karıştırmak, "garanti bitti, artık her şey ücretli" tartışmasını doğurur.

Bakım genellikle aylık ya da yıllık bir paket olarak ayrı sözleşmeyle ya da ekle yürür. Bakım maddesinde yazılım güncellemeleri, yedekleme, güvenlik takibi, küçük içerik değişiklikleri ve raporlama gibi işlerin hangisinin dahil olduğu listelenmelidir. Bakımın neleri kapsadığını web sitesi bakımı nedir yazımızda kontrol listesiyle anlattık.

Öte yandan bakım almamayı da seçebilirsiniz. Bu durumda sözleşmede güncellemelerin sizin sorumluluğunuzda olduğu ve ekibin sonradan yapacağı müdahalelerin ayrıca ücretlendirileceği açıkça yazmalıdır. Böylece kimse yanlış beklentiye girmez.

KVKK ve veri işleme maddesi neden gerekli?

Siteniz form, üyelik ya da ödeme yoluyla kişisel veri topluyorsa, tasarım ekibi geliştirme ve bakım sırasında bu verilere erişebilir. Bu durumda iki tarafın rolünü ve sorumluluğunu yazılı hale getiren bir veri işleme maddesi ya da ek sözleşme gerekir. Kural ve yükümlülükler için Kişisel Verileri Koruma Kurumu sayfasını resmi kaynak olarak takip edin.

• Ekibin hangi verilere, hangi amaçla eriştiği.
• Verilerin nerede saklandığı ve kimlerle paylaşıldığı.
• Güvenlik önlemleri ve olası ihlalde bildirim yükümlülüğü.
• Sözleşme bittiğinde verilerin iadesi ya da silinmesi.

Ayrıca aydınlatma metni, çerez bildirimi ve açık rıza metinlerinin içeriğini kimin hazırlayacağı da yazılmalıdır. Ekip bunları teknik olarak yerleştirir, ama metnin hukuki içeriği çoğu zaman sizin ya da avukatınızın sorumluluğundadır. Teknik tarafı KVKK ve GDPR uyumlu web sitesi yazımızda ayrıntılı ele aldık. Bu bölüm de hukuki danışmanlık değildir.

Gizlilik ve rekabet maddeleri ne işe yarar?

Gizlilik maddesi, proje sırasında paylaştığınız ticari bilgilerin, müşteri listelerinin ve stratejilerin üçüncü kişilere aktarılmamasını güvence altına alır. Özellikle yeni ürün lansmanı ya da henüz duyurmadığınız bir hizmet için site yaptırıyorsanız bu madde önem kazanır.

Bununla birlikte rekabet yasağı maddeleri dikkatle yazılmalıdır. Ekibin aynı sektörde başka bir firmaya hiç hizmet vermemesini istemek çoğu zaman gerçekçi değildir. Bunun yerine gizli bilgilerin kullanılmaması ve projenin duyuru tarihine kadar portföyde gösterilmemesi gibi daha dengeli bir çözüm önerilebilir.

Kısacası gizlilik maddesi kısa olabilir, ama süresi ve kapsamı açık olmalı. Sözleşme bittikten sonra ne kadar süre geçerli kalacağı da metinde yer almalıdır.

Ayrıca gizlilik iki yönlü çalışmalıdır. Siz ekibe panel şifreleri, müşteri verileri ve iç belgeler verirsiniz; ekip de size kendi çalışma yöntemlerini ve fiyat yapısını gösterir. Dengeli bir madde iki tarafın bilgisini de korur. Örneğin şifre paylaşımı için ortak bir parola yöneticisi kullanmayı, e-posta ile düz metin şifre göndermemeyi ve proje bitince erişimleri kapatmayı metne ekleyebilirsiniz. Böylece güvenlik yalnızca bir niyet olarak kalmaz, somut bir adıma dönüşür.

Test, kabul ve teslim tutanağı nasıl işlemeli?

Kabul maddesi, işin ne zaman "teslim" sayılacağını tanımlar. Bu tanım hem son ödemeyi hem garanti süresinin başlangıcını etkiler. Bu yüzden yazılı bir kabul süreci kurmanızı öneriyoruz: ekip test ortamını açar, siz belirlenen süre içinde inceleyip geri bildirim verirsiniz, ardından iki taraf teslim tutanağını imzalar.

1. Ekip test bağlantısını ve kontrol listesini paylaşır.
2. Siz farklı cihaz ve tarayıcılarda siteyi gezersiniz.
3. Bulduğunuz sorunları tek listede iletirsiniz.
4. Ekip düzeltmeleri yapar ve yeniden onaya sunar.
5. İki taraf tutanağı imzalar, ekip hesapları ve dosyaları devreder.

Metne "belirlenen süre içinde geri bildirim gelmezse iş kabul sayılır" gibi bir cümle girebilir. Bu cümle ekibi korur; ancak siz de süreyi gerçekçi tutmak için pazarlık edebilirsiniz.

Fesih maddesinde hangi durumları düzenlemelisiniz?

Fesih maddesi, projenin yarıda kalması halinde ne olacağını anlatır. Hiç kimse sözleşme imzalarken ayrılığı düşünmek istemez, ama bu madde en çok ihtiyaç duyulan maddedir. Hangi durumda taraflardan birinin sözleşmeyi bitirebileceği ve bitişte kimin neyi teslim edeceği net olmalıdır.

• Hangi durumda fesih hakkı doğuyor: ödeme gecikmesi, uzun süre iletişimsizlik, ağır kusur.
• Fesih bildiriminin nasıl ve hangi süreyle yapılacağı.
• O ana kadar yapılan işin nasıl ücretlendirileceği.
• Tamamlanan dosyaların, kodun ve hesap erişimlerinin devri.

Özellikle son madde önemlidir. Örneğin proje tasarım aşamasında biterse, ödediğiniz kısma karşılık gelen tasarım dosyalarını alabilmelisiniz. Böylece başka bir ekiple işe sıfırdan başlamak zorunda kalmazsınız.

Sorumluluk sınırı ve uyuşmazlık maddesini nasıl okumalısınız?

Sorumluluk sınırı maddesi, bir sorun çıktığında ekibin üstleneceği azami sorumluluğu belirler. Çoğu metin bu sınırı proje bedeline bağlar. Bu kendi başına olağandır; ancak veri kaybı ya da güvenlik ihlali gibi ağır durumların nasıl ele alınacağını ayrıca okumanız gerekir.

Uyuşmazlık maddesi ise anlaşmazlık halinde hangi yolun izleneceğini, yetkili mahkemeyi ya da arabuluculuk gibi alternatifleri yazar. Bu maddenin hukuki sonuçları önemli olduğu için yorumunu mutlaka avukatınıza bırakın.

Bizim saha gözlemimiz şudur: anlaşmazlıkların büyük kısmı mahkemeye değil, belirsiz kapsam ve eksik iletişime dayanır. Dolayısıyla önceki maddeleri net yazmak, bu maddeye hiç ihtiyaç duymamanın en iyi yoludur.

Bir de iletişim kanalını sözleşmeye yazmanızı öneriyoruz. Resmi bildirimlerin hangi e-posta adresine gideceği, haftalık durum toplantısının olup olmayacağı ve acil durumda kime ulaşacağınız açık olursa, küçük sorunlar büyümeden çözülür. Üstelik bu kayıtlar, ileride bir anlaşmazlık çıkarsa sürecin nasıl ilerlediğini gösteren en net kanıttır.

Yeniden tasarımda web tasarım sözleşmesine ne eklemelisiniz?

Mevcut bir siteyi yeniliyorsanız, sözleşmeye yeni bir sayfa listesinden fazlası girmelidir. Eski adreslerin yeni adreslere yönlendirilmesi, mevcut içeriklerin taşınması ve arama motoru görünürlüğünün korunması ayrı birer iş kalemidir. Bunlar yazılmazsa, yeni site güzel olur ama trafik düşebilir.

• Yönlendirme haritasını kim hazırlıyor, kim devreye alıyor?
• Hangi içerikleri taşıyor, birleştiriyor ya da kaldırıyorsunuz?
• Ekip yayın sonrası takibi ne kadar sürdürüyor?

Bu sürecin teknik ayrıntılarını yeniden tasarımda SEO sıralamasını koruma yazımızda adım adım anlattık. Sunucu da değişiyorsa hosting değiştirme kontrol listesi işinizi kolaylaştırır.

Değişiklik talepleri ve ek işler nasıl yönetmelisiniz?

Proje ilerledikçe yeni fikirler gelir; bu doğaldır. Sorun, bu fikirlerin kapsamın içine sessizce girmesidir. Bu yüzden sözleşmeye bir değişiklik talebi süreci ekleyin: yeni istek yazılı gelir, ekip etkisini süre ve bedel olarak tahmin eder, siz onay verince iş başlar.

1. Talebi tek cümleyle yazın ve gerekçesini ekleyin.
2. Ekip, talebin takvime ve bedele etkisini yazılı olarak iletir.
3. Siz onaylarsanız iki taraf kısa bir ek protokol imzalar.
4. Ekip işi takvime ekler ve sonraki aşamaları buna göre günceller.

Örneğin tasarım onayından sonra çok dilli yapı istemeye karar verdiniz diyelim. Bu istek sayfa sayısını, test yükünü ve içerik ihtiyacını birlikte artırır. Yazılı süreç olmadan ekip ya bedava çalışır ya da sonradan fatura çıkarır; iki durumda da ilişki zarar görür. Üstelik değişiklik kayıtları, proje sonunda neyin neden uzadığını görmenizi sağlar.

Kısacası ek işi engellemek değil, görünür kılmak gerekir. Böylece hem bütçenizi kontrol edersiniz hem de ekibin emeğini adil biçimde karşılarsınız.

Üçüncü taraf lisans ve abonelik maddesi neyi kapsamalı?

Modern bir site nadiren tek parçadan oluşur. Tema, eklenti, yazı tipi, harita servisi, form aracı ya da e-posta altyapısı gibi pek çok parça üçüncü tarafların lisans ya da abonelik koşullarına bağlıdır. Bu parçaların yıllık yenileme bedeli projeden sonra da sürer, bu yüzden sözleşmede ayrı bir listede durmalı.

• Hangi tema, eklenti ve servisleri kullandığınız.
• Lisansın kimin hesabına alındığı ve kimin adına yenilendiği.
• Yenileme tarihlerini kimin takip ettiği.
• Bir servis kapanırsa ya da fiyat değiştirirse ne yapacağınız.

Sahada sık gördüğümüz bir durum şudur: ekip lisansı kendi hesabından alır, proje biter, bir yıl sonra lisans yenilenmez ve güncellemeler durur. Bu nedenle lisansları mümkünse işletme hesabına aldırın ya da devri teslim tutanağına yazdırın. Ayrıca abonelik bedellerini teklif fiyatından ayrı görmek, toplam sahip olma maliyetini doğru hesaplamanıza yardım eder.

Performans ve erişilebilirlik hedefleri sözleşmeye girmeli mi?

Evet, en azından genel hedefler olarak girmesini öneriyoruz. Sitenin mobilde hızlı açılması, temel erişilebilirlik ilkelerine uyması ve arama motorlarının sayfaları tarayabilmesi kalite beklentinizin parçasıdır. Bu beklentiyi yazıya dökmezseniz, teslimde neyi ölçeceğinizi bilemezsiniz.

Ancak kesin skor taahhüdü istemek dikkat ister. Örneğin hız ölçümleri kullandığınız görsellere, eklentilere ve sunucuya göre değişir; bu etkenlerin bir kısmı ekibin kontrolünde değildir. Bunun yerine şu tür ifadeler daha adildir:

• Ekip, Google'ın web.dev rehberlerindeki temel performans ilkelerini uygular.
• Ekip, teslimde mobil ve masaüstü testlerinin sonucunu sizinle paylaşır.
• Formlar ve menüler klavye ile kullanılabilir durumdadır.
• Ekip, teslimde temel SEO ayarlarını kontrol listesiyle gösterir.

Böylece hedefler ölçülebilir olur, ama hiçbir taraf kontrol edemediği bir rakama bağlanmaz. Teslim günü bu listeyi birlikte gözden geçirmek de kabul sürecini netleştirir.

İmzadan önce hangi kontrol listesini kullanmalısınız?

Aşağıdaki liste, elinizdeki taslağı hızlıca taramanıza yardım eder. Her maddeye "evet, metinde açıkça yazıyor" diyebiliyorsanız, sözleşmeniz sağlam bir temele sahiptir. Cevabınız "hayır" ya da "emin değilim" ise o maddeyi ekipten netleştirmesini isteyin.

1. Kapsam ve kapsam dışı işler ayrı listelerde.
2. Revizyon turu sayısı ve son onay yetkilisi belli.
3. Takvim aşamalı, müşteri kaynaklı gecikme de metinde.
4. Her ödeme somut bir teslime bağlı.
5. Fikri mülkiyet ve kaynak kod devri açık.
6. Alan adı, hosting ve analiz hesapları işletme adına.
7. İçerik sorumluluğu ve teslim tarihi belli.
8. Garanti süresi rakamla belli, bakım ayrı maddede.
9. Veri işleme ve gizlilik maddeleri metinde.
10. Fesih halinde teslim edeceğiniz dosyaların listesi belli.

Bu listeyi metni okuyan avukatınızla da paylaşabilirsiniz. Böylece teknik tarafı siz, hukuki tarafı uzmanınız kontrol eder.

Web tasarım sözleşmesinde sık yapılan hatalar nelerdir?

Sahada en sık gördüğümüz hata, internetten indirilen genel bir şablonu hiç uyarlamadan kullanmaktır. Şablon başlangıç için iyidir, ama projenize özgü kapsamı, hesapları ve teslimleri içermez. İkinci hata, ek işleri sözlü konuşup yazıya dökmemektir.

• Kapsamı tek cümleyle geçmek: "kurumsal web sitesi yapılacaktır" gibi.
• Alan adını ekibin hesabına açtırmak.
• Garanti ile bakımı aynı madde içinde eritmek.
• Fesih halinde dosya teslimini yazmamak.
• Ek protokol yerine e-posta yazışmasına güvenmek.

Son olarak, sözleşmeyi imzalayıp çekmeceye koymak da bir hatadır. Proje boyunca metni elinizin altında tutun ve her aşama onayında ilgili maddeye bakın. Bu alışkanlık hem sizi hem ekibi aynı çizgide tutar. Özellikle uzun projelerde, ilk haftalarda konuştuğunuz ayrıntıları aylar sonra hatırlamak zordur; yazılı metin bu boşluğu doldurur ve iki tarafa da ortak bir referans noktası verir.

Doğru ekiple sözleşme sürecini nasıl kolaylaştırırsınız?

İyi bir ekip, sözleşme maddelerini sizden önce gündeme getirir. Hesapların kimin adına açılacağını, revizyon sınırını ve teslim dosyalarını ilk görüşmede kendisi sorar. Bu tavır, ileride çıkabilecek sorunların erken çözüleceğinin işaretidir.

Biz Talha Aslan ve ekibi olarak her projede kapsamı yazılı bir ekle netleştiriyor, hesapları işletme adına açtırıyor ve teslimde kaynak dosyaları devrediyoruz. Siz de projenizi bu açıklıkla başlatmak isterseniz web tasarım hizmeti sayfamızdan teklif isteyebilirsiniz. Sözleşmenin hukuki son okumasını ise her zaman avukatınıza bırakmanızı öneriyoruz.