Yazılım · 31 Ekim 2026 · 7 dk okuma
Uygulama Yaptırırken Sözleşmeye Mutlaka Yazılması Gerekenler (Kaynak Kodu, Mülkiyet)
Uygulama teslim edildi, ama kaynak kodu kimde, mağaza hesabı kimin adına, sunucu şifresi nerede? Sorun çıktığında tek dayanağınız sözleşmedir. Hangi maddelerin mutlaka yazılması gerektiğini anlattık.

Projeye başlarken herkes iyi niyetlidir. Toplantılar sıcak geçer, teklif kabul edilir, ilk ödeme yapılır ve sözleşme çoğu zaman bir iki sayfalık genel bir metin olarak imzalanır. Sorunlar ise genellikle aylar sonra çıkar: Yazılım ekibi değişir, iş birliği biter ya da uygulamaya yeni bir özellik eklemek istersiniz ve kaynak kodunun sizde olmadığını fark edersiniz. İşte o noktada elinizdeki tek dayanak, imzaladığınız yazılım sözleşmesidir.
Bu yazıda uygulama ya da web yazılımı yaptırırken sözleşmede mutlaka yer alması gereken maddeleri, yazılım tarafında çalışan bir ekip olarak sahada gördüklerimizle anlatıyoruz. Baştan önemli bir not: Bu içerik hukuki tavsiye değildir. Sözleşme metninizi imzalamadan önce mutlaka bir hukukçuya inceletin. Bizim amacımız, hukukçunuzla konuşurken hangi konuları masaya getirmeniz gerektiğini netleştirmek.
Yazılım Sözleşmesi Neden Bu Kadar Önemli?
Bir mobil uygulama ya da özel yazılım, tamamlandıktan sonra da yaşamaya devam eden bir varlıktır. Güncellenir, yeni sürümleri çıkar, başka sistemlere bağlanır, belki bir gün başka bir ekibe devredilir. Bu yüzden yazılım sözleşmesi yalnızca "ne yapılacak, kaça yapılacak" sorusunu değil, "iş bittikten sonra ne olacak" sorusunu da cevaplamalıdır.
Pratikte karşılaşılan anlaşmazlıkların çoğu aynı birkaç konudan doğar:
- Kaynak kodunun teslim edilmemesi ya da eksik teslim edilmesi
- Uygulama mağazası, sunucu veya alan adı hesaplarının yazılım firmasının adına açılmış olması
- "Bu özellik teklife dahil miydi?" tartışması
- Teslimden sonra çıkan hataların ücretli mi ücretsiz mi düzeltileceği
- İş birliği bittiğinde devir sürecinin tanımlanmamış olması
Bu konuların her biri, baştan bir iki cümleyle yazıya geçirildiğinde neredeyse hiç sorun yaratmaz.
1. Kaynak Kodu Teslimi
Kaynak kodu, yazılımın insan tarafından okunabilen ve değiştirilebilen hâlidir. Mağazadaki uygulama dosyası ya da sunucuda çalışan sistem, bu kodun derlenmiş ya da yayına alınmış sonucudur. Kaynak kodu elinizde değilse, yazılımı başka bir ekiple geliştirmeye devam etmeniz pratikte çok zorlaşır.
Sözleşmede şu sorular net cevaplanmalı:
- Ne teslim edilecek? Mobil uygulama kodu, yönetim paneli kodu, sunucu tarafı (backend) kodu, veritabanı yapısı ve kurulum dokümanı. Yalnızca "uygulamanın kodu" demek, backend'i dışarıda bırakabilir.
- Ne zaman teslim edilecek? Proje sonunda mı, her aşama ödemesinden sonra mı? Ara teslimler, uzun projelerde iki tarafı da korur.
- Hangi biçimde? Erişim verilen bir kod deposu (Git deposu) en sağlıklı yoldur; değişiklik geçmişi de korunur. Sıkıştırılmış bir dosya göndermek, geçmişi kaybettirir.
- Kurulabilirlik: Teslim edilen kodun, dokümana bakılarak başka bir geliştirici tarafından çalıştırılabilir olması.
Bazı yazılım firmaları kendi hazır altyapıları üzerine geliştirme yapar. Bu durumda altyapının kendisi size devredilmeyebilir; bu, kendi içinde meşru bir modeldir. Önemli olan bunun baştan açıkça yazılması ve size özel geliştirilen kısmın sınırlarının belirlenmesidir.
2. Fikri Mülkiyet ve Kullanım Hakları
Kaynak kodunu almak ile kodun haklarına sahip olmak aynı şey değildir. Bilgisayar programları Türkiye'de Fikir ve Sanat Eserleri Kanunu kapsamında korunan eserler arasında sayılır; hakların kimde kalacağı ve nasıl devredileceği ise büyük ölçüde sözleşmeyle belirlenir. Bu konuda kesin çerçeveyi hukukçunuz çizmelidir; ancak sözleşmede cevaplanması gereken iş soruları şunlardır:
- Size özel geliştirilen kodun mali hakları size mi devrediliyor, yoksa yalnızca kullanım lisansı mı veriliyor?
- Devir süresiz mi, belirli bir süre ve bölgeyle mi sınırlı?
- Yazılım firması aynı kodu ya da benzerini başka müşterilerde kullanabilir mi?
- Projede kullanılan açık kaynak kütüphaneler hangi lisanslarla geliyor? Bazı lisanslar ticari kullanımda ek yükümlülük getirebilir.
- Tasarım dosyaları, logo, ikonlar ve metinler kime ait?
Satın alınmış tema, eklenti ya da ücretli servis kullanılıyorsa, bunların lisansının kimin adına alındığı da yazılmalı.
3. Hesaplar, Alan Adı ve Altyapı Kimin Adına?
Sahada en sık gördüğümüz sorunlardan biri budur. Uygulama yayına alınır, her şey çalışır; ancak App Store ve Google Play geliştirici hesabı, sunucu, alan adı, e-posta servisi ve analiz araçları yazılım firmasının hesabında açılmıştır. İş birliği bittiğinde bu hesapların devri ciddi bir operasyona dönüşür; bazı mağaza hesaplarında uygulamayı başka bir hesaba taşımak ayrı bir süreç gerektirir.
Sözleşmede şu ilke yazılı olmalı: Ürünün yaşaması için gereken tüm hesaplar işletmenin adına açılır, yazılım firmasına yetkili kullanıcı olarak erişim verilir. Bu hesaplara örnek:
| Hesap / Varlık | Kimin adına olmalı? | Not |
|---|---|---|
| Alan adı | İşletme | Yenileme takibi de netleşmeli |
| App Store geliştirici hesabı | İşletme (kurumsal hesap) | Yıllık ücret işletmeden ödenir |
| Google Play geliştirici hesabı | İşletme | Tek seferlik kayıt |
| Sunucu / bulut hesabı | İşletme veya devir maddesi | Erişim yetkisi ayrıca verilir |
| Analitik, harita, ödeme servisleri | İşletme | API anahtarları belgelenmeli |
Mağaza yayın süreçlerinin ayrıntısını App Store ve Google Play'e uygulama yükleme yazımızda anlattık. Alan adının yenileme tarihini kimin takip edeceği de bu maddede yazılı olmalı; yenilenmeyen bir alan adı, en iyi yazılımı bile bir gecede erişilemez hâle getirir.
4. Kapsam, Değişiklik Talepleri ve Kabul Testi
"Bu teklife dahil miydi?" tartışmasını önlemenin yolu, kapsamı sözleşmenin ekine ayrıntılı yazmaktır. Ekranlar, kullanıcı rolleri, entegrasyonlar ve yönetim paneli özellikleri tek tek listelenmelidir. Kapsam belgesi ne kadar netse, ileride çıkan her yeni talebin "ek iş" mi "kapsam içi" mi olduğu o kadar kolay anlaşılır.
Bunun yanında iki madde daha yazılmalı:
- Değişiklik talebi süreci: Proje sırasında yeni bir özellik istendiğinde nasıl fiyatlandırılacağı, takvime etkisinin nasıl onaylanacağı. Yazılı onay olmadan kapsam büyümemeli.
- Kabul testi: Teslim edilen yazılımın hangi kriterlerle "kabul edildi" sayılacağı, test için kaç gün tanınacağı, bulunan hataların ne kadar sürede düzeltileceği. Kabul tarihi, garanti süresinin de başlangıcıdır.
Kapsam belgesini hazırlarken "şimdilik lazım değil ama ileride eklenebilir" dediğiniz özellikleri de ayrı bir başlık altında not edin; bu, sonraki fazların fiyatlandırmasını kolaylaştırır.
5. Garanti, Bakım ve Destek
Yazılım teslim edildiğinde iş bitmez. İşletim sistemleri güncellenir, mağazalar yeni kurallar getirir, bağlı servisler sürüm değiştirir. Bu yüzden sözleşme iki dönemi ayrı ayrı tanımlamalıdır:
- Garanti dönemi: Teslimden sonra belirli bir süre boyunca, kapsam içindeki hataların ücretsiz düzeltilmesi. Sürenin ne kadar olduğu ve "hata" tanımı yazılmalı.
- Bakım dönemi: Garanti bittikten sonra güncelleme, uyumluluk ve küçük geliştirmelerin hangi modelle yürüyeceği; aylık sabit ücret mi, saatlik çalışma mı? Müdahale süreleri de tanımlanmalı.
Bakımın neden bitmeyen bir kalem olduğunu kendi ürünlerimizde de yaşıyoruz: Yayındaki uygulamalarımız düzenli olarak işletim sistemi ve mağaza kuralı değişikliklerine uyarlanmak zorunda. Bu giderlerin mantığını uygulama bakım maliyeti yazımızda ayrıntılı ele aldık.
6. Gizlilik, Veri ve Fesih
Uygulamanız kullanıcı verisi topluyorsa, yazılım firması bu verilere erişebilecek konumdadır. Sözleşmede gizlilik yükümlülüğü, kişisel verilerin işlenmesine ilişkin roller ve güvenlik tedbirleri yer almalıdır. KVKK açısından hangi tarafın hangi sıfatla hareket ettiği hukuki bir değerlendirmedir; bu kısmı mutlaka bir hukukçuyla netleştirin. Teknik tarafta erişim yetkilerinin, şifrelemenin ve kayıt tutmanın nasıl yapılacağı da sözleşmenin ekinde tarif edilebilir.
Son olarak, iş birliği bittiğinde ne olacağı yazılmalı: Fesih bildirimi süresi, o güne kadar yapılan işin teslimi, şifrelerin ve erişimlerin devri, veritabanı yedeğinin teslimi ve yazılım firmasının erişimlerinin kapatılması. Bu madde, iyi giden bir iş birliğinde gereksiz görünür; işler ters gittiğinde ise en değerli madde olur.
İmzalamadan Önce Kontrol Listesi
- Kaynak kodu (mobil, panel, backend) teslimi ve teslim biçimi yazılı
- Mali hakların devri ya da lisans kapsamı net
- Mağaza, sunucu, alan adı ve servis hesapları işletme adına
- Kapsam belgesi sözleşmenin eki olarak imzalı
- Değişiklik talebi ve fiyatlandırma süreci tanımlı
- Kabul testi kriterleri ve süresi belli
- Garanti süresi ve sonrası bakım modeli ayrı ayrı yazılı
- Gizlilik ve kişisel veri maddeleri hukukçu tarafından incelendi
- Fesih hâlinde devir adımları tanımlı
- Ödeme planı teslim aşamalarına bağlı
Sık Sorulan Sorular
Kaynak kodunu almak için ek ücret ödemem gerekir mi? Bu, firmanın iş modeline bağlıdır. Bazı firmalar kodu proje bedeline dahil eder, bazıları kendi altyapısını lisansla verir. Önemli olan teklif aşamasında bunu sormanız ve sözleşmeye yazdırmanızdır.
Yazılım sözleşmesi için hazır şablon kullanabilir miyim? Şablonlar başlangıç noktası olabilir; ancak projenin kapsamına, kullanılan altyapıya ve veri işleme biçimine göre uyarlanması gerekir. İmzadan önce bir hukukçuya inceletmeniz en sağlıklısıdır.
Uygulama yazılım firmasının mağaza hesabında yayında. Ne yapmalıyım? Önce durumu tespit edin, ardından firmayla bir devir planı konuşun. Mağazaların uygulama taşıma süreçleri vardır; ancak zaman alabilir. Yeni projelerde hesapları baştan kendi adınıza açın.
Yazılım firması iflas eder ya da işi bırakırsa ne olur? Kaynak kodu düzenli olarak sizin erişiminizdeki bir depoya aktarılıyorsa ve hesaplar sizin adınızaysa, başka bir ekiple devam etmek mümkündür. Kod yalnızca firmanın sunucularındaysa risk büyür. Bu yüzden kodun ara teslimlerle size aktarılmasını sözleşmeye yazdırmak, en basit sigortadır. Bazı kurumsal projelerde kodun bağımsız bir üçüncü tarafta saklandığı emanet (escrow) düzenlemeleri de kullanılır; ihtiyacınız olup olmadığını hukukçunuzla değerlendirin.
Garanti süresi ne kadar olmalı? Sabit bir süre yok; projenin büyüklüğüne göre değişir. Önemli olan sürenin ve "hata" tanımının yazılı olması, kabul tarihinden itibaren başlamasıdır.
Sonuç
İyi bir yazılım sözleşmesi, iş birliğine güvensizlik değil, netlik getirir. Kaynak kodunun teslimi, hakların kimde olduğu, hesapların sahipliği, kapsam ve kabul kriterleri, garanti ve bakım, gizlilik ve fesih maddeleri baştan yazıldığında iki taraf da rahat eder. Metnin hukuki çerçevesini hukukçunuza bırakın; iş tarafındaki soruları ise bu listeyle masaya getirin.
Biz yazılım projelerinde kapsamı, teslim edilecekleri ve hesap sahipliğini teklif aşamasında yazılı olarak netleştiriyoruz. Uygulamanızı ya da iş yazılımınızı sağlam bir zeminde başlatmak için özel yazılım geliştirme hizmetimizi inceleyebilir, projenizi konuşmak için bize ulaşabilirsiniz.
Yazan: Vamos Dijital Ofis
Sonraki yazı: Fuarda Toplanan Kartvizitler Neden Müşteriye Dönmez? Fuar Sonrası Takip Rehberi →