Mobil Uygulama Geliştirme Sözleşmesinde Bulunması Gereken Maddeler

Bir ajansla veya freelancer ile çalışmaya karar verdiğinizde, iş genellikle bir teklif e-postası veya WhatsApp mesajıyla başlar — ama asıl güvenceniz yazılı bir sözleşmedir. Bu yazıda, fikrinizi paylaşmadan önce imzalanan gizlilik sözleşmesinden (NDA) farklı olarak, işin kapsamını ve teslimini düzenleyen asıl geliştirme sözleşmesinde bulunması gereken maddeleri anlatıyoruz.

Geliştirme Sözleşmesi Hukuken Ne Tür Bir Sözleşmedir?

Türk hukukunda bir yazılım/uygulama geliştirme sözleşmesi, genellikle 6098 sayılı Türk Borçlar Kanunu'nun 470. maddesinde tanımlanan "eser sözleşmesi" çerçevesinde değerlendirilir: yüklenicinin (geliştiricinin) bir eser meydana getirmeyi, iş sahibinin (sizin) de bunun karşılığında bir bedel ödemeyi üstlendiği sözleşme türü. Bu genel çerçeveyi bilmek, sözleşmenizde hangi hak ve yükümlülüklerin standart olarak beklenebileceğini anlamanıza yardımcı olur.

Sözleşmede Bulunması Gereken Temel Maddeler

Kaynak Kodu ve Fikri Mülkiyet Devri Maddesi

Bu, birçok girişimcinin sözleşmede es geçtiği ama en kritik maddelerden biridir. Sözleşmede, teslim ile birlikte kaynak kodunun ve fikri mülkiyet haklarının size devredildiği açıkça yazılı olmalıdır. Bu madde olmadan, geliştirdiğiniz uygulama üzerindeki haklarınız belirsiz kalabilir ve ileride farklı bir ekiple devam etmek istediğinizde sorun yaşayabilirsiniz.

Revizyon ve Değişiklik Talebi Maddesi

"Sınırsız revizyon" vaadi kulağa cazip gelse de pratikte nadiren gerçekçidir; büyük ajanslar dahi revizyon hakkını belirli bir sayı veya aşamayla sınırlar. Sözleşmenizde kaç revizyon hakkının ücretsiz olduğu, bu hakların hangi aşamada kullanılabileceği ve bu sınırın ötesindeki taleplerin nasıl ücretlendirileceği net yazılmalıdır. Bu netlik, hem sizi hem geliştiriciyi belirsiz beklentilerden korur.

Gecikme ve Fesih Şartları

Her proje planlandığı gibi gitmeyebilir. İyi bir sözleşme, gecikmenin hangi tarafın kusurundan kaynaklandığına göre (ör. müşterinin geç geri bildirim vermesi ile geliştiricinin geç teslim etmesi farklı sonuçlar doğurur) nasıl ele alınacağını tanımlar. Ayrıca projenin herhangi bir aşamada feshedilmesi durumunda, o ana kadar tamamlanan işin ve ödemenin nasıl ele alınacağı da netleştirilmelidir.

Teslim Sonrası Garanti Süresi

Teslim, projenin bittiği anlamına gelmez — teslim sonrası kısa bir sürede ortaya çıkabilecek hatalar için bir garanti/hata düzeltme süresi tanımlanmalıdır. Bu süre genellikle birkaç haftadan birkaç aya kadar değişebilir ve yalnızca teslim edilen kapsamdaki hataları kapsar; yeni özellik talepleri bu sürenin dışındadır. Bu ayrımın sözleşmede net yazılması, teslim sonrası ilk haftalarda çıkabilecek küçük sorunların nasıl ele alınacağını baştan netleştirir.

Ödeme Planının Sözleşmedeki Yeri

Ödeme planı, sözleşmenin en somut ve en çok anlaşmazlığa açık maddelerinden biridir. Tek seferlik geliştirme ücretinin hangi aşamalarda (proje başında, teslimde, ara kilometre taşlarında) ödeneceği net şekilde yazılmalı; barındırma gibi aylık kalemler varsa bunların ayrı bir madde olarak ele alınması gerekir. Ödeme planının netliği, hem sizi hem geliştiriciyi ilerleyen aşamalarda "bu ödeme ne zaman yapılacaktı" belirsizliğinden korur.

Bir girişimcinin, tanıdığı bir freelancer ile sözlü olarak anlaştığı bir proje düşünelim. İş ilerledikçe girişimci sürekli küçük değişiklikler istiyor, freelancer da her seferinde kabul ediyor — ta ki proje, başlangıçta konuşulanın çok ötesine geçene kadar. Freelancer ek ücret talep ettiğinde, girişimci "bunun dahil olduğunu düşünmüştüm" diyor; freelancer ise "bu kadar revizyonu ücretsiz yapmayı hiç kabul etmedim" diyor. Yazılı bir sözleşme ve net bir revizyon maddesi olsaydı, bu anlaşmazlık büyük olasılıkla hiç yaşanmayacaktı — her iki taraf da baştan hangi noktada ek ücretin devreye gireceğini bilecekti.

Sözleşme İmzalarken Sık Yapılan Hatalar

En sık düşülen üç hata şöyle: Birincisi, "güvendiğim biri" gerekçesiyle sözleşmeyi atlamaktır — güven, yazılı bir sözleşmenin yerini tutmaz; ikisi birbirini dışlamaz. İkincisi, kaynak kodu devrini sözleşmede açıkça yazmamaktır — bu madde olmadan, uygulamanız üzerindeki haklarınız belirsiz kalabilir. Üçüncüsü, revizyon sınırını belirsiz bırakmaktır — "makul sayıda revizyon" gibi muğlak ifadeler, her iki tarafın da farklı bir "makul" tanımına sahip olmasına yol açabilir.

mobilsepeti.com.tr'de Sözleşme Süreci

Projeye başlamadan önce kapsamı, ödeme planını ve teslim şartlarını yazılı olarak netleştiririz; kaynak kodu teslim aşamasında size verilir. Fikrinizi ilk paylaştığınızda gizliliğin nasıl korunduğunu merak ediyorsanız fikir koruma rehberimize, teklif aşamasında nelere dikkat etmeniz gerektiğini merak ediyorsanız teklif rehberimize göz atabilirsiniz.