Kod sahipliği: teslim neyi kapsar, eksikse ne olur, nasıl sınanır?

Sözleşme bitti, ödeme tamamlandı, sistem çalışıyor. Sekiz ay sonra yeni bir rapor gerekiyor ve o raporu yazacak kişiyi bulamıyorsunuz. Sözleşmede “kaynak kod müşteriye aittir” yazıyor; ama kodun hangi sürümünün canlıda olduğunu, veritabanının nasıl kurulduğunu ve boş bir sunucuda sistemin nasıl ayağa kaldırılacağını kimse bilmiyor. Mülkiyet sizde, kullanabilirlik değil.

Tedarikçi bağımlılığı çoğu zaman kötü niyetle açıklanır. Sahada çok daha sık gördüğümüz sebep daha sıradan: teslim listesi hiç yazılmamıştır. İki taraf da “kod verilecek” cümlesinde anlaşır, kimse o cümlenin altını doldurmaz. Bu yazı o listeyi dolduruyor.

Teslim tam olarak neyi kapsar

Çalışan bir sistemi bir başkasının sürdürebilmesi için sekiz kalem gerekir. Bunlardan biri eksikse sistem çalışmaya devam eder, ama değiştirilemez hâle gelir.

Teslim kalemi	İçinde ne var	Eksikse ne olur
Kaynak kod deposu	Değişiklik geçmişiyle birlikte tüm dallar	Kararların gerekçesi kaybolur, hata avı uzar
Veri modeli	Tablo şeması, ilişkiler, migration dosyaları	Veritabanı sıfırdan kurulamaz, rapor yazılamaz
Ortam yapılandırması	Örnek yapılandırma dosyası, gerekli değişken listesi	Kod açılır, uygulama açılmaz
Kurulum tarifnamesi	Boş sunucudan çalışır sisteme adım adım	Devralan ekip tersine mühendislik yapar
Üçüncü parti hesaplar	Entegratör, SMS, harita, e-posta servisleri	Servis yenilenmediği gün akış durur
Kabul testleri	Hangi ekran hangi sonucu verirse doğru sayılır	Yapılan değişikliğin neyi bozduğu görülmez
Mimari belge	Modüller, veri akışı, dış bağlantılar	Yeni ekip önce haritayı çizmek zorunda kalır
Tasarım kaynakları	Ekran tasarımı dosyaları, ikon ve font hakları	Arayüz değişikliği sıfırdan başlar

Bu sekiz kalem tek bir cümleye sığar ve o cümle sözleşmeye girmelidir: kod, veri modeli, kurulum tarifnamesi, yapılandırma örneği, hesap devirleri, kabul testleri, mimari belge ve tasarım kaynakları teslim kapsamındadır.

Eksik teslimin dört tipik hâli

Sahada gördüğümüz eksiklikler dört başlıkta toplanıyor ve dördü de “kod teslim edildi” cümlesiyle uyumlu görünüyor.

Geçmişi silinmiş kod. Depo yerine tek bir sıkıştırılmış dosya verilir. Kod oradadır, ama hangi satırın ne zaman ve neden değiştiği yoktur. Bir hatayı düzeltmeye çalışan yeni ekip, kendi yazmadığı kodun gerekçesini tahmin eder.

Şemasız kod. Uygulama kodu tamdır, veritabanı yapısını üreten dosyalar yoktur. Canlı sistemin yedeği elinizde olsa bile ikinci bir test ortamı kuramazsınız; her deneme canlıda yapılır.

Anahtarsız kod. Yapılandırma dosyası gizli tutulmuştur ve içinde hangi değişkenlerin beklendiği belgelenmemiştir. Uygulama açılışta hata verir, hatanın hangi eksik değişkenden geldiği tek tek denenerek bulunur.

Tarifnamesiz kod. En sık görüleni budur. Kurulum bir kişinin kafasındadır. O kişi ekipten ayrıldığında bilgi de ayrılır; ne tedarikçi ne siz elinizde bir belgeye sahipsinizdir.

Sözleşmede aranacak altı madde

Kod sahipliği iyi niyetle değil maddeyle güvence altına alınır. Aşağıdaki altı madde, teklif aşamasında sorulduğunda tedarikçiyi hiç zorlamaz; imzadan sonra sorulduğunda pazarlık konusu olur.

1. Teslim kapsamı. Yukarıdaki sekiz kalem, madde içinde tek tek sayılır. “Dokümantasyon dahildir” ifadesi kapsam değildir.
2. Teslim anı. Kod yalnız sözleşme bitiminde değil, her yayın sonunda deponuza yazılır. Teslim tek seferlik bir olay değil, süregelen bir durumdur.
3. Lisans. Kod devredilir veya süresiz, kullanıcı sayısından bağımsız kullanım lisansı verilir. Sürenin ve kullanıcı sayısının geçtiği her cümle bağımlılık üretir.
4. Veri dışa aktarımı. Tüm kayıtlar açık formatta (SQL yedeği, CSV, JSON) ve ücretsiz alınabilir. PDF rapor veri değildir.
5. Devralma hakkı. Üçüncü bir ekibin sistemi sürdürmesi sözleşmeyle engellenmez, rekabet yasağı kod bakımına uzatılmaz.
6. Çıkış süreci. Talepten teslime kaç gün, hangi format, kimin katılımıyla. Gün yazılmadıysa süre yoktur.

Bu maddeler teklif okurken nerede gizleniyorsa oradan çıkar: satır satır neyi neyin gizlediğini yazılım firması seçiminde 7 soru yazısında ele aldık.

Sahipliği sınama: devralma provası

Sözleşme metni bir şey vaat eder; prova onu doğrular. Devralma provası, canlı sisteme hiç dokunmadan yapılan ve genellikle bir gün süren bir tatbikattır.

1. Boş bir sunucu açın. Test amaçlı, canlıdan tamamen ayrı.
2. Teslim paketini elinize alın. Kod deposu, kurulum tarifnamesi, yapılandırma örneği, şema dosyaları.
3. Tedarikçiyi odadan çıkarın. Provanın anlamı, yardımsız kurulabilmesidir. Sorular yazılı sorulur, sözlü cevap verilmez.
4. Kurun ve açın. Uygulama açılıyor mu, örnek veriyle giriş yapılabiliyor mu, temel ekranlar geliyor mu?
5. Eksik listesini çıkarın. Tıkandığınız her adım, teslim paketinde eksik bir kalemdir. Liste tedarikçiye yazılı iletilir ve tamamlanır.

Provayı ilk canlı modülden hemen sonra yapın. İlişki iyi giderken eksikleri tamamlatmak, ilişki bittikten sonra istemekten kolaydır — ve o gün pazarlık gücünüz en yüksektir.

Yazılı cevap istenecek üç soru

Tedarikçi görüşmesinde şu üç soruyu sorun ve cevapları e-postayla isteyin. Sözlü cevaplar hatırlanmaz, yazılı cevaplar sözleşmeye taşınır.

• Yarın ayrılmak istesem verilerimi hangi formatta, kaç gün içinde alırım?
• Kaynak kodu bugün hangi depoda tutuyorsunuz ve o deponun sahibi hangi şirket?
• Sistemi başka bir ekip devralmak isterse hangi belgeleri teslim edersiniz?

Üçüne de kaçamak cevap geliyorsa, bağımlılığın bedelini şimdiden ödemeye başlamışsınız demektir. Veri tarafındaki karşılığını — sunucu hesabı kimin adına, yedek nerede, çıkışta ne alınır — verileriniz nerede duruyor yazısında ayrıca inceledik.

Bağımlılığın kabul edilebilir olduğu yer

Dürüst olalım: her bağımlılık kötü değildir. Hazır bir SaaS ürünü kullandığınızda kodu almazsınız ve bu, ürünün doğasında vardır. Standart bir ihtiyaç için standart bir ürün kiralıyorsanız sahiplik tartışması yerine veri dışa aktarımına bakın: kaydınızı istediğiniz gün açık formatta alabiliyorsanız, kod sizde olmasa da çıkış yolunuz açıktır.

Sahiplik tartışması, sisteme şirketinizin kendi süreçleri yazıldığında kritikleşir. O kod artık genel bir ürün değil, işinizin tarifidir; başkasının deposunda durması işin kendisini rehin bırakmak demektir. Hazır ürünle özel sistem arasındaki bu ayrımı paket mi özel mi karar rehberinde ölçüt ölçüt karşılaştırdık.

KodDelta’da teslim paketi kod, veri modeli, kurulum tarifnamesi, yapılandırma örneği, mimari belge ve kabul testlerinden oluşur; lisans ömür boyu, kullanıcı sayısı sınırsızdır. Kapsam ve süre bantlarını fiyat sayfasında açık yazdık. Elinizdeki mevcut sistemin teslim paketinde ne eksik olduğunu birlikte çıkarmak isterseniz teklif formundan yazın.

---

İ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

Sözleşmede 'kaynak kod müşteriye aittir' yazması yeterli mi?

Yeterli değil. O cümle mülkiyeti tarif eder, teslimi tarif etmez. Aynı cümlenin altında kodun hangi ortamda, hangi biçimde ve neyle birlikte verileceği yazmıyorsa, elinize bir klasör gelir ve o klasör tek başına çalışmaz. Sözleşmeye teslim kalemlerinin listesini ayrı bir madde olarak ekletin.

Kod deposunun geçmişi neden teslim kapsamına giriyor?

Çünkü bir hatayı düzeltecek yeni ekibin ilk sorusu 'bu satır neden böyle yazılmış' olur. Değişiklik geçmişi, hangi kararın hangi tarihte ve hangi talep üzerine alındığını gösterir. Geçmişi silinmiş tek bir sıkıştırılmış dosya, aynı kodun tarihsiz ve gerekçesiz hâlidir; devralma süresini belirgin biçimde uzatır.

Kaynak kodu görmek isteyince tedarikçi 'ticari sır' derse ne yapmalı?

Çerçeveler, kütüphaneler ve genel yardımcı kodlar zaten sırdır sayılmaz; sizin süreçlerinizi yazan kod ise sizin işinizin tarifidir. Tedarikçi kendi ürün altyapısını ayrı tutmak istiyorsa bunu sözleşmede iki katman hâlinde yazsın: hangi kısım size devredilir, hangi kısım süresiz kullanım lisansıyla verilir.

Escrow (kaynak kod emaneti) gerekli mi?

Kod zaten size teslim ediliyorsa gerekmez. Escrow, kodun tedarikçide kaldığı kurgular için düşünülmüş bir çözümdür ve yalnız sözleşmede tanımlı bir olay gerçekleşince açılır. KodDelta kurulumlarında kod baştan müşteriye teslim edildiği için emanet mekanizmasına ihtiyaç duyulmaz. Açıkça yazalım: **escrow hizmeti sunmuyoruz** ve hiçbir emanet sağlayıcısıyla anlaşmamız yok.

Sahipliği canlı sisteme dokunmadan nasıl sınarım?

Devralma provası yapın: teslim paketini boş bir sunucuya, tedarikçi ekibinden kimse yardım etmeden kurdurun. Kurulum tarifnamesi eksikse prova ilk saatte tıkanır ve eksik kalemler kendiliğinden ortaya çıkar. Provayı ilk canlı modülden hemen sonra, ilişki iyiyken yapın.

Kullanıcı başı lisans neden bağımlılık üretir?

Çünkü sistemin maliyeti işinizin büyümesine bağlanır: teknisyen sayınız arttıkça yazılım faturanız artar ve büyüme kararı bir yazılım kalemi hâline gelir. KodDelta'da kullanıcı sayısı sınırsız, lisans ömür boyudur; büyüme yalnız yeni modül eklendiğinde bütçeye girer.

İ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