Yazılım Geliştirme Sözleşmesinde Neye Bakılır?

Yazılım sözleşmesinin belirleyici maddeleri şunlardır: kapsam eki, mali hak devri, kaynak kod teslimi, kabul kriterleri, ödeme takvimi, gecikme, bakım ve fesih. FSEK 52’ye göre mali hak devri yazılı olmak ve devredilen haklar ayrı ayrı gösterilmek zorundadır; “tüm haklar devredilmiştir” cümlesi bu şartı karşılamaz.

Yazılım sözleşmeleri genelde iki durumda okunur: imzadan hemen önce aceleyle ve iş ters gittiğinde dikkatle. İkinci okumada anlaşılan şey her seferinde aynıdır — tartışılan konu sözleşmede ya hiç yok ya da muğlak yazılmış. Aşağıdaki 12 madde, o ikinci okumada aranan maddelerin listesidir.

Hukuki çerçeve: iki kanun

Eser sözleşmesi. Yazılım geliştirme işi, Türk Borçlar Kanunu’nun eser sözleşmesi hükümlerine (madde 470 ve devamı) tabidir: yüklenici bir eser meydana getirmeyi, iş sahibi de bedel ödemeyi üstlenir. Kanun metni mevzuat.gov.tr üzerinde.

Fikri haklar. Yazılım, 5846 sayılı Fikir ve Sanat Eserleri Kanunu kapsamında korunur. Kanunun 52. maddesi, mali haklara dair sözleşme ve tasarrufların yazılı olmasını ve konuları olan hakların ayrı ayrı gösterilmesini şart koşar. Kanun metni mevzuat.gov.tr üzerinde.

İkinci maddenin pratik sonucu şu: “tüm mali haklar devredilmiştir” biçiminde yazılmış bir devir maddesi, şartı karşılamadığı gerekçesiyle tartışmaya açık kalır. Devredilen hakların tek tek sayılması, süre ve yer sınırının belirtilmesi gerekir.

Bu yazı hukuki görüş değildir; sözleşmenizi imzalamadan önce avukatınıza okutun. Burada anlatılan şey, avukata götürmeden önce sizin kontrol edebileceğiniz maddelerdir.

12 madde ve her birinde aranan cümle

1. Kapsam eki

Sözleşmenin gövdesinde kapsam anlatılmaz; ek olarak bağlanır ve ekin sözleşmenin ayrılmaz parçası olduğu yazılır. Ek, teklif aşamasında hazırlanan şartname veya analiz belgesidir.

Aranan cümle: “Ek-1’de tanımlanan kapsam sözleşmenin ayrılmaz parçasıdır. Kapsam değişiklikleri yazılı ek protokolle yapılır.”

Şartnamenin nasıl yazıldığını yazılım şartnamesi nasıl yazılır yazısında ele aldık.

2. Kapsam dışı listesi

Yapılmayacakların yazılı olması, yapılacakların yazılı olması kadar önemli. Veri aktarımı, eğitim, donanım, mevcut sistemlerin lisansları — bunlardan hangileri kapsam dışıysa sayılmalı.

3. Mali hak devri

Devredilen haklar ayrı ayrı sayılır. Süre sınırsız mı, yer sınırı var mı, devir yetkisi (üçüncü kişiye devredebilme) var mı — üçü de yazılır. Yüklenicinin kendi genel kütüphanelerini başka projelerde kullanabileceği bir istisna varsa o da açıkça belirtilir; bu makul bir istisnadır ama sınırı yazılmalıdır.

4. Kaynak kod teslimi

Üç şey yazılır: ne teslim edilecek (kaynak kod, veritabanı şeması, kurulum dokümanı, yapılandırma dosyaları), ne zaman (kabul ile birlikte, aşama sonlarında), nasıl (sürüm kontrol deposu erişimi, arşiv dosyası).

Aranan cümle: “Kaynak kod ve kurulum dokümantasyonu, her aşamanın kabulü ile birlikte iş sahibine teslim edilir.”

Kaynak kodun neden bu kadar belirleyici olduğunu kod sahipliği ve lock-in yazısında ayrıntılı ele aldık.

5. Veri sahipliği ve barındırma

Verinin sahibi iş sahibidir; bu cümle sözleşmede geçmeli. Barındırma yüklenicinin sunucusundaysa şunlar yazılır: yedekleme sıklığı, verinin hangi ülkede tutulduğu, sözleşme sona erdiğinde verinin hangi formatta ve kaç gün içinde teslim edileceği.

Son madde en çok atlanan ve en pahalıya patlayan maddedir. Barındırma ve veri konusunu kurumsal yazılım güvenliği: verileriniz nerede yazısında ele aldık.

6. Kabul kriterleri ve tutanak

Kriter listesi sözleşme ekinde durur. Kabul süreci yazılır: teslim bildirimi, test süresi (5-10 iş günü tipiktir), itiraz hakkı, itiraz edilmezse kabul sayılma kuralı.

Aranan cümle: “Teslim bildiriminden itibaren 10 iş günü içinde yazılı itiraz gelmezse teslim kabul edilmiş sayılır.” Bu kural iki tarafı da korur: yüklenici sonsuza kadar bekletilmez, iş sahibi de habersiz kabul edilmiş sayılmaz.

7. Ödeme takvimi

Ödemeler teslimlere bağlanır, takvime değil. Tipik yapı: sözleşme imzasında bir avans, her aşama kabulünde bir dilim, son kabulde kalan bakiye.

Son dilimin makul büyüklükte olması önemlidir; %5’lik son dilim yükleniciyi kabul aşamasında motive etmez.

8. Değişiklik yönetimi

Kapsam değişikliği talebinin nasıl işleneceği yazılır: talep yazılı gelir, yüklenici süre ve bedel etkisini bildirir, iş sahibi onaylarsa uygulanır. Onaysız yapılan iş için bedel talep edilemez.

Bu madde olmadan proje ortasında iki taraf da haklı çıkar ve tartışma kişisel hale gelir.

9. Gecikme ve karşılıklı yükümlülük

Yazılması gereken	Neden
Yüklenicinin gecikme yaptırımı	Termin disiplini
İş sahibinin yükümlülükleri (veri, erişim, onay, test kaynağı)	Gecikmelerin bir kısmı buradan doğar
Gecikme sayacının durduğu haller	İş sahibi kaynaklı beklemeler
Üst sınır	Yaptırımın orantılı kalması

Tek taraflı yazılmış gecikme maddeleri uygulamada işlemez; ilk anlaşmazlıkta “biz beklettik mi siz mi” tartışması başlar ve madde askıda kalır.

10. Garanti

Garanti süresi (3-12 ay tipiktir), kapsamı (kapsamda tanımlanmış işlevin hatalı çalışması) ve kapsam dışı (yeni özellik talebi, kullanıcı hatası, üçüncü taraf sistem değişikliği) yazılır. Garanti süresinin ne zaman başladığı da net olmalı: kabulden mi, canlıya geçişten mi?

11. Bakım

Bakımın isteğe bağlı olduğu ve alınmadığında sistemin çalışmaya devam ettiği yazılır. Ayrıca: kapsam, hata sınıfları ve müdahale süreleri, yıllık bedel ve artış kuralı, bakım almadan sonradan başlama şartları.

Bakım maliyetlerinin nasıl hesaplandığını yazılım bakım maliyeti yazısında ele aldık.

12. Fesih ve devir

Fesih halleri (haklı sebep, karşılıklı anlaşma), fesih anında tamamlanmış işin bedeli, teslim edilecekler ve verinin iadesi yazılır. Yüklenicinin işi başka bir firmaya devretmesi izne bağlanır.

Bir de sessizce atlanan bir madde var: yüklenici firma kapanırsa ne olur? Kaynak kodun düzenli teslim edildiği bir sözleşmede bu risk zaten yönetilmiştir; kod teslimi yoksa emanet (escrow) düzenlemesi konuşulmalıdır. Bu, kodu elinde tutan tedarikçiler için geçerli bir sorudur; KodDelta escrow sunmuyor, çünkü kod her adımda teslim edildiği için emanet edilecek bir şey kalmıyor.

KVKK tarafı: veri sorumlusu ve veri işleyen ayrımı

Yazılım sözleşmelerinin çoğunda tek satırlık bir “KVKK’ya uyulacaktır” cümlesi bulunur ve o cümle hiçbir şey düzenlemez. Düzenlenmesi gereken şey iki taraf arasındaki rol dağılımıdır.

Kişisel Verilerin Korunması Kanunu iki rol tanımlar: verinin işlenme amacını ve vasıtalarını belirleyen veri sorumlusu, ve onun verdiği yetkiye dayanarak veri işleyen taraf. Kanun metni mevzuat.gov.tr üzerinde; rehber ve kurul kararları için kvkk.gov.tr kaynaktır.

Yazılım projelerinde tipik dağılım şudur: müşteri şirket veri sorumlusudur, yazılım firması geliştirme ve bakım sırasında veriye eriştiği ölçüde veri işleyendir. Bu ayrımın sözleşmeye yansıması gereken maddeleri:

• Yazılım firmasının hangi verilere, hangi amaçla ve hangi süreyle erişeceği
• Erişimin kim tarafından, nasıl kayıt altına alınacağı
• Canlı veri üzerinde test yapılıp yapılamayacağı; yapılamayacaksa maskeleme yükümlülüğünün kimde olduğu
• Alt yüklenici kullanılacaksa iş sahibinin onayına bağlanması
• Verinin hangi ülkede tutulacağı ve yurt dışına aktarım olup olmayacağı
• Sözleşme sona erdiğinde yazılım firmasındaki kopyaların ne olacağı
• Veri ihlali durumunda bildirim süresi ve yükümlülük paylaşımı

Üçüncü madde pratikte en çok ihlal edilen maddedir: geliştirme ve hata ayıklama sırasında canlı veritabanının kopyası geliştirici bilgisayarına indirilir ve orada kalır. Sözleşmede maskeleme yükümlülüğü tanımlanmadığında bu, kimsenin fark etmediği sürekli bir risktir.

Güvenlik ve barındırma tarafındaki teknik önlemleri kurumsal yazılım güvenliği yazısında ele aldık.

Sözleşme öncesi kontrol listesi

• Kapsam eki hazır ve sözleşmenin ayrılmaz parçası olarak bağlanmış
• Kapsam dışı kalemler ayrı listede sayılmış
• Devredilen mali haklar tek tek yazılmış; süre ve yer sınırı belirtilmiş
• Kaynak kod teslimi: ne, ne zaman, nasıl — üçü de yazılı
• Verinin sahibi iş sahibi; sözleşme bitiminde teslim şekli ve süresi yazılı
• Kabul kriterleri ek olarak bağlanmış; kabul süresi ve itiraz hakkı tanımlı
• Ödeme dilimleri teslim kabullerine bağlı
• Değişiklik talebi süreci yazılı; onaysız iş için bedel talep edilemiyor
• Gecikme maddesi karşılıklı; sayacın durduğu haller sayılmış
• Garanti süresi, kapsamı ve başlangıç anı net
• Bakım isteğe bağlı; almayınca sistemin çalışmaya devam ettiği yazılı
• Fesih halinde teslim edilecekler ve veri iadesi tanımlı
• Gizlilik ve kişisel veri maddeleri KVKK yükümlülüklerinizle uyumlu
• Uyuşmazlık halinde yetkili mahkeme ve uygulanacak hukuk belirtilmiş

Riskli kalıplar ve düzeltilmiş halleri

Riskli ifade	Sorunu	Yerine
“Tüm fikri haklar devredilmiştir”	FSEK 52’nin ayrı ayrı gösterme şartını karşılamaz	Hakların tek tek sayıldığı liste
“Kaynak kod talep halinde verilir”	Talep zamanı ve şekli belirsiz	“Her aşama kabulüyle birlikte teslim edilir”
“Ödemeler ayda bir yapılır”	İş gecikse de ödeme doğar	Teslim kabullerine bağlı dilimler
“Sistem sorunsuz çalışacaktır”	Ölçülemez; kabul kriteri olamaz	Ekteki kriter listesi
“Bakım sözleşmesi zorunludur”	Yazılımı kiralık hale getirir	“Bakım isteğe bağlıdır; alınmadığında sistem çalışmaya devam eder”
“Gerekli görülen değişiklikler yapılır”	Sınırsız kapsam	Değişiklik yönetimi maddesi
“Veriler yüklenicide saklanır”	Sahiplik belirsiz	“Veri iş sahibine aittir; sözleşme sonunda X formatında Y gün içinde teslim edilir”

Teklif aşamasında sorulacaklar

Sözleşmeye gelmeden önce teklif görüşmesinde şu dördünü sorun; cevaplar sözleşme metnini büyük ölçüde belirler:

1. Kaynak kod teslim ediliyor mu, hangi aşamada?
2. Bakım almazsak sistem çalışmaya devam eder mi?
3. Barındırma nerede, veriyi ne zaman ve hangi formatta geri alabiliriz?
4. Kapsam değişikliği talebinde süre ve bedel nasıl hesaplanıyor?

Bu dört sorunun cevabı net gelmiyorsa sözleşme metni de net olmayacaktır. Firma seçerken sorulacak diğer soruları yazılım firması seçimi: 7 soru yazısında topladık; teslim sürecinin nasıl işlediğini yazılım projesi teslim süreçleri yazısında anlattık.

Bizim sözleşme yaklaşımımız

Dört maddeyi standart olarak yazıyoruz ve pazarlığa açmıyoruz: lisans ömür boyu, kullanıcı sayısı sınırsız, kaynak kod müşteriye teslim, bakım isteğe bağlı. Bakım almadığınızda sistem çalışmaya devam eder; bu cümle sözleşmede yazılıdır.

Kapsam ve bedel tarafı şu bantlara oturur:

Kapsam	Bant	Süre
Tek süreç	80.000 - 150.000 ₺	2-4 hafta
Çok süreçli kurgu	200.000 - 400.000 ₺	4-8 hafta
Şirket geneli sistem	500.000 ₺+	3-6 ay
Ek modül	8.000 - 45.000 ₺	—

Barındırma ilk yıl dahildir, sonrasında 4.800 veya 9.600 ₺/yıl. Yıllık bakım isteğe bağlıdır (%12, %18, %25). Bantların tamamı fiyat sayfasında, çalışma biçimimiz kurumsal yazılım sayfasında.

---

---

İlgili Bütçe Araçları ve Karşılaştırma Rehberleri

• Paket vs Özel 5 Yıllık TCO Hesaplayıcı — Kiralık SaaS lisansı ile özel yazılımın 5 yıllık maliyetini kıyaslayın.
• Yazılım Bütçe ve Süre Tahmincisi — İhtiyacınız olan modülleri seçerek bütçe ve teslim bandınızı görün.
• ERP Fiyat Listesi 2026 Karşılaştırması — Türkiye kurumsal ERP lisans ve bakım bedelleri.
• Özel Yazılım Teknik Şartnamesi (RFP) Rehberi — Bütçe aşımını önleyen şartname hazırlama kılavuzu.

Sıkça sorulan sorular

Kaynak kod teslimi otomatik hakkım değil mi?

Değil. Bedelini ödediğiniz şey sözleşmede ne yazıyorsa odur. Kaynak kodun teslim edileceği, hangi formatta ve hangi aşamada teslim edileceği ayrıca yazılmazsa yalnız çalışan yazılımı almış olursunuz. Teslimi kabul aşamasına bağlayın; proje bittikten sonra istenen kod çoğu zaman gecikir.

"Tüm fikri hakları devredilmiştir" cümlesi yeterli mi?

Yeterli değil. FSEK 52, mali haklara dair sözleşmelerin yazılı olmasını ve konuları olan hakların ayrı ayrı gösterilmesini şart koşuyor. Toplu ifadeler bu şartı karşılamıyor. İşleme, çoğaltma, yayma ve umuma iletim haklarının hangilerinin, hangi süre ve yer sınırıyla devredildiği tek tek yazılmalı.

Kabul tutanağı olmadan ödeme yapmalı mıyım?

Ödeme takvimi teslimlere bağlanmalı, takvime değil. "Üçüncü ay sonunda %30" biçiminde yazılan maddeler, iş gecikse bile ödeme doğurur. Doğru yazım şu: her ödeme dilimi bir teslimin kabulüne bağlanır ve kabul kriterleri sözleşme ekinde listelenir.

Gecikme cezası koymalı mıyım?

Koyun ama tek taraflı olmasın. Gecikmelerin bir kısmı alıcıdan kaynaklanır: veri gecikmesi, onay bekleyen karar, erişim verilmemesi. Sözleşmede her iki tarafın yükümlülükleri ve gecikme sayacının hangi durumlarda durduğu yazılmalı. Aksi halde madde uygulanamaz hale gelir ve iki taraf da suçlu arar.

Bakım sözleşmesi zorunlu olmalı mı?

Olmamalı. Bakım almadığınızda sistemin çalışmaya devam ettiği açıkça yazılmalı. Bakımı zorunlu kılan veya bakım bitince sistemi durduran maddeler, bedelini ödediğiniz yazılımı kiralık hale getirir. Bakımın kapsamı, müdahale süreleri ve fiyat artış kuralı ayrıca yazılır.

İlgili rehberler

• Mobil uygulama seçimi: PWA mı, native mi? Kurumsal saha ve maliyet rehberi
• En iyi yazılım şirketleri 2026: Türkiye'deki kurumsal yazılım firmaları sıralaması
• ERP şartnamesi ve ihtiyaç analizi şablonu 2026: Başarısızlığı önleyen 16 maddelik RFP rehberi

Hizmet sayfası: Kurumsal yazılım hizmeti