Yazılım Geliştirme Sözleşmesi: Nelere Dikkat Edilmeli

Yazılım geliştirme sözleşmesinde fiyattan önce bakılacak beş madde vardır: kapsamın sözleşmeye ek olarak yazılı biçimde bağlanması, kaynak kodun ve mali hakların size devri, kabul (test) kriterleri, ödeme dilimlerinin takvim tarihine değil kabule bağlanması ve teslim sonrası garanti ile bakımın birbirinden ayrılması. Türk hukukunda mali hak devrinin yazılı olması ve devredilen hakların ayrı ayrı gösterilmesi şarttır (FSEK m. 52); sözleşmede bu satır yoksa faturayı siz ödeseniz de kodun mali hakları geliştiricide kalır. Aşağıda bir yazılım sözleşmesinin madde madde nasıl okunacağını, hangi cümlelerin sizi bağladığını ve uyuşmazlıkların gerçekte hangi boşluktan çıktığını bulacaksınız.

Sözleşmenin asıl gövdesi eklerdedir

İmzalanan metnin ilk sayfaları hemen her firmada aynıdır: taraflar, süre, gizlilik, tebligat adresleri. Uyuşmazlıkların neredeyse tamamı ise o metinde değil, atıf yapılan ekte çıkar — çünkü “ne yapılacağı” oradadır. “Kurumsal web sitesi ve yönetim paneli yapımı” gibi tek satırlık bir konu tanımı, altı ay sonra iki tarafın da kendince haklı olduğu bir tartışma üretir. Kapsam ekini hazırlamanın en verimli yolu, teklif toplarken kullandığınız brief’i olduğu gibi sözleşmeye taşımaktır; yazılım proje brief’i hazırlama yazısındaki başlıklar doğrudan ek olarak kullanılabilir.

• Ekran ve modül listesi — sayıyla. “Raporlama” değil, “5 rapor ekranı: satış, stok, tahsilat, kullanıcı, denetim kaydı”.
• Roller ve yetkiler — kaç kullanıcı rolü var, hangi rol neyi görüyor, neyi değiştirebiliyor. Rol sayısı geliştirme süresini doğrudan büyütür.
• Entegrasyonlar ve karşı tarafın sorumluluğu — hangi sistemlere bağlanılacak, API dokümanını ve test hesabını kim sağlayacak, üçüncü tarafın gecikmesi kimin riski.
• Veri göçü — hangi veri, hangi kaynaktan, kaç kayıt, temizliği kim yapıyor. Projeleri en çok geciktiren kalem neredeyse her zaman budur.
• Kapsam dışı olanlar — açıkça yazın: içerik girişi, görsel üretimi, mobil uygulama, çok dillilik, kullanıcı eğitimi. “Konuşulmadı” ile “kapsam dışıdır” arasında altı haftalık fark vardır.
• Teslim edilecek çıktılar — kaynak kod, veritabanı şeması, kurulum dokümanı, ortam değişkenleri listesi, tasarım dosyaları.

Kaynak kod ve fikri mülkiyet kime ait?

Yazılım Türk hukukunda eser sayılır ve eser üzerindeki mali haklar, yazılı olarak devredilmedikçe geliştiricide kalır. “Parasını ödedim, benimdir” varsayımı burada çalışmaz. Devir maddesi de genel bir cümle olmamalı: işleme, çoğaltma, yayma, temsil ve umuma iletim haklarının süresiz, yer bakımından sınırsız ve devredilebilir biçimde müşteriye geçtiği tek tek yazılmalıdır. Manevi haklar devredilemez, ancak kullanma yetkisi verilebilir — bu ayrım, geliştiricinin projeyi referans olarak gösterme hakkıyla birlikte konuşulur.

İkinci soru, teslim edilen kodun ne kadarının gerçekten geliştiriciye ait olduğudur. Her modern projede açık kaynak kütüphaneler bulunur; bunların çoğu sorunsuzdur, ama gövdeye gömülmüş GPL/AGPL lisanslı bir bileşen ürünü ileride kapalı kaynak olarak satmanızı imkânsız hâle getirebilir. Firmanın kendi altyapısını kullanması da yaygın ve makuldür; kabul edilemez olan, o çekirdeğin devredilmemesi ve karşılığında süresiz kullanım lisansı da verilmemesidir. Sözleşmeye tek cümle ekletin: teslim edilen üründe kullanılan üçüncü taraf bileşenlerin listesi ve lisansları teslimle birlikte verilir.

Kaynak kod deposunun sahibi kimse, projenin pratik sahibi odur. Depoyu kendi kurumsal GitHub/GitLab hesabınızda açıp geliştirici ekibi oraya davet etmek, sözleşmedeki devir maddesinden daha hızlı işleyen bir güvencedir: iş biterse erişimi kapatırsınız, kod zaten sizdedir.

Kabul kriterleri: “bitti” ne demek?

Sözleşmelerin en çok tartışma üreten boşluğu burasıdır. Teslim ile kabul aynı şey değildir: teslim geliştiricinin işi verdiği an, kabul sizin “beklediğim buydu” dediğiniz andır. Sözleşmede kabul için bir süre (tipik olarak 5-15 iş günü) ve bu sürede sessiz kalınırsa ne olacağı yazılı olmalıdır. “Süre içinde itiraz edilmezse kabul edilmiş sayılır” maddesi standarttır ve makuldür; karşılığında testi yapacak kişiyi ve o kişinin o hafta müsait olacağını siz garanti etmek zorundasınız.

• Engelleyici (blocker) — iş akışı hiç çalışmıyor. Kabulü engeller, düzeltilene kadar kabul süresi durur.
• Yüksek — çalışıyor ama yanlış sonuç üretiyor. Kabulü engeller; veri bozan hatalar her zaman bu sınıftadır.
• Düşük / kozmetik — hizalama, yazım hatası, ikincil metin. Kabulü engellemez, garanti kapsamında düzeltilir.
• Her sınıf için düzeltme süresi ve yeniden test hakkı yazılır; tekrar testin ek ücrete tabi olmadığı belirtilir.

Kabul kriterini “sipariş ekranı düzgün çalışacak” diye yazmak, ölçülemediği için hiçbir şey yazmamakla aynıdır. Ölçülebilir hâli şudur: “1.000 satırlık siparişte liste 2 saniyenin altında yüklenir; 50 eşzamanlı kullanıcıda hata oranı %1’in altında kalır; onay akışı yetkisiz kullanıcının onayını reddeder.” Bu kriterler kapsamı ve dolayısıyla adam-günü doğrudan etkilediği için teklif aşamasında konuşulmalıdır — hangi kalemin fiyatı nasıl belirlediğini özel yazılım maliyeti yazısında ayrıntılandırdık.

Kapsam değişikliği prosedürü sözleşmede yazılı olmalı

Hiçbir proje ilk gün yazıldığı kapsamla bitmez; sözleşmenin görevi değişimi yasaklamak değil, fiyatını ve takvim etkisini önceden belirlenmiş bir yola sokmaktır. Sabit fiyat, adam-gün ve hibrit modellerden hangisinin size uygun olduğu ayrı bir tartışmadır; burada belirleyici olan, hangi model seçilirse seçilsin değişiklik akışının maddeye bağlanmasıdır.

• Talep yazılı gelir; e-posta yeterlidir, sözlü talep işleme alınmaz.
• Geliştirici etki analizi verir: ek adam-gün, ek bedel ve teslim tarihine etkisi birlikte.
• Yazılı onay olmadan iş başlamaz — onaysız yapılan iş faturalanamaz. Bu madde iki tarafı da korur.
• Onaylanan her değişiklik takvimi otomatik günceller; “tarih sabit kalsın, kapsam da artsın” diye bir seçenek yoktur.
• Küçük işler için aylık serbest kota tanımlayın (örneğin 2 adam-gün). Aksi hâlde her metin değişikliği için teklif yazışması yapılır.

Ödeme planı: son dilim teslimde değil kabulde

Ödeme takvimini takvim tarihlerine bağlamak iki tarafı da cezalandırır: tarih gelir, iş bitmemiştir, ödeme tartışma konusu olur. Doğru bağlama noktası kabul edilmiş çıktılardır.

• Başlangıç ödemesi %20-30 — ekip ayırma ve analiz maliyetinin karşılığı.
• Ara dilimler, her biri bir kilometre taşının kabulüne bağlı: analiz onayı, ilk modül kabulü, entegrasyon testi.
• Son dilim canlıya alma değil, kabul sonrası ödenir; %10-20 arası bir bakiyenin garanti dönemine bırakılması yaygındır.
• Karşılıklı gecikme maddesi: müşteri onayı, veri ya da erişim gecikirse takvim de uzar. Tek taraflı ceza maddeleri kısa vadede güven verir, uzun vadede pazarlığı zorlaştırır.

Garanti ile bakım aynı madde olmamalı

Garanti, teslim edilen kapsamdaki hataların ücretsiz düzeltilmesidir ve süreye bağlıdır (tipik olarak 3-12 ay). Bakım ise ayrı bir sözleşmedir: güncellemeler, izleme, yedekleme, küçük iyileştirmeler ve yeni istekler. İkisi tek maddede birleştirilirse her talepte “bu hata mı, yeni özellik mi” tartışması çıkar. Ayırmanın pratik ölçütü şudur: kapsam ekinde yazılı bir davranış çalışmıyorsa hatadır (garanti), kapsam ekinde olmayan bir davranış isteniyorsa yeni iştir (bakım ya da değişiklik talebi). Bakımın yıllık bütçedeki ağırlığını web sitesi bakım ücreti yazısında rakamlarla anlattık.

• Destek saatleri: mesai içi mi, 7/24 mü? Fiyat farkını yaratan en büyük kalem budur.
• Yanıt süresi ile çözüm süresi ayrı ayrı yazılır — “4 saat içinde dönüş” bir çözüm taahhüdü değildir.
• Önem sınıfları ve her sınıf için ayrı süre.
• Aylık dâhil saat ve aşım birim ücreti.
• Tek bir kayıt kanalı. WhatsApp üzerinden yürüyen destek ölçülemez, dolayısıyla SLA da denetlenemez.

KVKK: veri işleyen ilişkisi sözleşmede tanımlansın

Projede kişisel veri işleniyorsa — müşteri kaydı, personel bilgisi, sipariş adresi — roller nettir: siz veri sorumlususunuz, yazılım firması sizin adınıza veri işleyendir ve teknik güvenlik tedbirlerinden müştereken sorumlusunuzdur. Sözleşmeye girmesi gerekenler: verinin hangi ülkede ve hangi bulutta tutulacağı, test/geliştirme ortamında gerçek müşteri verisinin kullanılmayacağı (maskeleme), erişimi olan personelin sınırlanması, proje bitiminde verinin iadesi ya da silinmesi ve bir ihlal durumunda size kaç saat içinde bildirim yapılacağı. Uygulama tarafındaki gereklilikleri KVKK uyumlu web sitesi yazısında topladık.

Fesih ve çıkış maddesi: en çok atlanan bölüm

Sözleşmeler her şeyin yolunda gideceği varsayımıyla yazılır; oysa en çok ihtiyaç duyulan madde ilişkinin bittiği anda devreye girer. Çıkış maddesinin işlevi, projenin ortasında ayrılsanız bile elinizde devredilebilir bir şey kalmasıdır.

• O güne kadar üretilmiş kaynak kodun ve dokümantasyonun teslimi — fesih sebebinden bağımsız olarak.
• Depo, sunucu, bulut ve üçüncü taraf servis erişimlerinin devri; şifre değil, hesap sahipliği düzeyinde.
• Devir desteği: yeni ekibe aktarım için belirli bir adam-gün (örneğin 5-10 gün) ve bunun bedeli baştan yazılı.
• Ödenmemiş bakiye ile teslim yükümlülüğünün ilişkisi. “Ödeme yapılmadan kod verilmez” makuldür, ancak kapsamı sınırlı ve karşılıklı olmalıdır.

Bu bölümün en sık kaçırılan ayrıntısı hesap sahipliğidir. Alan adı, hosting ve bulut aboneliği, App Store ile Google Play geliştirici hesabı, ödeme sağlayıcısı üye iş yeri hesabı — bunlar firmanın adına açıldıysa sözleşmede ne yazarsa yazsın ürünün pratik sahibi firmadır. Kural basit: hesaplar parayı ödeyen tarafın kurumsal kimliğiyle açılır, geliştiriciye yetki verilir. Mağaza hesabının kimin adına açılacağını Play Store uygulama yayınlama ücreti yazısında da ayrıca ele aldık.

Sözleşmeyi bozan beş hata

• Kapsamı e-posta yazışmalarında bırakmak. Sözleşmenin konusu tek satırsa, altı ay sonra iki taraf da kendi e-postasını gösterir.
• Fiyatı sabitleyip kapsamı sabitlememek. Sabit fiyat yalnızca sabit kapsamla anlamlıdır; kapsam açıkken sabit fiyat ya kaliteden ya ilişkiden çıkar.
• Hak devrini “proje bitince hallederiz”e bırakmak. Devir konusundaki pazarlık gücünüz imzadan önce en yüksek seviyededir.
• Kabul kriteri yazmadan ödeme takvimini tarihlere bağlamak.
• Altyapı ve mağaza hesaplarını geliştiricinin adına açtırmak.

Sonuç

İyi bir yazılım sözleşmesi tarafları birbirine karşı korumaktan çok, ikisinin de aynı şeyi anladığını kanıtlar. Pratikte bunu yapan şey uzun hukuki metin değil, dört ek belgedir: kapsam dokümanı, kabul kriterleri, ödeme kilometre taşları ve çıkış planı. Bu dördü yazılıysa geri kalan maddeler büyük ölçüde standarttır. Firma seçme ölçütlerini kurumsal yazılım firması seçimi yazısında topladık; projenizin kapsamını birlikte çıkarıp sözleşmeye dönüştürülebilir bir teklif hazırlamamız için özel yazılım geliştirme hizmetimize göz atabilir ya da teklif alabilirsiniz. Bu yazı genel bilgilendirme amaçlıdır; hukuki danışmanlık yerine geçmez, imzadan önce sözleşmeyi avukatınıza inceletin.