Web sitesi yaptırma lisans ve içerik hakları, teklif fiyatından bağımsız olarak projenin ileride kullanılabilirliğini, taşınabilirliğini ve başka bir ekiple sürdürülebilirliğini etkiler. “Site bizim olacak mı?” sorusu tek başına yeterli değildir; özel kod, tasarım dosyaları, metinler, stok görseller, fontlar, eklentiler, CMS ve hesap erişimleri farklı hak rejimlerine bağlı olabilir. Bu nedenle teklif aşamasında her varlığın kullanım, düzenleme, teslim, yenileme ve devir koşulları ayrı ayrı sorulmalıdır. Böyle bir kontrol, firma karşılaştırmasını daha şeffaf hale getirir ve hizmet sonlandığında beklenmedik bağımlılıkları azaltır.

01

Teklifte hak sahipliği neden kalem kalem sorulmalıdır?

Hak sahipliği kalem kalem sorulmalıdır çünkü bir web sitesi tek bir varlıktan değil, farklı üretim ve lisans koşullarına sahip bileşenlerden oluşur. Temel ayrım sahiplik, kullanım lisansı ve teslim hakkı arasındadır. Bir unsurun kullanılabilmesi, onun kaynak dosyasının devredildiği veya başka projelerde sınırsızca kullanılabileceği anlamına gelmez. Teklifte bu ayrım görünür değilse, proje sonunda tarafların farklı beklentilere sahip olması kolaylaşır.

Tek soruyu varlık bazlı kontrol listesine dönüştürün

Firma görüşmesinde “site kimin olacak?” yerine her varlık için ayrı hak soruları yöneltmek daha sağlıklı bir karşılaştırma sağlar. Özellikle web tasarım teklifinde sorulması gereken konuları lisans, teslim ve erişim başlıklarıyla birlikte değerlendirmek gerekir. Böylece teklif yalnızca geliştirme işini değil, kullanım sonrasındaki operasyonel özgürlüğü de açıklayan bir belgeye dönüşür.

  • Her varlığın kim tarafından üretildiğini veya sağlandığını sorun.
  • Kullanım hakkının süresini ve kapsamını ayrı yazdırın.
  • Düzenleme ve türev çalışma hakkının tanımını netleştirin.
  • Kaynak veya düzenlenebilir dosya teslimini ayrıca belirtin.
  • Üçüncü taraf lisanslarını proje üretiminden ayırın.
İyi tasarım iyi iştir. - Thomas J. Watson Jr.
02

Özel geliştirilen kodun kullanım hakkı nasıl tanımlanmalı?

Özel geliştirilen kodun kullanım hakkı, projeye özgü geliştirilen parçalar ile firmanın daha önce sahip olduğu kütüphane, altyapı ve yeniden kullanılabilir bileşenleri ayıracak şekilde tanımlanmalıdır. Kaynak kodu teslimi ile fikri hakların devri aynı şey değildir. Müşterinin kodu çalıştırma, değiştirme, başka bir geliştiriciye devretme veya farklı bir sunucuda kullanma yetkileri teklif ve sözleşmede ayrı ifadelerle açıklanmalıdır.

Kaynak kodu teslimini operasyonel kullanımla birlikte düşünün

Yalnızca bir dosya arşivi almak sürdürülebilir devir anlamına gelmeyebilir. Kod deposu, bağımlılık listeleri, kurulum bilgileri ve çalıştırma süreci de teslim kapsamının parçası olabilir. Bu nedenle web tasarım sözleşmesinde yer alacak maddeler incelenirken kodun hangi hakla verildiği, hangi bölümlerin önceden mevcut olduğu ve müşterinin sonraki geliştirmelerde hangi yetkilere sahip olacağı açıkça yazılmalıdır.

  • Projeye özgü kod ile önceden mevcut bileşenleri ayırın.
  • Kaynak kod deposunun teslim edilip edilmeyeceğini sorun.
  • Kodu değiştirme ve başka ekiple sürdürme hakkını tanımlayın.
  • Birden fazla alan adı veya şirket için kullanım sınırını öğrenin.
  • Devir, alt lisans veya yeniden satış kısıtlarını ayrıca kontrol edin.
03

Tasarım dosyaları ve içerikler hangi kapsamda teslim edilir?

Tasarım dosyaları ve içerikler, nihai yayındaki görünümden ayrı teslim kalemleri olarak tanımlanmalıdır. Yayınlanmış bir tasarımı kullanma hakkı, düzenlenebilir kaynak tasarım dosyalarının otomatik olarak teslim edileceği anlamına gelmez. Benzer şekilde şirketin sağladığı metin ve fotoğraflar ile ajansın proje kapsamında ürettiği metin, illüstrasyon veya görsellerin hak durumu aynı olmayabilir. Teklifte her içerik sınıfının kaynağı ve teslim biçimi belirtilmelidir.

Düzenlenebilir dosyaları ve içerik kökenini ayrı sorun

Tasarım tarafında ekran tasarımlarının, ikon setlerinin, özgün illüstrasyonların ve varsa prototip dosyalarının teslim edilip edilmeyeceği netleştirilmelidir. İçerik tarafında ise müşterinin sağladığı materyalin mülkiyeti ile hizmet sağlayıcının oluşturduğu materyalin kullanım koşulları ayrılmalıdır. Bu yaklaşım, ileride yeni sayfa üretirken veya farklı bir ekip ile çalışırken hangi varlığın yeniden kullanılabileceğinin baştan bilinmesini sağlar.

  • Düzenlenebilir tasarım dosyalarının teslim biçimini yazdırın.
  • Özgün ikon ve illüstrasyonların kullanım hakkını sorun.
  • Müşteri kaynaklı içerikleri ayrı bir envanterde tutun.
  • Ajans tarafından üretilen metinlerin kullanım kapsamını belirleyin.
  • Portföyde gösterim gibi ikincil kullanım izinlerini ayrıca değerlendirin.
04

Stok görsel ve üçüncü taraf lisanslarını kim yönetmeli?

Stok görsel ve üçüncü taraf lisanslarında yönetim sorumluluğu, lisansı kimin hesabından aldığına, lisansın devredilebilir olup olmadığına ve kullanım koşullarına göre açıkça belirlenmelidir. Üçüncü taraf lisansı, web projesinin kendi sahiplik şartlarından ayrı bir katmandır. Görsel, font, tema, eklenti, harita, API veya benzeri bir bileşen için müşteriye yalnızca belirli bir kullanım hakkı tanınabilir; tam hak devri mümkün olmayabilir.

Yenileme ve lisans sahibini teklif tablosunda görünür yapın

Teklifte üçüncü taraf ürünün adı kadar, lisansın hangi hesapta tutulduğu, yenileme gerektiğinde kimin sorumlu olduğu ve hizmet sağlayıcı değiştiğinde lisansın nasıl devam edeceği de sorulmalıdır. Özellikle abonelikle çalışan bileşenlerde ilk dönemin proje kapsamına dahil olması, sonraki dönemlerin de otomatik olarak dahil olduğu anlamına gelmez. Yenileme süreci ve olası alternatifler başlangıçta açıklanırsa bütçe ve süreklilik daha öngörülebilir olur.

  • Lisansın müşteri hesabında mı firma hesabında mı olduğunu öğrenin.
  • Yenileme tarihini ve sorumlu tarafı teklif ekine yazdırın.
  • Lisansın başka sağlayıcıya devredilip devredilemediğini kontrol edin.
  • Kullanımın alan adı veya kullanıcı sayısıyla sınırlı olup olmadığını sorun.
  • Alternatif bileşene geçiş halinde hangi işlerin gerekeceğini öğrenin.
05

CMS lisans bedeli ve yenileme sorumluluğu nasıl ayrılır?

CMS lisans bedeli ve yenileme sorumluluğu, ilk geliştirme hizmetinden ayrı değerlendirilmelidir. İçerik yönetim sistemi açık kaynaklı, ticari lisanslı veya hizmet olarak sunulan bir platform olabilir; bu modeller müşterinin erişim, güncelleme ve taşıma seçeneklerini farklılaştırır. Geliştirme bedelinin ödenmesi, devam eden platform aboneliklerinin de süresiz karşılandığı anlamına gelmez. Teklif, tekrar eden lisansların kapsamını ve ödeme sorumluluğunu anlaşılır biçimde göstermelidir.

Platform erişimini bakım hizmetinden bağımsız tanımlayın

Müşterinin yönetici hesabına sahip olup olmayacağı, kullanıcı oluşturma yetkisi, içerik dışa aktarma seçenekleri ve hizmet sonlandığında erişimin devam edip etmeyeceği sorulmalıdır. CMS için özel bir yönetim paneli geliştiriliyorsa bunun kod ve veri tabanı ile birlikte nasıl devredileceği de açıklanmalıdır. Böylece bakım sözleşmesi sona erse bile platformun temel kullanım hakkı ile destek hizmetinin kapsamı birbirine karışmaz.

  • CMS modelinin açık kaynak, lisanslı veya abonelik olduğunu sorun.
  • Tekrarlayan lisans ve abonelikleri ayrı kalem olarak görün.
  • Yönetici hesabının hangi taraf adına açılacağını belirleyin.
  • İçerik ve veri dışa aktarma imkanlarını kontrol edin.
  • Bakım bittiğinde panel erişiminin devam şartlarını yazdırın.
06

Site başka sunucuya taşınabilir mi ve neye bağlıdır?

Bir sitenin başka sunucuya taşınabilmesi; yazılım mimarisine, kullanılan platforma, üçüncü taraf lisanslarına ve gerekli erişimlerin müşteriye verilmesine bağlıdır. Taşınabilirlik, yalnızca kaynak kodun mevcut olmasıyla garanti edilmez. Veritabanı yapısı, dosya depolama, dış servisler, sunucu bağımlılıkları ve dağıtım süreci yeni ortamda yeniden kurulabilir olmalıdır. Bu nedenle site devir şartları teklif aşamasında teknik bir gereksinim olarak ele alınmalıdır.

Taşıma senaryosunu proje başlamadan test edilebilir hale getirin

Firma, çözümün standart bir hosting veya bulut ortamına taşınabildiğini söylüyorsa hangi gereksinimlerin bulunduğunu açıklamalıdır. Tamamen hizmet sağlayıcının kapalı altyapısına bağlı sistemlerde içerik dışa aktarımı mümkün olsa bile uygulamanın kendisi taşınamayabilir. Bu durum yanlış veya kötü bir model olduğu anlamına gelmez; ancak müşterinin sağlayıcı bağımlılığı düzeyini bilerek karar vermesini gerektirir.

  • Sunucu yazılımı ve sürüm gereksinimlerini isteyin.
  • Veritabanı ve yüklenen dosyaların nasıl aktarılacağını sorun.
  • Dış servis anahtarlarının yeniden tanımlanma sürecini öğrenin.
  • Kapalı platform bağımlılıklarını açıkça listeletin.
  • Taşıma için gerekli teknik dokümantasyonun teslimini kararlaştırın.
07

Firma değişiminde hangi teknik devir kalemleri istenmeli?

Firma değişiminde devir; alan adı, sunucu, kod deposu, veritabanı, yönetim paneli ve ölçüm araçları gibi temel hesap ve erişimleri kapsamalıdır. En kritik ilke, iş sürekliliği için gereken hesapların tek bir kişiye veya sağlayıcıya bağımlı kalmamasıdır. Müşteri adına açılabilecek hesapların mümkün olduğunca müşteri kontrolünde tutulması, devir sırasında parola paylaşımı yerine yetki aktarımı yapılmasını kolaylaştırır.

Erişim envanterini proje teslim listesinin parçası yapın

Devir planı yalnızca sözleşme bittiğinde gündeme gelmemelidir. Projenin başında hangi hesapların oluşturulacağı, ana yönetici kimliğinin kimde olacağı ve hangi erişimlerin teslim edileceği belirlenebilir. web tasarım firması değiştirirken dikkate alınacak noktalar içinde bu envanteri önceden hazırlamak, yeni ekibin sistemi incelemesini ve hizmet kesintisi riskini azaltacak geçiş planı kurmasını kolaylaştırır.

  • Alan adı kayıt kuruluşu ve DNS erişimini kontrol edin.
  • Hosting veya bulut yönetim hesabını envantere ekleyin.
  • Kod deposu ve sürüm geçmişinin teslimini planlayın.
  • Veritabanı yedeği ve dosya arşivi teslim yöntemini tanımlayın.
  • Analitik, arama ve diğer yönetim araçlarının yetkilerini devredin.
08

Bakım anlaşması sahiplik ve kullanım hakkından farklı mıdır?

Evet. Bakım anlaşması; güncelleme, hata müdahalesi, izleme, yedekleme veya teknik destek gibi devam eden hizmetleri tanımlar; sahiplik ve kullanım hakkı ise projenin varlıkları üzerinde hangi yetkilerin bulunduğunu açıklar. Bakım hizmeti ile lisans koşullarını aynı kavram gibi değerlendirmemek gerekir. Bir müşterinin bakım hizmeti almaması, sözleşmede farklı bir hüküm yoksa daha önce tanımlanmış kullanım haklarının ne olduğunu tek başına açıklamaz.

Devam eden hizmetlerle kalıcı hakları iki ayrı tabloda izleyin

Teklif karşılaştırırken bir tabloda teslim edilen varlıklar ve haklar, diğer tabloda ise periyodik bakım ve destek hizmetleri gösterilebilir. Böylece kaynak kod teslimi, CMS erişimi veya tasarım dosyaları gibi konular; güncelleme paketi, destek süresi ya da müdahale kapsamıyla karışmaz. Bu ayrım, düşük veya yüksek teklif fiyatından bağımsız olarak hangi hizmetin tek seferlik, hangisinin devam eden sorumluluk olduğunu görmeyi kolaylaştırır.

  • Kalıcı kullanım haklarını bakım paketinden ayrı yazdırın.
  • Güncelleme sorumluluğunun hangi bileşenleri kapsadığını sorun.
  • Destek sona erdiğinde hangi erişimlerin devam edeceğini belirleyin.
  • Yedekleme ve güvenlik operasyonlarını sahiplikten ayırın.
  • Yeni firma ile çalışma hakkını sınırlayan hükümleri kontrol edin.
09

Kurumsal site sözleşmesinde hangi maddeler netleştirilmeli?

Kurumsal site sözleşmesinde teslim kapsamı, lisans türleri, üçüncü taraf bileşenler, hesap sahipliği, kabul süreci ve sözleşme sonundaki devir adımları açık biçimde tanımlanmalıdır. Sözleşme, teklifin teknik ve ticari varsayımlarını ölçülebilir teslim maddelerine dönüştürmelidir. Hakların hangi anda doğduğu, ödeme veya kabul adımlarıyla ilişkisi ve projeye özgü varlıkların hangileri olduğu da tarafların kendi hukuk danışmanlarıyla değerlendirebileceği netlikte yazılmalıdır.

Teklif ile sözleşme eklerinin birbiriyle çelişmediğini kontrol edin

Teklifte “kaynak kod dahil” yazarken sözleşmede geniş bir istisna bulunması veya teslim listesinde tasarım kaynaklarının yer almaması farklı yorumlara yol açabilir. Bu nedenle web sitesi tekliflerini karşılaştırırken kullanılan kriterlere lisans tablosu ve teslim eki de eklenmelidir. Teknik ekip neyin teslim edileceğini, satın alma ekibi tekrar eden yükümlülükleri, hukuk danışmanı ise hak ve sorumluluk ifadelerini birlikte gözden geçirebilir.

  • Teslim edilecek varlıkların isimlerini sözleşme ekinde listeleyin.
  • Her varlık için sahiplik veya lisans modelini belirtin.
  • Üçüncü taraf ürünleri ve istisnaları ayrı gösterin.
  • Kabul ve nihai devir adımlarını ilişkilendirin.
  • Sözleşme sona erdiğinde uygulanacak erişim devrini açıklayın.
10

Teklifler lisans ve teslim açısından nasıl karşılaştırılmalı?

Teklifler lisans ve teslim açısından karşılaştırılırken her firmaya aynı varlık listesi ve aynı sorular gönderilmelidir. Böylece bir teklifin fiyatı yerine, müşteriye bıraktığı kullanım özgürlüğü, tekrar eden yükümlülükler ve devir kolaylığı birlikte görülebilir. Karşılaştırmanın amacı en fazla hakkı istemek değil, ihtiyaç duyulan hakları açık ve uygulanabilir biçimde tanımlamaktır. Bazı projelerde lisanslı bir platform doğru seçim olabilir; önemli olan bu bağımlılığın bilinerek kabul edilmesidir.

Karar öncesinde örnek teslim listesi ve sözleşme eki isteyin

Aday firmalardan örnek teslim listesi, üçüncü taraf lisans tablosu ve hesap devir şablonu istemek tekliflerin aynı zeminde değerlendirilmesini sağlar. Ayrıca kurumsal web sitesi hizmet kapsamını hak ve teslim koşullarıyla birlikte okumak, fiyatın hangi sorumlulukları içerdiğini daha net gösterir. Nihai kararda teknik uygunluk, operasyonel sürdürülebilirlik ve sözleşme açıklığı birlikte ele alınmalıdır.

  • Aynı lisans ve teslim sorularını tüm firmalara yöneltin.
  • Tek seferlik teslimlerle yinelenen lisansları ayırın.
  • Taşıma ve firma değişimi senaryosunu teklif öncesinde sorun.
  • Eksik veya belirsiz maddeleri yazılı açıklama ile tamamlatın.
  • Nihai sözleşmede teklif eklerinin güncel sürümünü referans alın.

Lisans ve teslim kapsamınızı netleştirin

Teklifinizdeki lisans, içerik hakkı ve devir maddelerini paylaşın; proje kapsamını ve teslim sorumluluklarını netleştirmek için görüşme planlayın.

Teklif Görüşmesi Planlayın