Yazılım Bakım Sözleşmesi: Kapsam, SLA ve Ücretler

Yazılım bakım sözleşmesi, teslim edilmiş bir yazılımın hata giderme, güvenlik yaması, uyarlama ve küçük geliştirme işlerini yazılı kurallara bağlayan ek sözleşmedir. Uluslararası ölçüt, yıllık bakım bedelinin net lisans ya da proje bedelinin %18-22'si aralığında kalmasıdır; bedeli belirleyen iki değişken kapsam ve SLA seviyesidir.

Yazılım projelerinde en pahalı tartışma, teslimden üç ay sonra çıkan "bu kapsam dışı" tartışmasıdır. Siz hatanın giderilmesini beklersiniz, yazılım firması bunu yeni geliştirme sayar. İkinizin de elinde yazılı bir şey yoksa tartışmayı kim daha ısrarcıysa kazanır — ve bu arada yazılım çalışmamaya devam eder.

Bu sorunun kaynağı genelde kötü niyet değil, eksik sözleşmedir. Geliştirme sözleşmesi teslime kadar olan işi tanımlar; teslimden sonrasını tanımlayan belge ise bakım sözleşmesidir. Türk Borçlar Kanunu'nun 478. maddesine göre yüklenicinin ayıplı eserden doğan sorumluluğu, taşınmaz yapılar dışındaki eserlerde teslim tarihinden itibaren iki yılın geçmesiyle zamanaşımına uğrar (TBK m.478). Yazılım bu kategoriye girer. Yani garanti tartışmasının hukuki ömrü sandığınızdan kısadır ve ayıp sorumluluğu, "her ay bakılsın" anlamına da gelmez.

Bu rehber bakım sözleşmesini avukat diliyle değil, imzalayacak işletme sahibinin gözünden ele alıyor: kapsam nasıl yazılır, SLA'da hangi süreler gerçekçidir, bedel nasıl hesaplanır ve hangi maddeler atlandığında fatura sonradan kabarır. Odak web ve kurumsal yazılım; mobil uygulamaya özgü kalemler için ayrı bir rehberimiz var.

İçindekiler

• Yazılım Bakım Sözleşmesi Nedir, Neyi Kapsar?
• Bakım Türleri: Düzeltici, Uyarlayıcı, Önleyici ve Geliştirici
• Kapsam Dışı Ne Olmalı? Bakım ile Yeni Geliştirme Arasındaki Sınır
• SLA: Önem Seviyeleri, Yanıt ve Çözüm Süreleri
• Hizmet Kredisi ve Yaptırım: SLA'nın Dişi Var mı?
• Ücret Modelleri: Aylık Paket, Saat Bankası, Olay Başı
• Yıllık Bakım Bedeli Nasıl Hesaplanır?
• Sözleşmede Mutlaka Olması Gereken 12 Madde
• KVKK ve Veri Güvenliği: Bakım Firması Üretim Verisine Erişirse
• Bakımsız Yazılımın Biriken Maliyeti
• Web Yazılımı ile Mobil Uygulama Bakımı Arasındaki Fark
• Sözleşme Yenilerken ve Firma Değiştirirken Nelere Dikkat Etmeli?
• Sıkça Sorulan Sorular

Yazılım Bakım Sözleşmesi Nedir, Neyi Kapsar?

Yazılım bakım sözleşmesi, çalışan bir yazılımın çalışmaya devam etmesi için yapılacak işleri ve bu işlerin hangi sürede, hangi bedelle yapılacağını tanımlayan sözleşmedir. Geliştirme sözleşmesinin devamı niteliğindedir ama konusu farklıdır: biri yeni bir şey üretmeyi, diğeri mevcut olanı ayakta tutmayı taahhüt eder.

TÜBİTAK BİLGEM Yazılım Teknolojileri Araştırma Enstitüsü'nün Yazılım Bakım Rehberi bakımı şöyle tanımlar: "mevcut yazılım üzerinde gerçekleştirilecek hata giderme, işlev ekleme ve iyileştirmelere yönelik yazılım geliştirme faaliyetleri ile ilgili dokümantasyonun güncellenmesi."

Aynı rehberin çizdiği sınır, sözleşme yazarken en çok işe yarayan cümledir: işletim sistemi, uygulama sunucusu, veritabanı yönetim sistemi, hazır yazılım veya programlama dilini değiştirme ihtiyacından doğan işler bakım değil, yazılım modernizasyonu kapsamındadır. Bu ayrımı sözleşmeye yazmayan taraflar, iki yıl sonra "veritabanını yenilemek bakıma dahil mi?" sorusunda tıkanır.

Pratikte bir bakım sözleşmesi şu dört bloktan oluşur:

• Reaktif blok: Bildirilen hataların giderilmesi, kesinti müdahalesi, geri alma (rollback).
• Proaktif blok: Güvenlik yamaları, bağımlılık güncellemeleri, yedek doğrulama, izleme.
• Esnek blok: Aylık belirli bir saat kotası içinde küçük geliştirme ve içerik/parametre değişiklikleri.
• Yönetişim bloğu: Raporlama, periyodik toplantı, eskalasyon merdiveni, kapsam değişikliği süreci.

Dört bloğun hepsi tek fiyata gömülürse ilk ihtilafta ayrıştırılamaz. Sözleşmede her bloğun ayrı ayrı yazılı olması, hem bedelin denetlenebilir olmasını hem de kapsam tartışmalarının kısa sürmesini sağlar.

Bakım Türleri: Düzeltici, Uyarlayıcı, Önleyici ve Geliştirici

Yazılım mühendisliği literatürü bakımı dört türe ayırır. Bu dört başlığı sözleşmenin kapsam maddesine aynen taşımak, "neyin dahil olduğu" sorusunu büyük ölçüde kapatır.

Uyarlayıcı bakım, sözleşmelerde en çok hafife alınan kalemdir; çünkü takvimini sizin ekibiniz değil üçüncü taraflar belirler. Somut iki örnek: PHP'nin resmi sürüm takvimine göre PHP 8.2 artık yalnızca kritik güvenlik düzeltmesi alıyor ve bu destek de 31 Aralık 2026'da bitiyor; PHP 8.4'ün etkin desteği de aynı tarihte sona eriyor. Node.js tarafında ise Node 20 ömrünü tamamladı; üretimde yalnızca 22 ve 24 LTS sürümleri önerilir.

Bunlar "isterseniz yaparız" işleri değildir. Desteği bitmiş bir çalışma zamanının üzerinde duran yazılım, bir sonraki güvenlik açığında yamasız kalır. Bakım sözleşmesi bu yükseltmeleri kapsamıyorsa, maliyet ortadan kalkmaz; yalnızca ertelenir ve büyür.

Kapsam Dışı Ne Olmalı? Bakım ile Yeni Geliştirme Arasındaki Sınır

İyi bir yazılım bakım sözleşmesi, dahil olanları saymakla yetinmez; kapsam dışını da açıkça yazar. Deneyimimizde en çok ihtilaf çıkaran sekiz kalem şunlardır:

1. Yeni modül ve yeni ekran: Var olmayan bir işlevi üretmek bakım değildir, projedir.
2. Platform geçişi ve yeniden yazım: Framework değişikliği, veritabanı göçü, mimari değişiklik — TÜBİTAK rehberinin diliyle modernizasyon.
3. Üçüncü taraf lisans ve servis bedelleri: Sunucu, SSL, e-posta, SMS, harita API'si, ödeme altyapısı kullanım bedelleri.
4. İçerik girişi: Ürün, haber, görsel yükleme gibi operasyonel işler ayrı kalemdir.
5. Kullanıcı hatasından doğan veri düzeltmeleri: Yapılabilir, ama saat kotasından düşülmeli.
6. Entegre olunan tarafın değişikliği: Banka veya kamu entegrasyonunun sürüm değiştirmesi uyarlayıcı bakımdır; sözleşmede kapsamda mı, ek işlem mi olduğu yazılmalıdır.
7. Yük artışından doğan altyapı büyütme: Trafik üç katına çıktığında sunucu ölçeklendirme bir bakım kalemi değil, kapasite kararıdır.
8. Eğitim ve yeni personel oryantasyonu: Saat bazlı ayrı hizmet olarak tanımlanmalıdır.

Kapsam dışı kalemler için sözleşmeye bir de değişiklik talebi (change request) süreci eklenir: talep nasıl iletilir, kaç iş günü içinde fiyatlanır, hangi saat ücreti uygulanır, onay kim verir. Bu dört satır, sonradan yapılan işlerin "sözsüz anlaşmayla" birikmesini engeller.

SLA: Önem Seviyeleri, Yanıt ve Çözüm Süreleri

SLA (hizmet seviyesi taahhüdü), yazılım bakım sözleşmesinin ölçülebilir kısmıdır. İki süreyi karıştırmamak gerekir: yanıt süresi firmanın kaydı alıp çalışmaya başladığını bildirmesi, çözüm süresi ise sorunun giderilmesidir. Yalnızca yanıt süresi veren bir SLA, pratikte hiçbir şey taahhüt etmez.

Olgun SLA'lar önce önem seviyelerini tanımlar. Büyük bulut sağlayıcılarının kurumsal destek planları bu merdivenin fiili standardını oluşturuyor: AWS'nin destek planlarında kritik iş sistemi durduğunda yanıt taahhüdü 15 dakika, üretim sistemi durduğunda 1 saat, üretim sistemi kısmen bozulduğunda 4 saat, sistem kısmen bozulduğunda 12 saat, genel danışma sorularında 24 saattir.

Türkiye'deki web ve kurumsal yazılım projelerinde gerçekçi bir karşılığı şöyle kurabilirsiniz:

Üç noktayı sözleşmede netleştirmek gerekir. Birincisi, sürelerin saati hangi anda başlar: bildirimin ulaştığı an mı, mesai başlangıcı mı? İkincisi, destek penceresi: mesai içi destek (örneğin hafta içi 09:00-18:00) ile nöbetli kesintisiz destek arasındaki maliyet farkı iki ila üç kata çıkabilir, çünkü ikincisi ayrı bir nöbet ekibi gerektirir. Üçüncüsü, seviye kararını kim verir: müşteri S1 der, firma S3 derse hakem kim olacak? Pratik çözüm, seviye tanımlarını örnekli yazmak ve ilk yanıtta seviyenin karşılıklı teyit edilmesini şart koşmaktır.

Bir de kimin bildirdiği önemlidir. Sözleşmeye "yetkili bildirim kanalı" yazılmazsa talepler WhatsApp'tan, e-postadan ve telefondan paralel akar; hiçbiri ölçülemez. Tek bir talep kanalı (destek sistemi veya belirlenmiş e-posta adresi) SLA'nın ön koşuludur.

Hizmet Kredisi ve Yaptırım: SLA'nın Dişi Var mı?

Süre taahhüdü, ihlal edildiğinde bir sonucu yoksa temenni hükmündedir. Olgun sözleşmelerde bu sonuç hizmet kredisidir: taahhüt tutulmazsa o dönemin bedelinin belirli bir yüzdesi iade edilir ya da sonraki faturadan düşülür.

Piyasada bu mekanizmanın nasıl kurulduğunu görmek için kurumsal yazılım şirketlerinin kamuya açık SLA metinleri iyi bir referanstır. Örneğin Atlassian'ın hizmet kredisi tablosunda aylık çalışma süresi %99,0-%99,9 arasında kalırsa %10, %95,0-%99,0 arasında kalırsa %25, %95'in altına düşerse %50 kredi uygulanıyor; kurumsal planda %99,9-%99,95 aralığı için ayrıca %5'lik bir kademe var. Talep, ihlalin yaşandığı ayın bitiminden itibaren 15 gün içinde yapılmalı ve kredi nakit iade değil, sonraki faturaya mahsup olarak işliyor.

Küçük ve orta ölçekli bir bakım sözleşmesinde bu mekanizmayı birebir kopyalamak gerekmez, ama üç unsuru taşımalıdır:

• Ölçüm yöntemi: Çalışma süresi hangi araçla, hangi noktadan ölçülür? Planlı bakım penceresi hesaba katılır mı?
• Kademeli yaptırım: Tek bir ceza yerine ihlalin büyüklüğüne göre artan kademe.
• Talep süresi ve usulü: Kredi otomatik mi işler, yoksa süre sınırı olan bir talep mi gerekir?

Bir uyarı: hizmet kredisi tek başına koruma değildir. Aylık bedelin %25'i, bir günlük kesintinin işletmeye verdiği zararın yanında küçük kalabilir. Bu yüzden kredi maddesinin yanına tekrarlayan ihlal halinde tazminatsız fesih hakkı yazılması, pazarlıkta sizin en güçlü maddenizdir.

Ücret Modelleri: Aylık Paket, Saat Bankası, Olay Başı

Bakım bedeli dört ana modelden biriyle kurulur. Her modelin kazandığı ve kaybettiği taraf farklıdır.

Pratikte en dengeli kurgu, aylık sabit paket + aşım saati tarifesi birleşimidir: proaktif ve reaktif blok sabit bedele girer, esnek bloğa aylık saat kotası konur, kota aşıldığında önceden belirlenmiş saat ücreti uygulanır. Kullanılmayan saatlerin bir sonraki aya devri (genelde bir ay, en çok kota kadar) sözleşmeye yazılırsa müşteri tarafındaki "boşa ödedim" hissi de ortadan kalkar.

Saat bankası modelinde iki maddeyi atlamayın: saatlerin geçerlilik süresi ve SLA'nın saat bankasıyla ilişkisi. Havuzda saat kalmadığında firmanın yanıt yükümlülüğü devam ediyor mu, etmiyor mu? Bu cümle yazılmazsa kritik bir kesintide saat satın alma pazarlığı yaparken sistem kapalı kalır.

Yıllık Bakım Bedeli Nasıl Hesaplanır?

Paket yazılım dünyasında ölçüt nettir. ABD Savunma Bakanlığı Kurumsal Yazılım Girişimi'nin yayımladığı yazılım bakım pazarlığı rehberine göre yazılım üreticileri ilk yıl bakımı için net (indirimli) lisans bedelinin %20 veya üzerini talep etmeyi olağan sayıyor ve bedeli her yıl endeksliyor. Aynı rehber bu modelin sonucunu çarpıcı biçimde özetliyor: kuruluşlar "esasen her beş yılda bir lisansları yeniden satın alıyor."

Rehberin karşılaştırma tablosu, yüzdenin ve artış oranının birlikte ne kadar fark yarattığını gösteriyor: 25 milyon dolar liste bedelli bir yazılımda net lisans bedelinin %22'si + yıllık %4 artış ile %18'i + yıllık %2 artış arasındaki fark, 15 yıllık ömür boyunca 12 milyon doları aşıyor. Yani pazarlıkta tek rakam olarak yüzdeye bakmak yarım iştir; artış oranı ve artışın neye endekslendiği en az o kadar önemlidir.

Özel geliştirilen web ve kurumsal yazılımlarda hesap biraz farklı kurulur, çünkü lisans bedeli yoktur. Burada kullanılabilecek üç çapa şudur:

• Proje bedelinin yüzdesi: Yıllık bakım bedelini geliştirme bedelinin bir yüzdesi olarak bağlamak, bütçelemeyi kolaylaştırır. Yazılım ne kadar çok entegrasyona dokunuyorsa bu yüzde yukarı gider.
• Saat maliyeti üzerinden aşağıdan yukarı: Aylık kaç saat proaktif iş (yama, yedek testi, izleme) gerektiği gerçekçi biçimde tahmin edilir, buna reaktif iş için tampon eklenir.
• Altyapı ve servis maliyetlerinin ayrıştırılması: Sunucu, yedek depolama, izleme aracı, SSL ve üçüncü taraf servis bedelleri bakım emeğinden ayrı satır olmalıdır; aksi halde yıllık artışlar görünmez biçimde fiyatın içinde erir.

Yazılımın ilk fiyatını ve bakım bedelini birlikte planlamak istiyorsanız web sitesi fiyat hesaplayıcı ile kapsam-bütçe ilişkisini kabaca görebilir, ardından bu rehberdeki yüzdelerle yıllık bakım kalemini üzerine ekleyebilirsiniz. Daha geniş bir bütçe çerçevesi için yazılım yaptırma maliyeti rehberi proje tarafındaki kalemleri ayrıntılandırıyor.

Son bir uyarı: fiyat artış maddesini "firma tek taraflı belirler" biçiminde bırakmayın. Artışın bir üst sınırı, bir referansı (örneğin bir önceki yılın tüketici fiyat endeksi) ve bildirim süresi olmalıdır.

Sözleşmede Mutlaka Olması Gereken 12 Madde

Aşağıdaki liste, bir yazılım bakım sözleşmesinde imzadan önce satır satır kontrol edebileceğiniz asgari çerçevedir. Eksik madde sayısı, sonradan çıkacak tartışma sayısıyla doğru orantılıdır.

1. Kapsam tanımı: Dört bakım türü ayrı ayrı yazılı, kapsam dışı kalemler listelenmiş.
2. Önem seviyeleri ve SLA: Seviye tanımları örnekli, yanıt ve çözüm süreleri ayrı ayrı belirtilmiş.
3. Destek penceresi ve tatil kuralı: Hangi saatler, hangi günler; resmi tatil ve yıllık izin dönemi nasıl yönetilir.
4. Tek talep kanalı ve eskalasyon: Talep nereye düşer, çözülmezse sırayla kim devreye girer, iletişim kişileri ve yedekleri kim.
5. Saat kotası ve aşım tarifesi: Aylık kota, devir kuralı, aşım saat ücreti.
6. Değişiklik talebi süreci: Fiyatlama süresi, onay yetkisi, ek iş sözleşmesinin biçimi.
7. Raporlama ve periyodik toplantı: Aylık rapor içeriği (açılan/kapatılan kayıt, SLA uyumu, yapılan yamalar), toplantı sıklığı.
8. Ortam ve erişim yönetimi: Geliştirme/test/üretim ortamı ayrımı, kimin hangi yetkiyle eriştiği, erişim kayıtlarının tutulması.
9. Yedekleme ve geri yükleme taahhüdü: Yedek sıklığı, saklama süresi, kurtarma hedefleri ve yılda en az bir kez test edilmesi.
10. Kişisel veri eki: Veri işleyen sıfatıyla yükümlülükler, alt yüklenici kuralı, ihlal bildirim süresi.
11. Fikri mülkiyet ve kaynak kod: Bakım sırasında üretilen kodun mali haklarının kime ait olduğu ve kod teslim/erişim düzeni.
12. Süre, fesih ve devir: Sözleşme süresi, yenileme biçimi, fesih bildirim süresi ve fesih halinde devir yükümlülüğü.

On birinci madde Türkiye'de özellikle yanlış kurgulanıyor. Fikir ve Sanat Eserleri Kanunu'nun 52. maddesi şarttır: "Mali haklara dair sözleşme ve tasarrufların yazılı olması ve konuları olan hakların ayrı ayrı gösterilmesi şarttır" (FSEK m.52). Yani bakım faturasını ödemek, bakım sırasında yazılan kodun haklarının size geçtiği anlamına gelmez; hakların yazılı ve tek tek sayılmış olması gerekir. Konunun ayrıntısı için kaynak kod teslimi rehberine bakabilirsiniz.

KVKK ve Veri Güvenliği: Bakım Firması Üretim Verisine Erişirse

Bakım yapan ekip, işin doğası gereği üretim ortamına ve dolayısıyla gerçek müşteri verisine erişir. Bu, sözleşmenin en çok ihmal edilen ama hukuki sonucu en ağır olan kısmıdır.

6698 sayılı Kişisel Verilerin Korunması Kanunu'nun 12. maddesinin ikinci fıkrası açıktır: "Veri sorumlusu, kişisel verilerin kendi adına başka bir gerçek veya tüzel kişi tarafından işlenmesi hâlinde, birinci fıkrada belirtilen tedbirlerin alınması hususunda bu kişilerle birlikte müştereken sorumludur" (KVKK m.12). Yani bakım firmanızın sunucusunda yaşanan bir sızıntı sizi sorumluluktan kurtarmaz; siz de sorumlu olursunuz.

Bu yüzden bakım sözleşmesine şu altı maddenin eklenmesi gerekir:

• Veri işleyen tanımı ve talimat sınırı: Firma hangi veriye, hangi amaçla, hangi talimatla erişebilir.
• Erişim yetkisi envanteri: Kaç kişi, hangi rolle erişiyor; personel ayrıldığında yetki kaç gün içinde kapatılıyor.
• Üretim verisinin test ortamına kopyalanması yasağı: Gerekliyse maskeleme/anonimleştirme şartı.
• Alt yüklenici (alt işleyen) kuralı: Yazılı izin olmadan üçüncü tarafa veri aktarılamaz.
• İhlal bildirim süresi: Firma bir güvenlik olayını size kaç saat içinde bildirmekle yükümlü.
• Sözleşme sonunda veri imhası: Yedekler, log'lar ve yerel kopyalar dahil, belgeli imha veya iade.

Ayrıca gizlilik yükümlülüğünün sözleşme bittikten sonra da sürdüğünü yazmak gerekir; Kanun'un aynı maddesi veri işleyenler için bu devamlılığı zaten öngörür. Web tarafındaki uyum başlıklarının tamamı için web sitesi KVKK uyumu rehberi ayrıntılı bir kontrol listesi veriyor.

Bakımsız Yazılımın Biriken Maliyeti

"Çalışıyor, dokunmayalım" yaklaşımı maliyeti ortadan kaldırmaz; faturayı erteler ve büyütür. 2026 verileri bu erteleme riskinin nasıl büyüdüğünü oldukça net gösteriyor.

Birincisi, yamalanacak açık sayısı patladı. NIST'in Ulusal Güvenlik Açığı Veri Tabanı'na (NVD) yayım tarihine göre 2025 yılında yaklaşık 50.000 güvenlik açığı kaydı eklendi; 2026'nın ilk dokuz ayında bu sayı 75.000'i aştı. Bağımlılık listeniz ne kadar uzunsa, bu akışın size dokunma olasılığı o kadar yüksektir.

İkincisi, saldırganların tercih ettiği giriş yolu değişti. Verizon'un 2026 Veri İhlali Soruşturmaları Raporu, ihlallerin %31'inin yazılım güvenlik açıklarıyla başladığını ve bu yolun çalınmış şifreleri geçerek birinci sıraya yerleştiğini bildiriyor. Bu, "bizde kritik veri yok" savunmasının teknik olarak geçersiz hale geldiği anlamına geliyor: hedef sizin verinizden çok, yamasız bileşeniniz.

Üçüncüsü, olayın bedeli artıyor. IBM'in veri ihlali maliyeti raporuna göre bir veri ihlalinin küresel ortalama maliyeti 4,99 milyon dolara çıktı; bu, bir önceki yıla göre %12 artış ve rapor tarihindeki en yüksek seviye. Rakam küresel ortalamadır ve her işletmeye birebir uymaz, ama yönü tartışmasızdır.

Buna bir de görünmeyen kalem eklenir: bakımsız kalan yazılımda her ertelenen güncelleme, sonraki güncellemeyi zorlaştırır. İki büyük sürüm geriden gelen bir bağımlılığı yükseltmek, her sürümü zamanında geçmekten kat kat pahalıdır — çünkü artık tek bir yükseltme değil, birikmiş kırılmaların toplu tamiri yapılmaktadır. Güvenlik tarafındaki asgari çerçeve için web sitesi güvenliği rehberi pratik bir başlangıç noktası.

Web Yazılımı ile Mobil Uygulama Bakımı Arasındaki Fark

İki dünyanın bakım yükü aynı değildir; sözleşme şablonunu birinden diğerine kopyalamak hata üretir.

Pratik sonuç: web tarafında bakım sözleşmesinin ağırlık merkezi kesinti ve güvenlik, mobil tarafta ise mağaza uyumu ve sürüm yönetimidir. Mobil tarafın kalem kalem bütçesi için mobil uygulama bakım maliyeti rehberine bakın; web tabanlı çözümlerin yapısal avantajları için web tabanlı yazılım nedir yazısı konuyu açıyor.

İki yazılımı aynı firmaya baktırıyorsanız tek sözleşme altında iki ayrı kapsam ve iki ayrı SLA tablosu kurmak en temiz yoldur. Tek tablo, mağaza süreçlerinden kaynaklanan gecikmeleri haksız biçimde SLA ihlali gibi gösterir.

Sözleşme Yenilerken ve Firma Değiştirirken Nelere Dikkat Etmeli?

Bir yazılım bakım sözleşmesinin gerçek testi, yenileme ve ayrılma anında yaşanır. Yenileme döneminde dört veriyi masaya koyun: geçen yıl açılan ve kapatılan kayıt sayısı, SLA uyum oranı, kota kullanımı ve yapılan güvenlik güncellemelerinin listesi. Bu dördü yoksa fiyat pazarlığını veriyle değil hisle yapıyorsunuz demektir — ve bu genelde firmanın lehine sonuçlanır.

Firma değiştirme kararı verdiyseniz devir maddesi hayati hale gelir. Sözleşmede şunların yazılı olması gerekir:

• Erişim ve varlık envanteri: Alan adı, DNS, sunucu, depo (repository), veritabanı, üçüncü taraf servis hesapları — kimin adına kayıtlı ve nasıl devredilecek.
• Dokümantasyon teslimi: Kurulum adımları, ortam değişkenleri, mimari notlar, bilinen sorunlar listesi.
• Devir süresi ve desteği: Fesihten sonra kaç gün boyunca yeni ekibe soru-cevap desteği verilecek, bu süre ücretli mi.
• Veri ve log teslimi: Hangi formatta, hangi süre içinde.

Uluslararası uygulamada bu riski azaltan bir araç daha var: kaynak kod emaneti (escrow). Hukuk pratiğinde, bakım yükümlülüğünün yerine getirilmemesi veya sözleşmenin sona ermesi, emanetteki kaynak kodun müşteriye açılması için bir tetikleyici olarak düzenlenebiliyor. Küçük projelerde bunun basit karşılığı, kod deposunun müşteri hesabı altında tutulması ve yazılım firmasına yalnızca yetki verilmesidir.

Son olarak, firmayı seçerken bakım kapasitesini de ölçün. Teklif aşamasında "kaç kişilik destek ekibiniz var, nöbet nasıl işliyor, geliştirici izne çıktığında kayıt kime düşüyor" sorularının cevabı, SLA tablosundaki sayılardan daha fazla şey anlatır. Firma seçim kriterlerinin tamamı için yazılım firması nasıl seçilir rehberine, özel yazılım sürecinin bütününe ise özel yazılım geliştirme yazısına bakabilirsiniz.

Sıkça Sorulan Sorular

Yazılım bakım sözleşmesi zorunlu mu?

Hayır, yasal bir zorunluluk değildir. Ancak Türk Borçlar Kanunu'nun 478. maddesine göre yüklenicinin ayıplı eserden doğan sorumluluğu, yazılım gibi taşınmaz yapı dışındaki eserlerde teslimden iki yıl sonra zamanaşımına uğrar. Bu süre dolduktan sonra garanti argümanı kalmaz; sürekli destek istiyorsanız bunu ayrı bir bakım sözleşmesiyle kurmanız gerekir.

Yıllık yazılım bakım ücreti ne kadar olur?

Paket yazılımda uluslararası ölçüt, ilk yıl için net lisans bedelinin %20 ve üzeridir; ABD Savunma Bakanlığı Kurumsal Yazılım Girişimi rehberi bu oranı ve yıllık endeks artışını olağan uygulama olarak tanımlıyor. Özel geliştirilen yazılımlarda bedel genellikle proje bedelinin bir yüzdesi ya da aylık saat kotası üzerinden kurulur; belirleyici olan SLA seviyesi, destek penceresi ve entegrasyon sayısıdır.

Bakım ile destek arasındaki fark nedir?

Destek, kullanıcıdan gelen soru ve olayların karşılanmasıdır; bakım, yazılımın kendisinde yapılan düzeltme, uyarlama ve iyileştirme çalışmasıdır. Birçok sözleşme ikisini tek başlıkta birleştirir, ancak ayrı yazıldığında hem fiyat hem SLA daha doğru kurulur: destek saat bazlı ölçülür, bakım iş kalemi bazlı planlanır.

SLA'da yanıt süresi mi çözüm süresi mi daha önemli?

Çözüm süresi işletme için belirleyici olandır, çünkü kesintinin ne kadar süreceğini o belirler. Yanıt süresi yalnızca kaydın alındığını gösterir ve tutulması kolaydır. İyi bir sözleşme ikisini ayrı ayrı taahhüt eder; yalnızca yanıt süresi veren bir SLA pratikte ölçülebilir bir koruma sağlamaz.

Bakım sözleşmesi kaynak kodu bana verir mi?

Kendiliğinden vermez. Fikir ve Sanat Eserleri Kanunu'nun 52. maddesi, mali haklara ilişkin devirlerin yazılı olmasını ve devredilen hakların ayrı ayrı gösterilmesini şart koşar. Bakım bedelini ödemek bu şartı karşılamaz; kaynak kodun teslimi ve hak devri sözleşmede açıkça yazılmalıdır.

Bakım firmamı değiştirirken ne isteyeceğim?

Erişim ve varlık envanteri (alan adı, DNS, sunucu, kod deposu, veritabanı, üçüncü taraf hesaplar), güncel dokümantasyon, bilinen sorunlar listesi, veri ve log teslimi ile devir döneminde soru-cevap desteği. Bu kalemlerin tamamı yeni sözleşme imzalanırken fesih maddesine yazılmalıdır; ayrılık anında pazarlık edilmesi en zor konulardır.

Hangi işler bakım kapsamı dışında kalır?

Yeni modül ve ekran geliştirme, framework veya veritabanı değişikliği gibi modernizasyon işleri, üçüncü taraf lisans ve servis bedelleri, içerik girişi, trafik artışından doğan altyapı büyütmesi ve kullanıcı eğitimi tipik olarak kapsam dışıdır. TÜBİTAK BİLGEM YTE rehberi de teknoloji değiştirme ihtiyacından doğan işleri bakım değil, yazılım modernizasyonu olarak sınıflandırır.

Bakım sözleşmesini kaç yıl için imzalamalıyım?

Bir yıllık süre ve otomatik yenileme, taraflara performansı ölçme imkânı verdiği için yaygın tercihtir. Daha uzun süreli taahhütlerde fiyat avantajı aranabilir, ancak bunun karşılığında fesih bildirim süresinin kısa tutulması ve tekrarlayan SLA ihlalinde tazminatsız fesih hakkının sözleşmeye yazılması gerekir.

Yazılım bakım sözleşmesi, yazılım projelerinde en sessiz ama en belirleyici belgedir. İyi yazıldığında teslimden sonra kimse onu okumak zorunda kalmaz; kötü yazıldığında ilk kesintide iki taraf da onu okur ve ikisi de farklı sonuç çıkarır. Aradaki farkı yaratan şey hukuki ustalık değil, kapsamın ve sürelerin somut örneklerle yazılmış olmasıdır.

Elinizde çalışan bir yazılım varsa ilk adım yeni bir sözleşme değil, mevcut durumun envanteri olabilir: hangi çalışma zamanı ve kütüphane sürümleri kullanılıyor, yedekler geri yüklenebiliyor mu, erişim yetkisi kimlerde ve kayıtlar nerede tutuluyor. Bu envanter çıkmadan yazılan kapsam maddesi tahmine dayanır. Mevcut yazılımınızın bakım yükünü birlikte değerlendirmek ya da yeni bir projeye bakım planıyla başlamak için iletişim sayfamızdan bize yazabilir, dilerseniz web yazılım hizmetlerimizi inceleyebilirsiniz.