Yazılım Sözleşmesinde Dikkat Edilecek 8 Madde (2026): Kapsam, Kabul, Ödeme Planı ve Fesih

Yazılım sözleşmesi, bir projede çıkabilecek tartışmaların çoğunu daha başlamadan karara bağlar. Yazılım projelerindeki anlaşmazlıklar nadiren kötü niyetten çıkar; çoğu, iki tarafın farklı şeyler anlamasına izin veren ifadelerden doğar. Yazılım elle tutulamayan bir üründür ve müşteriyle geliştiricinin 'bitti' derken kastettiği şey çoğu zaman aynı değildir. Bu yazı imzadan önce kontrol etmenizi önerdiğimiz sekiz maddeyi ve görünce durmanız gereken ifadeleri sade bir dille anlatıyor. Genel bilgilendirmedir, hukuki tavsiye değildir; büyük ya da yoğun veri işleyen projelerde sözleşmeyi bir avukata okutun. Henüz firma seçiyorsanız yazılım outsource kırmızı bayrakları rehberimiz bu yazının iyi bir tamamlayıcısı.

Yazılım sözleşmesi neden bu kadar önemli?

Sözleşme, 'ne konuşmuştuk' sorusunun hafızadan çıkıp iki tarafın da gösterebileceği bir belgeye dönüştüğü yerdir. Kapsamı, süreyi ve bedeli yazılı hâle getirmek hem müşteriyi hem geliştiriciyi korur. Türk hukukunda teslim edilecek belirli bir çıktısı olan yazılım geliştirme işi genellikle Türk Borçlar Kanunu (TBK) m. 470 anlamında eser sözleşmesi olarak değerlendirilir; geliştirici bir sonucu taahhüt eder. Bu nitelendirmenin pratik sonuçları var, örneğin iş sahibinin eseri gözden geçirme ve ayıpları bildirme yükümlülüğü; aşağıdaki maddelerin önemi de buradan geliyor. Sözleşmesiz ya da belirsiz sözleşmeli projeler, kapsam kaymasının, gecikmenin ve ödeme tartışmalarının en sık görüldüğü projelerdir.

1. Kapsam ve teslimatlar net yazılmış mı?

Kapsam maddesi neyin yapılacağını ve neyin yapılmayacağını söylemelidir. 'Kurumsal web sitesi' gibi genel ifadelerin yerine somut kalemler yazın: sayfa ya da ekran sayısı, modüller, entegrasyonlar, desteklenen diller, hedef cihazlar ve tarayıcılar. Kapsam dışında kalanları yazmak, kapsama girenleri yazmak kadar önemlidir; sonradan çıkacak 'bu zaten dahildi' tartışmasını önler. Brief'i ya da teknik şartnameyi sözleşmeye ek olarak bağlayın; içinde ne olması gerektiğini yazılım projesi brief'i rehberimizde anlattık. Kapsam değişirse bunun nasıl fiyatlanacağını da ilk değişiklik gelmeden yazın.

2. Kaynak kod ve fikri haklar kime ait?

Kodun sahipliği açık ve yazılı bir devir ister; projenin bedelini ödemek hakları tek başına size geçirmez. 5846 sayılı FSEK bilgisayar programlarını eser sayar ve 52. maddesi mali hakların devrinin yazılı olmasını ve hakların tek tek gösterilmesini şart koşar. 'Kaynak kod ve bütün mali haklar ödemenin tamamlanmasıyla müşteriye devrolur' gibi açık bir ifade arayın; firmanın kendi hazır bileşenlerinin ve açık kaynak kütüphanelerin hangi lisansla kullanıldığını da sorun. İlgili maddeleri, 2020 tarihli Yargıtay kararını ve sözleşmeye yazılacak hükümleri kaynak kod mülkiyeti rehberimizde ayrıntılı anlattık; burada kısa tutuyoruz: sahiplik belirsizse ileride firma değiştirmek çok zorlaşır.

3. Kabul kriterleri ve test süreci tanımlı mı?

Teslim ile kabul farklı şeylerdir ve sözleşme işin hangi durumda kabul edilmiş sayılacağını tanımlamalıdır. TBK m. 474'e göre iş sahibi teslim edilen eseri işlerin olağan akışına göre imkân bulur bulmaz gözden geçirmek ve ayıpları uygun bir süre içinde bildirmek zorundadır; m. 477'ye göre sonradan ortaya çıkan ayıplar da gecikmeden bildirilmelidir. Yazılı bir kabul süreci bu yükümlülüğü yönetilebilir kılar: kabul testi ne kadar sürer, hatalar nasıl bildirilir, sonra ne olur. 'Teslimden sonraki 10 iş günü içinde bildirilen hatalar ücretsiz düzeltilir' gibi bir hüküm işleyişi netleştirir. Ölçülebilir kriterler kullanın: sayfa yüklenme hedefi, desteklenen tarayıcılar, ödeme akışının başarıyla tamamlanması gibi. Kriter yoksa kabul iki tarafın görüşüne kalır.

4. Ödeme planı iş ilerlemesine bağlı mı?

Sağlıklı bir ödeme planı ödemeleri analiz onayı, tasarım teslimi, test sürümü ve canlıya alma gibi kilometre taşlarına bağlar. Bedelin tamamını peşin ödemek ciddi bir risktir, çünkü teslimat üzerindeki etkinizi ortadan kaldırır. Firmanın emeğini korumak için avans istemesi ise makuldür. Uygulanabilir denge; avans, aşamalara bağlı ara ödemeler ve teslimden sonraya bırakılan bir bakiyedir. Fiyatın sabit mi saatlik mi olduğunu, KDV ve fatura koşullarını da yazdırın.

5. Revizyon ve değişiklik talebi nasıl işliyor?

Her projede değişiklik olur; mesele değişikliğin nasıl ele alınacağıdır. Sözleşme fiyata kaç tur revizyonun dahil olduğunu ve kapsam dışı taleplerin nasıl teklif edileceğini belirtmelidir. Yazılı bir değişiklik talebi (change request) süreci müşteriyi sürpriz faturalardan, firmayı da bitmeyen revizyondan korur. Onaylanan her değişikliğin bedele ve süreye etkisi, iş başlamadan yazılı hâle gelmelidir. Bu düzen, proje ortasında biriken gerginliğin çoğunu önler.

6. Gizlilik ve kişisel veri hükümleri var mı?

Yazılım firmanız süreçlerinizi, müşteri verilerinizi ve ticari sırlarınızı görebilir; bu yüzden sözleşmede bir gizlilik maddesi, kişisel veri varsa veri koruma hükümleri olmalıdır. Gizlilik (NDA) maddesi bu bilgilerin üçüncü kişilerle paylaşılmasını ve amaç dışı kullanılmasını yasaklamalıdır. Proje kişisel veri işliyorsa firma veri işleyen konumundadır ve 6698 sayılı KVKK'nın 12. maddesine göre veri sorumlusu, gerekli güvenlik tedbirlerinin alınmasından veri işleyenle birlikte müştereken sorumludur; o tedbirleri sözleşmeye yazın. Test ortamında gerçek müşteri verisi kullanılıp kullanılmayacağını sorun. Yurt dışında sunucu ya da alt yüklenici kullanılıyorsa bunun açıkça belirtilmesini isteyin; sitenin kendi yükümlülüklerini KVKK uyumlu web sitesi kontrol listemizde topladık.

7. Garanti ve teslim sonrası destek ne kadar?

Yayından sonra bulunan hataların ücretsiz düzeltileceği bir garanti süresi tanımlayın ve bunu yeni özellik taleplerinden açıkça ayırın. Sözleşme sürenin ne kadar olduğunu ve neyin değişiklik değil hata sayılacağını belirtmelidir. Uzun vadeli bakım ayrı bir sözleşmeyle yapılabilir; genellikle neleri kapsadığını ve ne tuttuğunu web sitesi bakım maliyeti rehberimizde anlattık. Yanıt süresinin ve çözüm süresinin ayrı tanımlandığından emin olun. Garantisiz bir teslim, ilk ay çıkan hatalar için ek ödeme yapmanıza yol açabilir.

8. Fesih ve proje devri koşulları neler?

Hiçbir taraf projenin yarıda kalmasını planlamaz, ama sözleşme planlamalıdır. Hangi durumlarda tarafların feshedebileceğini ve fesihte o güne kadar yapılan işin bedelinin ve tesliminin nasıl ele alınacağını yazmalıdır. En önemli hüküm, o ana kadar üretilen kodun ve dokümanların size teslim edileceğidir. Kod deposuna (repository) sizin de erişiminizin olması, firmanın kapanması ya da ekibin değişmesi gibi risklere karşı güvence sağlar. Cezai şartı ve gecikme tazminatını ölçülü tutun: Türk Ticaret Kanunu m. 22'ye göre tacir, TBK m. 182'nin başkalarına tanıdığı fahiş cezai şartın indirilmesini kural olarak mahkemeden isteyemez; yani şişirilmiş bir cezai şartı imzalayan şirket ona bağlı kalabilir.

Hangi ifadeler kırmızı bayraktır?

Kapsamın 'ihtiyaca göre belirlenecektir' gibi ifadelerle açık bırakıldığını gördüğünüzde durun. Bedelin tamamının peşin istenmesi, kaynak kodun teslim edilmeyeceğinin ima edilmesi ya da yalnızca firma lehine tek taraflı fesih hakkı ciddi uyarı işaretleridir. Hiç kabul kriteri olmayan bir sözleşme, 'sınırsız revizyon' vaadi kadar sorunludur, çünkü ikisi de pratikte uygulanamaz. Yazılı sözleşme yapmak istemeyen bir firmaya projenizi emanet etmeyin. Seçim sürecinin geri kalanı için Türkiye'de yazılım şirketi seçimi rehberimize bakın.

İmzadan önce neleri kontrol etmelisiniz?

İmzalamadan önce altı soruyu cevaplayabiliyor olmalısınız: ne, ne zaman teslim edilecek; kod ve haklar kime geçiyor; 'bitti' nasıl ölçülüyor; ödemeler hangi aşamalara bağlı; kapsam değişirse ne olacak; sorun çıkarsa kim, ne kadar sürede çözecek. Sözleşme uzunsa ya da bütçe büyükse bir avukata okutmak, olası bir anlaşmazlığın maliyeti yanında küçük bir harcamadır. Bu yazı genel bilgilendirme amaçlıdır ve hukuki danışmanlığın yerini tutmaz.