Mobil Uygulama Geliştirme Sözleşmesi: 10 Kritik Madde

Uygulama geliştirme sözleşmesi, bir mobil uygulama projesinde kapsamı, kabul kriterlerini, ödeme takvimini, kaynak kod sahipliğini ve mağaza sorumluluklarını yazıya bağlayan eser sözleşmesidir. Türk hukukunda imza öncesi netleşmesi gereken 10 kritik madde vardır; en çok para kaybettiren madde kabul kriterleridir, çünkü TBK m.477 sessiz kalan müşteriyi eseri kabul etmiş sayar.

Uygulama projelerinde anlaşmazlıkların büyük kısmı kötü niyetten değil, iki tarafın aynı cümleyi farklı anlamasından doğar. "Uygulama bitince teslim edilecek" cümlesi geliştirici için derlenen bir APK dosyası, müşteri için mağazadan indirilen hazır bir ürün demektir. Aradaki fark; mağaza hesabı, inceleme reddi, test cihazları ve ilk sürüm sonrası güncellemeler kaleminde haftalar ve ciddi bir bütçe demektir.

Bu rehber, uygulama geliştirme sözleşmesinin 10 maddesini müşteri tarafından okunacak biçimde sıralar: her maddede sözleşmeye hangi cümlenin gireceğini, dayanağın hangi kanun hükmü olduğunu ve o madde eksik kaldığında pratikte ne olduğunu bulacaksınız. Mobil uygulamaya özgü dört madde (mağaza hesapları, inceleme reddi, platform güncellemeleri, test matrisi) genel yazılım sözleşmesi şablonlarının çoğunda hiç yer almaz.

Bu yazı genel bilgilendirme amaçlıdır; hukuki danışmanlık yerine geçmez. Sözleşmenizi imzadan önce bir avukata okutun; aşağıdaki maddeler görüşmeye hazırlıklı gitmeniz için bir kontrol listesidir.

İçindekiler

• Uygulama geliştirme sözleşmesi neden formalite değil
• 1. Kapsam ve teknik şartname
• 2. Kabul kriterleri ve test süreci
• 3. Ödeme planı ve hakediş bağı
• 4. Gecikme, cezai şart ve temerrüt
• 5. Kaynak kod ve mali hak devri
• 6. Mağaza hesapları ve yayın hakları
• 7. Mağaza reddi ve platform güncellemeleri
• 8. Garanti, bakım ve destek
• 9. Gizlilik ve kişisel veri sorumluluğu
• 10. Fesih, devir ve uyuşmazlık çözümü
• Sözleşmede kırmızı bayraklar
• Sıkça Sorulan Sorular

Uygulama geliştirme sözleşmesi neden formalite değil

Mobil uygulama, web sitesinden farklı olarak iki özel şirketin (Apple ve Google) kurallarına bağlı bir üründür. Yayın izni ne sizin ne de ajansınızın kararına bağlı: Apple'ın açıkladığı rakamlara göre App Review ekibi 2025'te 9,1 milyondan fazla başvuru inceledi ve bunların 2 milyondan fazlasını reddetti — 1,2 milyonu yeni uygulama, 800 bine yakını güncelleme. Yalnız gizlilik ihlali gerekçesiyle reddedilen başvuru sayısı 443 bini aştı (Apple Newsroom, Mayıs 2026).

Yaklaşık her beş başvurudan birinin geri döndüğü bir ortamda "reddi kim düzeltir, kaç tur, ücretsiz mi" sorusunun cevabı sözleşmede yoksa, ilk ret e-postası ulaştığında taraflar pazarlığa oradan başlar. Aynı mantık platform güncellemeleri için de geçerlidir: Google Play, 31 Ağustos 2026'dan itibaren yeni uygulamalar ve güncellemeler için Android 16 (API 36) hedefini şart koşuyor; mevcut uygulamalar da Android 15 (API 35) hedefi olmadan daha yeni sürüm çalıştıran cihazlarda görünmez duruma düşüyor (Google Play hedef API gereksinimleri). Apple tarafında 28 Nisan 2026'dan bu yana App Store Connect'e yüklenen her sürümün Xcode 26 ve iOS 26 SDK ile derlenmesi gerekiyor (Apple Upcoming Requirements).

Bunlar "arıza" değil, takvime bağlı rutin yükümlülüklerdir ve her yıl tekrar eder. Kimin yapacağı ve kimin ödeyeceği imza aşamasında yazılmazsa, uygulamanız bir yıl sonra mağazada görünmez duruma düştüğünde size yalnız bir teslim tutanağı kalacak.

Türk hukukunda yazılım geliştirme kural olarak eser sözleşmesidir: TBK m.470, yüklenicinin bir eser meydana getirmeyi, iş sahibinin de karşılığında bedel ödemeyi üstlendiği sözleşmeyi bu adla tanımlar (Türk Borçlar Kanunu). Bu, sözleşmeniz sessiz kaldığında kanunun devreye gireceğini gösterir — ama kanunun çözümü her zaman sizin lehinize çıkmaz. Aşağıdaki maddelerin yarısı, tam olarak bu "kanun ne der" boşluğunu kapatmak için vardır.

1. Kapsam ve teknik şartname

Uygulama geliştirme sözleşmesinin gövdesine "mobil uygulama geliştirme hizmeti" yazıp detayı eke bırakan bir metin, ekin kendisi imzalı değilse hiçbir şey ifade etmez. SERP'teki şablonların en sık hatası budur: "Ek-A'da tanımlanan kapsam" cümlesi var, Ek-A yok.

Kapsam ekinde şunları arayın:

• Ekran envanteri: uygulamanın ekran sayısı ve adları (giriş, kayıt, ürün listesi, sepet, profil…). Sayı, sonradan "bu ekran kapsamda mıydı" tartışmasını bitirir.
• Özellik listesi ve kabul cümlesi: her özelliğin yanında test senaryosuna çevrilen tek satırlık bir ifade. "Push mesajı gönderilecek" değil; "yönetici panelinden gönderilen bildirim, uygulamayı kapatmış kullanıcının cihazında 60 saniye içinde görünür".
• Platform ve sürüm matrisi: iOS ve Android'in hangi sürümlerinden itibaren destek (örneğin iOS 17+ ve Android 10+), hangi cihazlarda kabul testi yapılacağı, tablet desteği var mı.
• Entegrasyon listesi: ödeme altyapısı, e-fatura, kargo, CRM, harita, analitik. Her entegrasyonun hesabını kimin açacağı ve lisans ya da komisyon ücretini kimin ödeyeceği aynı satırda görünmeli.
• Dil ve içerik: kaç dil, metinleri kim yazar, görselleri kim hazırlar.
• Hariç tutulanlar: kapsam dışı kalemleri açıkça sayın (ör. yönetici paneli, web sitesi, ASO çalışması, içerik girişi).

Kapsamın net yazılması iki tarafı da korur. Bedel götürü (sabit) kararlaştırılmışsa TBK m.480 yükleniciyi o bedele bağlar: eser öngörülenden fazla emek ve masraf gerektirse bile yüklenici kararlaştırılan bedeli artırmayı isteyemez. Buna karşılık bedel yaklaşık olarak kararlaştırılmışsa m.482, bu bedel aşırı ölçüde aşılacaksa iş sahibine sözleşmeden dönme hakkı tanır. İki hüküm de kapsamı net yazan tarafı korur.

Değişiklik yönetimi (change order) maddesini aynı bölüme ekleyin: kapsam dışı her talep yazılı teklife bağlanır, teklifte iş günü ve bedel etkisi ayrı ayrı görünür, onay gelmeden iş başlamaz. Sözleşmeyi götürü bedelle imzaladıysanız bedel artışının damga vergisi sonucu da vardır; Damga Vergisi Kanunu m.14, belli parayı içeren mukavelenamelerin değiştirilmesi durumunda artan miktarın aynı nispette vergiye tabi olduğunu söyler.

Bütçe aralıklarını henüz netleştirmediyseniz mobil uygulama maliyet hesaplayıcı ile kapsam-bütçe ilişkisini önce kendiniz görün; teklif karşılaştırmasına da mobil uygulama fiyatları rehberi ile hazırlıklı gidin.

2. Kabul kriterleri ve test süreci

Bu, uygulama geliştirme sözleşmesinin en pahalı maddesidir ve çoğu metinde tek cümleyle geçer.

TBK m.474, iş sahibine teslimden sonra "işlerin olağan akışına göre imkân bulur bulmaz" eseri gözden geçirme ve ayıpları uygun bir süre içinde yükleniciye bildirme yükümlülüğü getirir. Sonraki madde sert: TBK m.477'ye göre iş sahibi gözden geçirmeyi ve bildirimde bulunmayı ihmal ederse eseri kabul etmiş sayar. Yüklenicinin sorumluluğu da açık veya örtülü kabulden sonra sona erer; yalnız kasten gizlenen ve usulünce incelemede fark edilemeyecek ayıplar için sorumluluğu sürer.

Pratik sonuç şu: teslim e-postasına üç hafta cevap vermeyen bir müşteri, farkında olmadan uygulamayı olduğu gibi kabul eder. Bunu önlemek için sözleşmeye somut bir kabul prosedürü yazın:

• Teslimin nasıl yapılacağı (TestFlight / Play kapalı test bağlantısı + sürüm notu + kabul testi senaryoları).
• Kabul testi süresi: 5-10 iş günü gibi net bir pencere ve bu pencerede kimin test edeceği.
• Hata sınıflandırması: kritik (ödeme geçmiyor, uygulama çöküyor), majör (özellik eksik çalışıyor), minör (yazım/hizalama). Kabulü yalnız kritik ve majör hatalar engeller.
• Düzeltme ve tekrar test döngüsü: düzeltme için kaç iş günü, kaç tur ücretsiz.
• Kısmi kabul: modül modül teslim varsa her modül için ayrı kabul tutanağı düzenlenir.

Ayıplı teslimde TBK m.475 iş sahibine üç seçimlik hak tanır: sözleşmeden dönme, ayıp oranında bedelden indirim ve aşırı masraf gerektirmiyorsa masrafların tamamı yükleniciye ait olacak biçimde ücretsiz onarım. Tazminat isteme hakkı da saklıdır. Süre sınırı ise m.478'de: taşınmaz yapılar dışındaki eserlerde dava açma süresi teslimden itibaren iki yıl, yüklenicinin ağır kusuru varsa yirmi yıldır.

Kabul testi senaryolarını kim yazacak sorusu da sözleşmeye girsin. Test planının nasıl kurulduğunu mobil uygulama testi rehberinde adım adım anlattık; kabul kriterlerini o çerçeveden türetmek, hem müşteri hem ajans için ölçülebilen bir zemin yaratır.

3. Ödeme planı ve hakediş bağı

TBK m.479, iş sahibinin bedel ödeme borcunun eserin teslimi anında muaccel olduğunu söyler. Aynı madde devamında kritik bir imkân tanır: eserin parça parça teslimi kararlaştırılmış ve bedel parçalara göre ayrılmışsa, her parçanın bedeli kendi tesliminde muaccel olacaktır. Hakedişe bağlı ödeme planının kanuni dayanağı budur — ama yalnız bedeli parçalara ayırdıysanız işler.

Uygulama geliştirme sözleşmesinde dengeli bir hakediş yapısı şöyledir:

Son dilimi mağaza yayınına ve kaynak kod teslimine bağlamak, projenin en çok takılan son %10'unu canlı tutar. Ajans tarafında ise peşin oranının makul kalması, ekip tahsisinin karşılığıdır; "işe başlamadan %60" talebi, nakit akışı sorunu olan bir tedarikçi sinyali verir.

Üç noktayı sözleşmeye yazın: her hakedişin faturasının hangi belgeye (kabul tutanağı) bağlandığı, ödeme vadesi (fatura tarihinden kaç gün), ve gecikme faizi oranı. TBK m.120, sözleşmeyle kararlaştırılacak yıllık temerrüt faizinin kanuni orana göre hesaplanan oranın yüzde yüz fazlasını aşamayacağını söyler; bu sınırın üstündeki bir oran sizi korumaz.

4. Gecikme, cezai şart ve temerrüt

Takvim maddesi iki soruya cevap verir: gecikme ne zaman başlar ve sonucu nedir.

Kanun, teslim gününü beklemeden hareket etme imkânı tanır. TBK m.473'e göre yüklenicinin işe zamanında başlamaması veya sözleşmeye aykırı biçimde işi geciktirmesi yüzünden işi kararlaştırılan zamanda bitiremeyeceği açıkça ortaya çıkarsa, iş sahibi teslim için belirlenen günü beklemeksizin sözleşmeden dönebilir. Aynı maddenin ikinci fıkrası daha ölçülü bir yol da sunar: eserin ayıplı çıkacağı açıkça belli olduğunda iş sahibi, uygun bir süre vererek ihtarda bulunur ve bu süre sonunda hasar ve masrafları yükleniciye ait olmak üzere işin üçüncü bir kişiye verileceğini bildirir.

Cezai şart (ceza koşulu) maddesinde üç ayrıntı sonucu değiştirir:

1. Birikimli talep. TBK m.179/2, ceza borcun kararlaştırılan zamanda ifa edilmemesi durumu için konmuşsa, alacaklının asıl borçla birlikte cezayı da isteyebileceğini söyler — ancak hakkından açıkça feragat etmemiş veya ifayı çekincesiz kabul etmemiş olması şartıyla. Geciken teslimi kabul ederken "gecikme cezası haklarımız saklıdır" cümlesini tutanağa yazdırmak, bu yüzden tek satırlık ama pahalı bir detaydır.
2. Zarar şartı yok. m.180'e göre alacaklı hiçbir zarara uğramamış olsa bile kararlaştırılan cezanın ifası gerekir. Zararınız cezayı aşıyorsa aşan kısım için yüklenicinin kusurunu kanıtlamanız gerekir.
3. Hâkim müdahalesi. m.182'nin son fıkrası nettir: hâkim, aşırı gördüğü ceza koşulunu kendiliğinden indirir. "Her gün için sözleşme bedeli üzerinden %5" gibi bir oran kâğıt üstünde caydırıcı görünse de mahkemede ayakta durmaz. Piyasada tutan yapı şudur: gecikilen her takvim günü için sözleşme bedeli üzerinden binde 1, toplamda ise %10'u aşmayan bir tavan.

Gecikmenin karşı tarafı da yazılsın: müşteri kaynaklı gecikmeler (içerik gelmemesi, onay verilmemesi, test edilmemesi, API erişiminin açılmaması) takvimi uzatır ve bunları sayan bir fıkra yoksa tüm gecikmenin muhatabı yüklenici olacaktır. Mücbir sebep tanımını da bu maddede tutun.

5. Kaynak kod ve mali hak devri

Kaynak kodu teslim almanız, hak sahibi olmanızla aynı şey anlamına gelmez. FSEK m.57, bir eserin nüshasına malik olmanın eser üzerindeki mali hakları da kazandırmadığı mantığını kurar; kodun sizde olması, onu değiştirip yeni sürüm çıkarma hakkını kendiliğinden vermez.

Fikri haklar maddesinde dört hüküm sonucu değiştirir (Fikir ve Sanat Eserleri Kanunu):

• FSEK m.52: mali haklara dair sözleşme ve tasarrufların yazılı olması ve konuları olan hakların ayrı ayrı gösterilmesi şarttır. "Tüm hakları müşteriye aittir" cümlesi bu şartı karşılamaz; çoğaltma, yayma, işleme, temsil ve umuma iletim haklarını tek tek sayın.
• FSEK m.48/3: henüz vücuda getirilmemiş veya tamamlanacak bir esere ilişkin devir işlemleri batıldır. Yani proje başında imzalanan peşin devir cümlesi hükümsüzdür.
• FSEK m.50: buna karşılık bu tasarruflara dair taahhütler, eser henüz meydana getirilmeden önce yapılsa bile geçerlidir. Doğru kurgu iki aşamalıdır: sözleşmede devir taahhüdü, teslimde (veya son ödemede) ayrı bir devir beyanı.
• FSEK m.49: hakkı veya kullanma ruhsatını devralan kimse, bunu ancak eser sahibinin yazılı muvafakatiyle başkasına devredebilir; işleme hakkının devrinde de aynı muvafakat şarttır. Ajansınız freelancer veya alt yüklenici kullanıyorsa, zincirin her halkasında yazılı devir arayın.

Sözleşmeye ayrıca şunları yazın: hangi depoda (repository) çalışılacağı ve deponun kimin hesabına ait olduğu, teslim paketinin içeriği (kaynak kod, derleme talimatı, ortam değişkenleri, mimari dokümantasyon, tasarım dosyaları), ajansın kendi hazır kütüphaneleri için verilecek lisansın kapsamı ve kullanılan açık kaynak bileşenlerin lisans listesi. Deponun müşteri şirketi adına açılması, ajansın davetli kullanıcı olarak çalışması en temiz yapıdır.

FSEK m.38'in dördüncü fıkrası bir güvenlik ağı sunar: bilgisayar programını yasal yollardan edinen kişinin programı yükleme, çalıştırma ve hatalarını düzeltme hakkı ile kullanım için gerekli bir adet yedekleme kopyası yapma hakkı sözleşmeyle önlenemez. Bu, kötü bir sözleşmeyi kurtarmaz ama sizi tamamen kilitli bırakmaz.

Konunun hukuki arka planı için yazılım sözleşmesinde kod sahipliği yazımız maddeleri daha derin işliyor; teslim paketinin teknik içeriğini ise kaynak kod teslimi rehberinde bulacaksınız. Ajansın kapanması riskine karşı kaynak kod emaneti (escrow) de bir seçenektir; emanetçi kurum, kodu sözleşmede sayılan koşullar gerçekleştiğinde size açar.

6. Mağaza hesapları ve yayın hakları

Mobil projeyi web projesinden ayıran en kritik madde budur; genel şablonlarda hazırlanan uygulama geliştirme sözleşmesi metinlerinde çoğu zaman hiç yoktur.

Uygulamanız kimin geliştirici hesabından yayınlanacak? Doğru cevap neredeyse her zaman "müşterinin tüzel kişiliği adına açılmış hesaptan" biçimindedir; ajans App Store Connect ve Play Console'a kullanıcı olarak eklenir. Hesap bedelleri bunu kolaylaştıracak kadar düşüktür: Apple Developer Program yıllık 99 USD (Apple Developer Enterprise Program 299 USD) (Apple), Google Play tarafında ise 25 USD tek seferlik kayıt ücreti vardır (Play Console).

Hesap tipini de sözleşmeye yazın. Google Play, 13 Kasım 2023'ten sonra açılan kişisel geliştirici hesaplarına üretim erişimi için ek bir şart koşuyor: uygulamanın en az 12 test kullanıcısıyla, kesintisiz en az 14 gün kapalı testten geçmesi gerekiyor (Play Console Yardım). Kurumsal hesapta bu şart aranmaz. Takvimi kişisel hesaba göre kuran bir proje, iki haftayı baştan kaybeder.

Uygulama yanlış hesapta yayınlandıysa devir mümkündür, ama koşullu. Apple'ın app transfer kriterleri şunları sayar: uygulamanın App Store'da yayınlanmış en az bir sürümü olması; hiçbir ülkede ön siparişe açık olmaması; "Waiting for Review", "In Review", "Processing for Distribution", "Accepted", "Pending Developer Release" veya "Pending Apple Release" statülerinde bulunmaması; uygulama içi satın alma ürün kimliklerinin alıcı hesaptaki ürün kimlikleriyle çakışmaması. Apple Arcade uygulamaları devredilemez (Apple app transfer criteria). İyi haber: Apple'ın belgelediğine göre devir sırasında ve sonrasında uygulama yorumlarını ve puanlarını korur, kullanıcılar güncelleme almaya devam eder.

Bu maddede netleştirilecek diğer başlıklar:

• Mağaza vitrini (store listing) metinleri, ekran görüntüleri, tanıtım videosu kimin işi.
• Yaş derecelendirmesi, gizlilik etiketleri ve veri beyanlarını kimin dolduracağı. Apple, 31 Ocak 2026'dan bu yana güncellenmiş yaş derecelendirme sorularına cevap verilmesini şart koşuyor.
• Avrupa Birliği'nde satış yapıyorsanız Dijital Hizmetler Yasası kapsamındaki "trader" (tacir) beyanı. Apple, bu beyanı verilmeyen uygulamaların AB'de App Store'dan kaldırıldığını duyurdu; beyanı veren tarafın müşteri şirketi olması gerekir.
• Sertifika, imzalama anahtarları ve Play App Signing yetkilerinin teslim listesi.

Yayın sürecinin tamamını mobil uygulama nasıl yayınlanır yazısında anlattık; imza öncesi hazırlık için uygulama yayın kontrol listesi aracımızı ajansla birlikte doldurun.

7. Mağaza reddi ve platform güncellemeleri

Yukarıdaki Apple rakamları bu maddenin neden gerektiğini gösteriyor. Sözleşmede üç soruya cevap arayın.

Birincisi: reddi kim giderir? Kapsam kaynaklı redleri (eksik işlev, çöken uygulama, bilgi ekranı olmayan abonelik) yüklenici ücretsiz düzeltir; iş modeli veya içerik kaynaklı redleri (mağaza politikasına aykırı bir hizmet, lisanssız içerik) müşteri çözer. Apple'ın 2.1 maddesi, başvurunun eksiksiz ve cihazda test edilen bir sürüm olmasını, giriş gerektiren uygulamalarda demo hesap verilmesini açıkça ister; bu, yükleniciye ait bir yükümlülüktür. Sık görülen ret gerekçelerini App Store uygulama reddi yazısında derledik.

İkincisi: kaç tur ve ne kadar süre? "İlk yayın başarıyla tamamlanana kadar" ifadesi en temiz çözümdür. Buna bir dış sınır ekleyin: ilk gönderimden itibaren 60 gün gibi.

Üçüncüsü: platformun yıllık zorunlulukları kimin işi? Hedef API yükseltmesi, yeni SDK ile yeniden derleme, kaldırılan izinlerin yerine yenisinin eklenmesi her yıl tekrarlayan bir bakım kalemidir. Google Play'in 31 Ağustos 2026 tarihli Android 16 (API 36) şartı için uzatma talebi yalnız 1 Kasım 2026'ya kadar süre tanıyor; kurum içi dağıtıma kapalı özel uygulamalar bu şartın dışında tutuluyor. Apple'ın Xcode 26 / iOS 26 SDK şartı ise 28 Nisan 2026'dan beri yürürlükte. Bu kalemleri ilk yıl garanti kapsamına mı, bakım sözleşmesine mi koyacağınızı imza aşamasında kararlaştırın — sonradan konuşulan her kalem ek teklif olarak döner.

8. Garanti, bakım ve destek

Garanti ile bakım farklı iki şeydir ve uygulama geliştirme sözleşmesinde ikisini aynı paragrafa sıkıştırmak pahalı bir alışkanlıktır. Garanti, teslim edilen kapsamın sözleşmeye uygun çalışmamasını ücretsiz onarır; bakım, zaman geçtikçe doğan yeni ihtiyaçları karşılar. Sözleşmede ikisini ayrı başlıklara koyun.

Garanti bölümünde süre (uygulamalarda yaygın pratik 3-6 ay), kapsam (kabul gören özelliklerdeki hatalar) ve kapsam dışı kalemler (yeni özellik, üçüncü taraf servis değişikliği, müşteri tarafında yapılan müdahaleler) yer alsın. TBK m.478'deki iki yıllık dava zamanaşımının sözleşmedeki garanti süresinden bağımsız işlediğini unutmayın; kısa bir garanti süresi, ayıba karşı tekeffül haklarınızı kendiliğinden ortadan kaldırmaz.

Bakım ve destek bölümünde beş kalem netleşsin: aylık/yıllık bedel ve neyi kapsadığı, destek kanalı ve çalışma saatleri, hata sınıfına göre ilk yanıt ve çözüm süreleri (SLA), sunucu-servis maliyetlerinin kime ait olduğu, yıllık güncelleme kotası (örneğin yılda iki küçük sürüm). Bakım bütçesini planlarken mobil uygulama bakım maliyeti yazısındaki kalemleri referans olarak kullanın; sözleşme metninin yapısı için yazılım bakım sözleşmesi rehberimiz hazır bir iskelet sunuyor.

9. Gizlilik ve kişisel veri sorumluluğu

Uygulamanız kullanıcı verisi topluyorsa (neredeyse hepsi toplar) uygulama geliştirme sözleşmesinin bir veri işleme bölümü olmalı.

KVKK m.12'nin ikinci fıkrası doğrudan sizi ilgilendirir: veri sorumlusu, kişisel verilerin kendi adına başka bir gerçek veya tüzel kişi tarafından işlenmesi durumunda, güvenlik tedbirlerinin alınması hususunda bu kişilerle birlikte müştereken sorumludur (6698 sayılı Kanun). Yani ajansın test ortamına kopyaladığı gerçek kullanıcı verisi sızarsa, muhatap yine siz olacaksınız. Aynı maddenin dördüncü fıkrası, veri sorumlusu ve veri işleyenin öğrendikleri kişisel verileri Kanuna aykırı biçimde açıklamama ve işleme amacı dışında kullanmama yükümlülüğünün görevden ayrıldıktan sonra da sürdüğünü söyler.

Sözleşmeye şu cümleleri ekleyin: geliştirme ve test ortamlarında gerçek kullanıcı verisi yerine maskelenmiş veri kullanılacak; ajans erişimleri proje bitiminde kapatılır ve kopyalar silinir; alt yüklenici kullanımı müşterinin yazılı onayına bağlıdır; veri ihlali durumunda ajans müşteriyi kaç saat içinde bilgilendirir. Gizlilik yükümlülüğünün süresini de yazın — proje bitiminden sonra devam eden 2-5 yıllık bir süre yaygındır.

Fikir aşamasında görüşme yapıyorsanız gizlilik sözleşmesinin ne işe yaradığını ve sınırlarını uygulama fikri nasıl korunur yazısında ayrıntılı anlattık.

10. Fesih, devir ve uyuşmazlık çözümü

Hiç kimse projeye fesih düşünerek başlamaz; uygulama geliştirme sözleşmesinin bu bölümü tam da bu yüzden okunmadan imzalanır.

TBK m.484 iş sahibine güçlü bir hak verir: eserin tamamlanmasından önce, yapılmış kısmın karşılığını ödemek ve yüklenicinin bütün zararlarını gidermek koşuluyla sözleşmeyi feshedebilir. "Bütün zararları gidermek" ifadesi burada ucu açık bir risk yaratır; sözleşmede fesih sonucunu önceden rakama bağlamak iki tarafın da işine gelir. Örneğin: fesih hâlinde o ana kadar kabul gören hakedişler ödenir, devam eden sprintin bedeli oranlanır, teslim edilen kodun mali hakları ödenen bedelle sınırlı biçimde devredilir.

Fesih maddesine ayrıca şunları ekleyin: haklı fesih sebepleri (ödemede 30 günü aşan gecikme, takvimin X günü aşması, gizlilik ihlali), fesih bildiriminin biçimi (KEP, noter veya iadeli taahhütlü), ve çıkış (exit) prosedürü — fesih tarihinden itibaren kaç gün içinde kaynak kod, dokümantasyon, hesap erişimleri ve varsa veritabanı yedeği teslim edilir.

Uyuşmazlık bölümünde üç ayrıntıyı atlamayın:

• Arabuluculuk zorunluluğu. TTK m.5/A, konusu bir miktar para olan alacak ve tazminat davalarında dava açılmadan önce arabulucuya başvurulmuş olmasını dava şartı sayar. Arabulucu başvuruyu görevlendirildiği tarihten itibaren altı hafta içinde sonuçlandırır, zorunlu hâllerde süre en fazla iki hafta uzar (Türk Ticaret Kanunu). Bu süreci sözleşmeye yazmasanız da işler, ama takvim beklentinizi buna göre kurun.
• Yetkili mahkeme. Tacirler arasında yetki sözleşmesi geçerlidir; hangi şehrin mahkemelerinin yetkili olacağını yazın. Boş bırakılan bir yetki maddesi, uyuşmazlığı karşı tarafın şehrine taşır.
• Damga vergisi. Kimin ödeyeceğini yazın, ama sınırını da görün: Damga Vergisi Kanunu m.3'e göre mükellef kâğıtları imza edenlerdir ve m.24, birden fazla kişi tarafından imzalanan kâğıtlara ait vergi ve cezanın tamamından imza edenleri müteselsilen sorumlu tutar. Sözleşmedeki "damga vergisini müşteri öder" cümlesi taraflar arasında rücu ilişkisi kurar, idareye karşı sorumluluğu ortadan kaldırmaz. Oran, belli parayı içeren mukavelenamelerde binde 9,48'dir; nispi vergide nüsha sayısı fark etmez, m.5 yalnız bir nüshanın vergiye tabi olduğunu söyler (488 sayılı Kanun). Sözleşme süresinin uzatılması veya bedel artışı ise yeniden vergi doğurur.

Sözleşmede kırmızı bayraklar

Bir uygulama geliştirme sözleşmesinde şu ifadeleri gördüğünüzde soru sorun. Hiçbiri tek başına kötü niyet göstermez; hepsi netleştirilmeden imzalanmaması gereken cümlelerdir.

Teklifleri karşılaştırırken bu tabloyu ajans seçim kriterleriyle birlikte okuyun: yazılım firması nasıl seçilir yazısındaki sorular, sözleşme öncesi görüşmeyi çok daha verimli yapar.

Sıkça Sorulan Sorular

Uygulama geliştirme sözleşmesi noterden onaylanmalı mı?

Hayır. Uygulama geliştirme sözleşmesi için noter onayı geçerlilik şartı değil; yazılı ve imzalı olması yeterlidir. Ancak mali hak devri bakımından FSEK m.52 yazılı şekil şartı koyar, bu yüzden sözleşmenin ve devir beyanının ıslak imza veya nitelikli elektronik imzayla imzalanmış bir metin olarak saklanması gerekir. Noter onayı yalnız ispat kolaylığı sağlar.

Sözleşme yapmadan geliştirilen uygulamanın kaynak kodu kime ait?

Yazılı bir mali hak devri yoksa eser sahibi, kodu yazan taraftır; müşteri, ödeme yapmış olsa dahi mali haklara kendiliğinden sahip olmaz. Bu durumda FSEK m.38'in güvencesi devreye girer: programı yasal yoldan edinen kişinin yükleme, çalıştırma, hata düzeltme ve bir yedek kopya hakkı sözleşmeyle engellenemez. Yeni sürüm çıkarma ve üçüncü kişiye devretme hakkı için yazılı devir şarttır.

Gecikme cezası için üst sınır var mı?

Kanun bir üst sınır koymaz; TBK m.182 tarafların ceza miktarını serbestçe belirleyebileceğini söyler. Ama aynı maddenin son fıkrası hâkimin aşırı gördüğü ceza koşulunu kendiliğinden indireceğini düzenler. Bu nedenle pratikte işleyen yapı şudur: gecikilen her gün için sözleşme bedeli üzerinden binde 1 ve toplamda %10'u aşmayan bir tavan.

Kabul sonrası çıkan hatalarda hangi süre işler?

TBK m.478, taşınmaz yapılar dışındaki eserlerde ayıp sebebiyle açılacak davaların teslim tarihinden itibaren iki yılda zamanaşımına uğradığını, yüklenicinin ağır kusuru varsa bu sürenin yirmi yıl olduğunu düzenler. Ayrıca m.477, kasten gizlenen ve usulünce incelemede fark edilemeyecek ayıplarda yüklenicinin sorumluluğu kabulden sonra da devam ettiğini söyler.

Mağaza hesabı ajansın adına açıldıysa ne yaparım?

Uygulamayı kendi hesabınıza devralmayı isteyin. Apple'ın app transfer süreci bunu destekler; uygulamanın App Store'da yayınlanmış en az bir sürümü olmalı, inceleme veya yayın bekleyen statülerde olmamalı ve ön siparişe açık olmamalıdır. Devir sırasında uygulama yorumlarını ve puanlarını korur. Devirden sonra eski hesap, devir öncesi satış verilerini görmeye devam eder; sonraki satış verilerine erişimi kapanır.

Uyuşmazlıkta doğrudan dava açmak mümkün mü?

Konusu bir miktar para olan alacak veya tazminat talebiyle ticari dava açacaksanız hayır: TTK m.5/A arabulucuya başvurmuş olmayı dava şartı sayar. Arabuluculuk süreci altı hafta içinde sonuçlanır, zorunlu hâllerde en fazla iki hafta uzar. Anlaşma sağlanırsa tutanak ilam niteliği taşır.

Bakım sözleşmesi ana sözleşmeye mi girer, ayrı mı imzalanır?

İkisi de mümkündür, ama ayrı imzalamak daha sağlıklıdır. Garanti süresi boyunca hata düzeltme ana sözleşmenin yükümlülüğüdür; bu süre bittikten sonra başlayan bakım, farklı bir fiyatlama ve farklı bir SLA mantığı taşır. Ayrı sözleşme, bakımı yenilemediğinizde ana sözleşmedeki devir ve garanti hükümlerini etkilemez.

Kapsam dışı taleplerde ek ücret istemeyen ajans daha mı iyi?

Hayır; bu çoğu zaman kapsamın yeterince net yazılmadığını gösterir. Her talebi "hallederiz" diyerek karşılayan bir süreç, takvimin kaymasıyla ve kalite düşüşüyle sonuçlanır. Sağlıklı yapı, küçük düzeltmeler için aylık bir kota tanımlamak ve bunun üstündeki talepleri yazılı değişiklik teklifine bağlamaktır.

Uygulama geliştirme sözleşmesi, projenin kalitesini garanti etmez; ama anlaşmazlık çıktığında hangi tarafın güçlü olacağına karar verir. Bu on maddeyi teklif aşamasında masaya koyduğunuzda geliştirici tarafı sizi daha ciddiye alacak — çünkü sorularınız, hangi kalemlerin gerçekten maliyet yarattığını bildiğinizi gösterir.

Mobil uygulama projenizin kapsamını, hakediş planını ve teslim paketini netleştirmek için mobil uygulama geliştirme hizmetimize göz atın; sözleşme öncesi kapsam görüşmesi için bizimle iletişime geçin ve projenizin madde madde çıkarılmış kapsam ekini birlikte hazırlayalım.