Uygulama Kaynak Kodu Kime Ait? Sözleşmede Bakmanız Gerekenler

Bu yazıyı büyük ihtimalle bir uygulama teklifi masanızdayken ya da eski yazılımcınızla yollar ayrılmışken okuyorsunuz. Her iki durumda da önce şu üç soruyu cevaplayın:

1. Sözleşmede kaynak kodunun ve fikri hakların size devredileceği açıkça yazıyor mu?
2. Apple ve Google geliştirici hesapları kimin adına açık?
3. Sunucu, veritabanı ve alan adı erişimlerinin yönetici şifresi kimde?

Talha Aslan ve ekibi olarak bu yazıda sahiplik konusunu teknik ve sözleşme tarafıyla birlikte anlatıyoruz. Mağaza süreçlerini Apple ve Google'ın resmi yardım sayfalarından doğruladık. Önemli bir not: bu yazı genel bilgilendirmedir, hukuki danışmanlık değildir. Sözleşmenizi imzalamadan önce mutlaka bir avukata inceletin.

Kaynak kodu, paket dosyası ve fikri mülkiyet arasındaki fark nedir?

Bu üç kavram sık karışır, oysa sözleşmede her birini ayrı ele almanız gerekir. Kaynak kodu, yazılımcının yazdığı ve düzenleyebildiği dosyalardır. Paket dosyası ise telefona yüklediğiniz, çalışmaya hazır uygulamadır; onu değiştiremez, yalnızca çalıştırabilirsiniz. Fikri mülkiyet ise bu eserin üzerindeki kullanma, çoğaltma, değiştirme ve dağıtma haklarının toplamıdır.

Örneğin yazılımcı size yalnızca mağazadaki uygulamayı teslim ederse elinizde çalışan bir ürün olur, ama yeni bir özellik eklemek istediğinizde başka bir ekip işe başlayamaz. Öte yandan kaynak kodunu bir klasör olarak alsanız bile sözleşmede hak devri yoksa o kodu çoğaltma ve değiştirme yetkiniz tartışmalı kalabilir.

Dolayısıyla güvenli bir sözleşme üç şeyi birlikte ister: kodun fiziksel teslimi, hakların yazılı devri ve uygulamayı yeniden derleyip yayınlamanızı sağlayan erişimler. Bunlardan biri eksikse sahiplik kâğıt üzerinde kalır.

Sözleşmede yazmıyorsa uygulama kaynak kodu kimde kalır?

Sözleşme sessizse uygulama kaynak kodu üzerindeki haklar çoğu durumda kodu yazan tarafta kalır. Türkiye'de Fikir ve Sanat Eserleri Kanunu, bilgisayar programlarını eser olarak korur. Kanun, mali hakların devrinde yazılı sözleşme ve devredilen hakların ayrı ayrı gösterilmesini arar. Yani "uygulama sizin olacak" gibi genel bir cümle her zaman yeterli olmayabilir.

Bunun pratik sonucu şudur: projeyi yaptıran işletme uygulamayı kullanmaya devam eder, ancak kodu başka bir ekibe verip geliştirmek istediğinde itirazla karşılaşabilir. Üstelik bazı yazılımcılar aynı altyapıyı başka müşterilerine de satar ve bunu sözleşmeye aykırı görmez.

Bu nedenle sözleşmeye "kaynak kodu dahil tüm mali hakların süre, yer ve sayı sınırı olmaksızın devri" gibi açık bir madde koydurun. Hangi hakların devredildiğini tek tek saydırın. Mevzuat ve yorumları değişebileceği için güncel durumu bir avukatla teyit edin; biz burada yalnızca genel çerçeveyi anlatıyoruz.

Çalışan, serbest yazılımcı ve ajans arasında hak açısından ne fark var?

Kodu kimin yazdığı, varsayılan durumu değiştirir. Kanun, işçi veya memurun görevini yaparken meydana getirdiği eserlerde hakları kural olarak işverene tanır. Ancak serbest çalışan bir yazılımcı ya da bir ajans sizin çalışanınız değildir. Dolayısıyla onlarla çalışırken devri sözleşmeyle kurmanız gerekir.

Son satır çoğu zaman gözden kaçar. Ajans işi bir dış yazılımcıya yaptırdıysa ve o kişiden hakları devralmadıysa, size devredeceği hak da eksik kalır. Bu yüzden sözleşmeye alt yüklenici taahhüdü ekletin.

Devir maddesinde hangi hakları tek tek saymalısınız?

Devir maddesini genel bir cümleyle geçmeyin; hakları sayarak yazdırın. Biz müşterilerimize sözleşmelerinde en az şu başlıkları görmelerini öneriyoruz:

• İşleme (kodu değiştirme, uyarlama, yeni sürüm üretme) hakkı.
• Çoğaltma hakkı, yani kodu ve uygulamayı kopyalama yetkisi.
• Yayma hakkı: uygulamayı mağazalarda dağıtma ve satma.
• Temsil ve umuma iletim hakları: uygulamayı kullanıcılara internet üzerinden sunma.
• Hakların süre, ülke ve sayı sınırı olmadan devri.
• Hakları üçüncü kişilere yeniden devretme ya da lisanslama yetkisi.

Ayrıca devrin kapsadığı unsurları da listeleyin: kaynak kodu, veritabanı şeması, arayüz tasarım dosyaları, ikon ve görseller, metinler ve teknik dokümantasyon. Örneğin tasarımı ayrı bir tasarımcı yaptıysa, tasarım dosyalarının hakları da ayrıca devredilmelidir.

Son olarak devrin ne zaman gerçekleştiğini yazdırın. Kimi sözleşmelerde devir son ödemeyle, kimisinde her teslim aşamasıyla olur. Hangisini seçerseniz seçin, belirsiz bırakmayın.

Lisans mı, devir mi: hangisini istemelisiniz?

Devir, hakların size geçmesi demektir; lisans ise yazılımcının hak sahibi olarak kalıp size kullanma izni vermesidir. Uygulama işinizin merkezindeyse genellikle devir daha güvenlidir. Çünkü ileride yazılımcı değiştirebilir, uygulamayı satabilir ya da yatırım alırken sahipliği kanıtlayabilirsiniz.

Öte yandan lisans her zaman kötü değildir. Hazır bir rezervasyon veya sipariş altyapısını aylık bedelle kiralıyorsanız, size özel bir kod zaten yazılmıyordur. Bu durumda önemli olan, lisans sözleşmesinin şartlarıdır: süresi, sona erince verilerinize ne olacağı ve fiyat artışlarının sınırı.

Peki karma modelde ne olur? Pek çok ajans, kendi geliştirdiği ortak altyapıyı lisansla, size özel yazdığı bölümleri ise devirle verir. Bu makul bir yaklaşımdır; yeter ki hangi dosyanın hangi gruba girdiğini sözleşmede listeleyin. Aksi takdirde "bu modül bizim altyapımız" itirazıyla her şeyi tartışmaya açarsınız.

Teklifleri karşılaştırırken bu ayrımı mutlaka sorun. Bunun için hazırladığımız mobil uygulama teklifini değerlendirme rehberindeki sorular işinizi kolaylaştırır.

Hazır bileşenler ve açık kaynak kütüphaneler ne olur?

Hiçbir modern uygulama tamamen sıfırdan başlamaz. Geliştiriciler giriş, harita, grafik ve ödeme gibi işler için açık kaynak kütüphaneler ve ticari bileşenler kullanır. Bu kütüphanelerin hakları size devredilemez, çünkü yazılımcı da onların sahibi değildir. Sizin elde edeceğiniz şey, onları kendi lisans şartlarına göre kullanma hakkıdır.

Bu yüzden sözleşmeye "kullanılan üçüncü taraf bileşenlerin listesi ve lisans türleri teslimde verilecektir" maddesini ekletin. Bazı açık kaynak lisansları, kodunuzu da açmanızı gerektirebilecek şartlar içerir. Böyle bir bileşen kullanılacaksa önceden onayınızın alınmasını isteyin.

Ücretli bileşenler için de dikkatli olun. Ajans lisansı kendi adına aldıysa, ajansla yollar ayrıldığında o bileşeni kullanamayabilirsiniz. Bu nedenle ücretli lisansların doğrudan sizin adınıza alınmasını şart koşun. Benzer bir mantığı native ve cross-platform kararında da göreceksiniz; seçilen teknoloji, hangi bileşenlere bağımlı kalacağınızı da belirler.

Apple ve Google geliştirici hesabını kimin adına açmalısınız?

Geliştirici hesapları uygulamayı yayınlayan kişinin ya da kurumun adına açık olmalıdır, yani sizin adınıza. Apple, Apple Developer Program kayıt sayfasında bireysel kayıtta kişinin adının, kurum kaydında ise kurumun adının App Store'da satıcı adı olarak göründüğünü belirtiyor. Apple, kurum kaydı için D-U-N-S numarası da istiyor.

Google tarafında da benzer bir ayrım var. Play Console hesap türü sayfası, bir kurum veya işletme için hesap açıyorsanız kuruluş hesabı seçmenizi ve bunun için D-U-N-S numarası sağlamanızı istiyor. Kayıt sırasında takılırsanız Apple Developer kaydı ve D-U-N-S rehberimize bakabilirsiniz.

Ajans kendi hesabından yayın yaptığında bu, kısa vadede pratik bir çözüm gibi durur. Ancak bu durumda mağazada satıcı adı ajans olur, kullanıcı yorumları ve indirme istatistikleri de ajansın hesabında birikir. Doğru yol, hesabı sizin adınıza açmak ve ajansa kullanıcı olarak yetki vermektir. Her iki mağaza da hesap sahibinin ekip üyelerini davet edip rol atamasına izin verir.

Hesap sahibi rolünü neden kendinizde tutmalısınız?

Apple tarafında her üyeliğin bir Hesap Sahibi (Account Holder) rolü vardır. Apple'ın rol belgelerine göre yasal anlaşmaları kabul etmek ve üyeliği yenilemek bu role aittir; yöneticileri de ilk olarak bu kişi ekler. Google Play'de ise hesap sahibi, Play Console'a tam erişimi olan ve ödeme profilini bağlayabilen ilk kayıtlı hesaptır.

Kısacası hesap sahibi rolü, uygulamanın anahtarıdır. Bu rolü ajansa bırakırsanız, uygulamanız teknik olarak sizin olsa bile pratikte başkasının kontrolündedir. Örnek senaryo: üyelik yenileme tarihi gelir, ajans bunu takip etmez ve uygulama mağazadan kalkar. Siz de müdahale edemezsiniz.

Bunun yerine şu düzeni kurun:

1. Hesabı işletmenizin adına ve kurumsal bir e-posta adresiyle açın.
2. Hesap sahibi rolünü işletmeden bir yetkilide tutun.
3. Geliştirici ekibe yalnızca işini yapacak kadar yetki verin.
4. Proje bitince ya da ekip değişince yetkileri gözden geçirip kapatın.

Bu yaklaşım, sosyal medya ve reklam hesaplarında önerdiğimiz düzenle aynıdır. Genel çerçeve için dijital varlık yönetimi rehberimize göz atabilirsiniz.

Ajans kendi hesabından yayınladıysa uygulamayı nasıl taşırsınız?

Her iki mağaza da uygulamanın bir geliştirici hesabından diğerine taşınmasına izin veriyor; yani uygulamayı silip yeniden yayınlamanız gerekmez. Apple'ın uygulama aktarımı genel bakış sayfasına göre aktarımı devreden üyeliğin Hesap Sahibi başlatır, alan hesabın Hesap Sahibi kabul eder. Uygulama yorumlarını, puanlarını ve paket kimliğini korur; kullanıcılar güncellemeleri almaya devam eder.

Apple'ın aktarım kriterleri sayfası da bazı şartlar sayıyor. Örneğin uygulamanın App Store'da yayına çıkmış en az bir sürümü olmalı ve uygulama incelemede beklemiyor olmalı. Ayrıca iki tarafın da güncel ücretli ve ücretsiz anlaşmaları kabul etmiş olması gerekiyor.

Google tarafında ise Play Console uygulama aktarma sayfası süreci anlatıyor. Talebi asıl hesap sahibi gönderir, hedef hesap sahibi onaylar. Kullanıcılar, indirme istatistikleri, puanlar ve yorumlar hedef hesaba geçer. Ancak toplu dışa aktarım ve kazanç raporları geçmez; bu yüzden onları önceden indirmeniz gerekir. Test gruplarını da yeni hesapta baştan kurmanız gerekir.

Sözleşmenize "ajans, kendi hesabında yayına aldığı uygulamaları talep halinde ve makul sürede işletmenin hesabına aktarır" maddesini ekletin.

İmzalama anahtarları ve sertifikalar neden bu kadar kritik?

Mağazalar, bir güncellemenin gerçekten uygulamanın sahibinden geldiğini dijital imzayla doğrular. Bu imzanın anahtarlarını kaybederseniz güncelleme yayınlamakta zorlanabilirsiniz. Dolayısıyla anahtarlar, kaynak kodu kadar önemli bir teslim kalemidir.

Google'ın Play Uygulama İmzalama sayfası iki anahtarı ayırıyor. Yükleme anahtarını geliştirici tutar ve uygulama paketini yüklemeden önce bununla imzalar. Uygulama imzalama anahtarını ise Google tutar ve kullanıcılara giden paketleri bununla imzalar. Yükleme anahtarı kaybolursa Play Console üzerinden sıfırlama isteyebilirsiniz. Ancak imzalama anahtarını kendiniz yönetiyorsanız ve kaybederseniz, sayfaya göre bu anahtar sıfırlanamaz.

Apple tarafında sertifikalar ve profiller geliştirici hesabına bağlıdır. Hesap sizin adınızaysa, yeni bir ekip bu sertifikaları kendi yetkisiyle yeniden oluşturabilir. Bu nedenle teslimde yükleme anahtarını, şifresini ve hangi hesapta hangi sertifikanın kullanıldığını yazılı olarak isteyin; şifreleri güvenli bir parola yöneticisiyle paylaşın, e-postayla değil.

Sunucu, veritabanı ve API erişimi kimde olmalı?

Çoğu işletme uygulamasının görünen yüzü telefonda, beyni ise sunucudadır. Kullanıcı hesapları, siparişler, randevular ve içerikler bir veritabanında durur. Telefondaki uygulama bu verilere bir API, yani uygulamalar arası veri alışverişi arayüzü üzerinden ulaşır. Uygulama kaynak kodu elinizde olsa bile sunucu erişimi yoksa uygulama çalışmaz.

Bu nedenle sözleşmede şu konuları netleştirin:

• Sunucu ya da bulut hesabının kimin adına ve hangi ödeme yöntemiyle açılacağı.
• Veritabanının yönetici erişiminin ve düzenli yedeklerin kimde tutulacağı.
• API'nin (arka uç yazılımının) kaynak kodunun da devre dahil olduğu.
• Alan adı ve e-posta hesaplarının işletme adına kayıtlı olduğu.
• Kişisel verilerin nerede saklandığı ve kimlerin erişebildiği.

Son madde aynı zamanda yasal bir yükümlülüğe dayanır. Kullanıcı verisi işliyorsanız veri sorumlusu sizsiniz; bu konuyu mobil uygulamada KVKK uyumu yazımızda ayrıntılı anlattık. Web siteleri için yaşanan benzer sorunları da siteyi ve alan adını eski ajanstan geri alma rehberinde bulabilirsiniz.

Üçüncü taraf servis hesaplarını kimin adına açmalısınız?

Bir uygulama yalnızca mağaza hesabı ve sunucudan ibaret değildir. Analiz, çökme raporu, anlık bildirim, harita, e-posta gönderimi ve ödeme gibi işler genellikle ayrı servislerde yürür. Bu servislerin her biri bir hesap, bir fatura ve bir anahtar demektir.

Sık gördüğümüz sorun şudur: yazılımcı geliştirme sırasında bu servisleri kendi kişisel hesabında açar ve proje bittiğinde öyle bırakır. Örnek senaryo: yazılımcının kartının süresi dolar, bildirim servisi durur ve kullanıcılarınız sipariş bildirimi almaz. Sorunun kaynağını bulmak bile günler sürebilir.

Bu yüzden sözleşmeye "yazılımcı, projedeki tüm üçüncü taraf hesapları işletme adına açar veya teslimde işletmeye devreder" maddesini ekletin. Teslimde her servisin adını, hesap sahibini ve fatura bilgisini gösteren bir liste isteyin. Google Play aktarım sayfası da analiz izinleri ve bulut bağlantıları gibi entegrasyonların uygulamayla otomatik taşınmadığını hatırlatıyor; bunları ayrıca güncellemeniz gerekir.

Uygulama kaynak kodu tesliminde hangi kalemler olmalı?

Teslim listesi, sözleşmenin en somut kısmıdır. Biz projelerimizde aşağıdaki tabloyu kullanıyoruz; siz de sözleşmenize ek olarak koydurabilirsiniz.

Tablodaki "dokümantasyon" satırını hafife almayın. Kod elinizde olsa bile nasıl derleneceği yazılı değilse, yeni bir ekibin projeyi anlaması uzun sürer ve size ek maliyet çıkarır.

Uygulama kaynak kodu teslimini ne zaman ve hangi biçimde almalısınız?

Kaynak kodunu proje sonunda tek bir arşiv dosyası olarak almak en zayıf yöntemdir. Çünkü dosyanın gerçekten güncel sürüm olduğunu doğrulamak zordur ve sürüm geçmişi kaybolur. Bunun yerine kodun, sizin adınıza kayıtlı bir kod deposunda (sürüm kontrol sistemi) baştan itibaren tutulmasını isteyin.

Böylece her gün yapılan değişiklikleri görebilir, proje yarıda kalsa bile o ana kadar yazılan koda sahip olursunuz. Ayrıca yazılımcıyı depoya kullanıcı olarak eklediğiniz için, iş bitince erişimini tek tıkla kaldırırsınız.

Teslimi doğrulamak için de basit bir test uygulayın. Bağımsız bir yazılımcıdan, teslim edilen dokümana bakarak uygulamayı sıfırdan derlemesini isteyin. Derleme başarılıysa ve ortaya çıkan uygulama mağazadakiyle aynı çalışıyorsa teslim gerçek demektir. Bu kontrolü son ödemeden önce yapmanızı öneriyoruz.

Kod deposu konusunda bir ayrıntı daha var: deponun sahibi siz olun, yazılımcı ise davetli kullanıcı. Tersi durumda, yani depo yazılımcının hesabındaysa ve siz yalnızca davetliyseniz, erişiminiz tek bir tıkla kapanabilir. Kısacası kontrolün sizde olması için deponun sahiplik ayarına bakmanız yeterlidir.

Ek olarak sözleşmede teslim tarihini ve gecikme durumunda ne olacağını yazdırın. "Proje bitince teslim ederiz" gibi bir ifade, bitişin tanımı tartışmalı olduğunda işe yaramaz.

Bakım ve hata düzeltme süresini sözleşmede nasıl tanımlarsınız?

Yayından sonraki ilk haftalar, gerçek kullanıcıların uygulamayı ilk kez zorladığı dönemdir. Bu yüzden sözleşmede bir garanti dönemi tanımlayın. Bu sürede ortaya çıkan ve teslim edilen kapsamdaki hataları yazılımcı ek ücret almadan düzeltmelidir.

Garanti döneminden sonrası için ayrı bir bakım anlaşması yapın. Bu anlaşmada şunları yazılı hale getirin:

• Hataların önem derecesine göre sınıflandırılması (uygulamayı durduran, bir özelliği bozan, görsel kusur).
• Her sınıf için ilk yanıt ve çözüm süresi.
• İşletim sistemi güncellemelerine ve mağaza kural değişikliklerine uyum işinin kapsamda olup olmadığı.
• Yeni özellik talebinin bakım değil, ayrı iş olduğu.
• Bakım bittiğinde güncel kodun ve erişimlerin yeniden teslimi.

Mağaza tarafındaki zorunlu güncellemeler bakım bütçesinin önemli bir kısmını oluşturur. Bu kalemin maliyete etkisini mobil uygulama geliştirme maliyetini belirleyen etkenler yazımızda anlattık. Kesin süre veya ücret vermiyoruz; her projeyi kendi kapsamıyla ele alıyoruz.

Ödeme takvimini hak devrine nasıl bağlarsınız?

Yazılımcı açısından en büyük risk, işi teslim edip ödemeyi alamamaktır. İşletme açısından ise en büyük risk, ödemeyi yapıp kodu alamamaktır. Bu iki endişeyi aynı anda çözen yöntem, ödemeyi aşamalara bölmek ve her aşamada o aşamanın kodunu teslim almaktır.

Örnek senaryo: projeyi dört aşamaya bölersiniz; tasarım, temel özellikler, tüm özellikler ve yayın. Her aşamanın sonunda yazılımcı kodu deponuza aktarır, siz kontrol edersiniz ve o aşamanın ödemesini yaparsınız. Böylece hiçbir taraf büyük bir risk taşımaz.

Hak devrinin son ödemeyle gerçekleştiğini yazan sözleşmeler de yaygındır ve yazılımcı açısından makul bir talep olabilir. Ancak bu durumda bile kodun depoda sizin erişiminizde durmasını isteyin. Yani devir hukuken son ödemeyle olsa da kodun fiziksel kontrolü baştan sizde olur.

Ayrıca ödeme takvimini, teslim listesindeki kalemlerle eşleştirin. "İşletme son ödemeyi, teslim listesi eksiksiz tamamlandıktan sonra yapar" gibi bir cümle, listedeki her kalemi bağlayıcı hale getirir.

Gizlilik, rekabet ve yeniden kullanım maddeleri neyi korur?

Uygulamanız iş modelinizin bir parçasını yansıtır: fiyatlama mantığı, kampanya kurgusu ya da operasyon akışı. Gizlilik maddesi, yazılımcının proje sırasında öğrendiği bu bilgileri başkalarıyla paylaşmamasını sağlar. Bu maddeyi sözleşme bittikten sonra da geçerli kalacak şekilde yazdırın.

Yeniden kullanım konusu ise daha incedir. Yazılımcılar genel teknik bilgi birikimini elbette başka projelerde de kullanır; bunu yasaklamak gerçekçi değildir. Öte yandan size özel geliştirdiği iş mantığının, ekranların ve içeriklerin rakibinize satılmasını engellemek makul bir taleptir.

Dengeli bir madde şöyle kurulabilir: genel kod parçaları ve bilgi birikimi serbest, size özel iş mantığı, tasarım ve içerik ise sizin olur ve yazılımcı bunları başkasına veremez. Rakip firmalara benzer ürün yapmama yasağı istiyorsanız, bunu makul bir süre ve sektörle sınırlayın. Bu tür maddelerin geçerliliği ülkeden ülkeye değiştiği için avukatınızın görüşünü alın.

Proje yarıda kalırsa ya da yazılımcıyla yollar ayrılırsa ne yaparsınız?

Her proje planlandığı gibi bitmez. Yazılımcı başka işe geçebilir, ajans kapanabilir ya da iletişim kopabilir. Böyle bir durumda paniğe kapılmadan şu sırayla ilerleyin:

1. Sözleşmenizi ve yazışmalarınızı bir klasörde toplayın; devir ve teslim maddelerini işaretleyin.
2. Mağaza hesaplarının, sunucunun ve alan adının kimin adına olduğunu kontrol edin.
3. Sizin adınıza olan hesaplarda tüm yetkili kullanıcıları ve şifreleri gözden geçirin.
4. Yazılımcıdan yazılı olarak, teslim listesindeki eksik kalemleri makul bir süre vererek isteyin.
5. Uygulama ajans hesabındaysa, yukarıda anlattığımız resmi aktarım sürecini başlatmasını talep edin.
6. Yanıt gelmezse hukuki yollar için bir avukata danışın.

Bir uyarı: birilerinin hesaplarınıza izinsiz erişip "kurtarma" yapacağını vaat eden kişilere itibar etmeyin. Başkasının hesabına erişmek veya sahte belgeyle mağaza desteğini yanıltmak hem yasal risk taşır hem de geliştirici hesabınızı tehlikeye atar. Mağazaların sunduğu resmi aktarım yolu ve sözleşmeniz, elinizdeki en güçlü araçlardır.

İmzadan önce sözleşmeyi nasıl kontrol edersiniz?

Tüm bu maddeleri tek bir kontrol listesinde topladık. Sözleşmeyi imzalamadan önce her satıra "evet" diyebiliyorsanız temel riskleri büyük ölçüde kapatmışsınız demektir.

• Kaynak kodu dahil tüm mali hakların devri açıkça ve tek tek yazıyor.
• Devrin süre, ülke ve sayı sınırı yok.
• Ajans ortak altyapı kullanıyorsa, lisansla verdiği dosyaların listesi sözleşmede var.
• Ajans, alt yüklenicilerden hakları devraldığını taahhüt ediyor.
• Apple ve Google geliştirici hesapları işletmenin adına olacak.
• Sunucu, veritabanı, alan adı ve üçüncü taraf hesaplar işletmenin adına.
• Kod baştan işletmenin deposunda duracak.
• Teslim listesi sözleşmenin eki olarak yer alıyor.
• Garanti dönemi ve bakım şartları tanımlı.
• Ödeme takvimi teslim aşamalarına bağlı.
• Gizlilik maddesi sözleşme sonrasında da geçerli.

Listeyi kullanırken her maddenin karşısına sözleşmedeki ilgili madde numarasını yazın. Böylece eksik kalan konuları tek bakışta görürsünüz. Ayrıca yazılımcıya bu listeyi önceden gönderin; ciddi bir ekip bu sorulara rahatlıkla yanıt verir ve sözleşme taslağını buna göre düzenler. Bir maddeye gelince konuyu geçiştiren bir teklif ise size önemli bir uyarı sinyali verir.

Bu liste bir başlangıç noktasıdır. Projenizin özelliklerine göre ek maddeler gerekebilir; bu nedenle son metni bir avukata inceletmeniz en sağlıklı yoldur.

Talha Aslan ve ekibi uygulama projelerinde sahipliği nasıl ele alıyor?

Biz mobil uygulama geliştirme projelerinde sahiplik sorusunu ilk toplantıda konuşuruz. Uygulamanızı biz geliştirir, mağazaya biz çıkarırız; ancak geliştirici hesaplarını, sunucuyu ve kod deposunu baştan sizin adınıza açarız. Biz bu hesaplarda yalnızca işimizi yapacak yetkiyle çalışırız.

Teklifimizde teslim listesini, garanti dönemini ve bakım seçeneklerini ayrı başlıklar halinde gösteririz. Böylece hangi kalemin ne zaman size geçtiğini imzadan önce görürsünüz. Ortak altyapı kullandığımız bir bölüm varsa, bunu da açıkça belirtiriz.

Uygulama fikrinizi netleştirdiyseniz ya da elinizde yarım kalmış bir proje varsa, durumu birlikte değerlendirelim. Mobil uygulama geliştirme hizmetimiz sayfasından teklif isteyebilirsiniz; kapsamı ve teslim listesini projenize göre hazırlarız.