Yazılım Geliştirme Sözleşmesi: Kapsamlı Rehber + Ücretsiz Şablon

Çoğu yazılım projesi, geliştiricilerin kodlama konusunda kötü olmasından dolayı başarısız olmaz. Başarısızlık nedeni, kimsenin "tamamlandı"nın ne anlama geldiğini yazılı hale getirmemesidir. Standish Group'un CHAOS Raporu, yazılım projelerinin başarı oranını yalnızca %31 olarak belirlemektedir — ve kapsam anlaşmazlıkları, belirsiz IP sahipliği ile tartışmalı ödeme koşulları en yaygın suçlulardır.

Bir yazılım geliştirme sözleşmesi, çalışmalar başlamadan önce tüm bu sorunları çözer. Müşteri ile geliştirici (veya ajans) arasındaki sözleşme, neyin yapılacağını, kime ait olacağını, ne kadara mal olacağını ve bir şeyler ters gittiğinde ne olacağını tanımlar. Onsuz, iyi niyete ve hafızaya güveniyorsunuz — ve mahkemeler ikisini de kabul etmez.

Bu rehber her şeyi kapsar: ne zaman bir yazılım geliştirme sözleşmesine ihtiyacınız olduğu, dört sözleşme türü ve her birinin ne zaman kullanılacağı, gerçekten önemli olan her madde ve projeniz için özelleştirebileceğiniz ücretsiz indirilebilir bir şablon. Temel bilgileri zaten biliyorsanız ve doğrudan şablona geçmek istiyorsanız, şablon bölümüne atlayın. Aksi takdirde, bağlam önemlidir — özellikle IP bölümü, çoğu sözleşmenin sessizce başarısız olduğu yerdir. Sözleşmelerin anlaşmalardan nasıl farklıldığına daha geniş bir bakış için, sözleşme vs. anlaşma rehberimiz bilmeniz gereken yasal ayrımları kapsar.

Bir yazılım geliştirme sözleşmesi (SDA), bir müşteri ile yazılım geliştirici veya geliştirme şirketi arasında yapılan hukuken bağlayıcı bir sözleşmedir. İş kapsamını, ödeme yapısını, teslimat takvimini, fikri mülkiyet sahipliğini, gizlilik koşullarını ve herhangi bir tarafın anlaşmadan çıkması gerektiğinde ne olacağını tanımlar.

SDA bir teklif, proje özeti veya çalışmayı onaylayan bir Slack mesajı değildir. Geliştirme başlamadan önce her iki tarafın da kabul ettiği şeyin resmi yasal kaydıdır. İmzalandıktan sonra, bir anlaşmazlık olması durumunda başvuracağınız belgedir — ve dava açılması durumunda mahkemenin okuyacağı belgedir.

Bir SDA'nın kapsadığı konular

Düzgün hazırlanmış bir yazılım geliştirme sözleşmesi şunları ele alır:

• İş kapsamı — geliştiricinin ne inşa edeceği, üçüncü bir tarafın tamamlanıp tamamlanmadığını değerlendirebileceği kadar spesifik
• Teslimatlar ve kilometre taşları — ne teslim edileceği, hangi formatta ve ne zamana kadar
• Ödeme koşulları — toplam ücret, ödeme programı ve her ödemeyi tetikleyen koşul
• IP sahipliği — kod yazıldıktan sonra kime ait olduğu
• Gizlilik — her tarafın gizli tutması gereken tescilli bilgiler
• Kabul testi — müşterinin teslim edilen yazılımın gereksinimleri karşılayıp karşılamadığını nasıl değerlendirdiği
• Garantiler — geliştiricinin yazılımın işlevselliği hakkında ne garanti ettiği
• Fesih koşulları — her iki tarafın da sözleşmeyi nasıl sonlandırabileceği ve tamamlanan çalışmalara ne olacağı

Bazı müşteriler SDA'yı bir İş Tanımı Beyanı (SOW) ile karıştırır. Örtüşme vardır, ancak aynı şey değildirler — ve bu ayrım önemlidir. MSA ve SOW arasındaki ilişki, bu belgelerin uzun vadeli çalışmalarda nasıl birlikte çalıştığını açıklar.

Kısa cevap: birine yazılım geliştirmesi için ödeme yaptığınızda veya bunu yapmak için para aldığınızda.

Sözleşme, iki haftalık bir proje için tek başına bir freelancer tutmanızda veya 12 aylık bir ürün geliştirmesi için 20 kişilik bir ajansla çalışmanızda önemlidir. Ölçek değişir; yazılı koşullara olan ihtiyaç değişmez.

Bir yazılım geliştirme sözleşmesine sahip olmanız gereken durumlar:

• Yazılım geliştirmeyi dış kaynak kullanarak yaptırıyorsunuz — özellikle yetki alanı farklılıklarının gayri resmi anlaşmaları karmaşıklaştırdığı offshore veya uzaktan ekiplere
• Özel yazılım geliştiriliyor — iş ne kadar özel olursa, IP sahipliğinin açıkça belgelenmesi o kadar gerekli olur
• Birden fazla geliştirme aşaması var — kilometre taşı tabanlı ödemeler, her aşamayı tetiklemek için yazılı kabul kriterleri gerektirir
• Hassas veri veya sistemler söz konusu — müşteri verilerine dokunan her proje gizlilik ve güvenlik maddelerine ihtiyaç duyar
• Tescilli çerçeveler üzerine inşa ediyorsunuz — önceden var olan kodun özelleştirilmiş teslimatlarına dahil edilmesi, net bir anlaşma olmadan karmaşık sahiplik soruları yaratır
• Sınır ötesi çalışıyorsunuz — geliştirici ve müşteri farklı ülkelerde olduğunda, yöneten hukuk ve yetki alanı adlandırılmalıdır

Tam bir SDA olmadan idare edebileceğiniz tek durum: ilgili tüm koşulları zaten kapsayan kapsamlı bir ana hizmet sözleşmesi tarafından yönetilen çok kısa, düşük değerli bir iş. Ancak yine de çoğu avukat size evrak işlerini yapmanızı söyler.

Tek bir SDA şablonu her çalışmaya uymaz. Sözleşme yapısının projenin nasıl fiyatlandırıldığı ve kapsamlandırıldığıyla eşleşmesi gerekir — ve yanlış yapı seçmek, iyi sonuçlara karşı çalışan teşvikler yaratır.

Sabit fiyat sözleşmeleri

Sabit fiyatlı bir SDA, proje gereksinimlerinin geliştirme başlamadan önce kararlı ve iyi anlaşıldığı durumlarda işe yarar. Geliştirici, belirlenmiş bir kapsamı kabul edilen toplam bir ücret karşılığında teslim etmeyi taahhüt eder. Bütçe kesinliği, müşteriler için temel çekiciliktir. Risk: gereksinimler yetersiz belirtilmişse, geliştirici ya aşımı üstlenir ya da anlaşmazlıklar başlar.

Zaman ve malzeme sözleşmeleri

T&M sözleşmeleri, keşif projeleri, erken aşama ürünleri veya tam kapsamın önceden tanımlanamayacağı her durum için mantıklıdır. Müşteri, kabul edilen ücretler üzerinden çalışılan gerçek saatler için ödeme yapar. Esneklik elde edersiniz; karşılığı maliyet belirsizliğidir. Bütçe limitleri ve aylık tavanlar bu riski yönetmeye yardımcı olur.

Özel ekip anlaşmaları

Tutarlı bir uzaktan mühendislik ekibine ihtiyaç duyan şirketler için — tek seferlik proje teslimatından ziyade — özel ekip anlaşması devam eden bir ilişkinin koşullarını belirler. IT şirketleri için sözleşme yönetimi genellikle dış kaynak ortaklarıyla çalışırken bu modeli kullanır.

MSA + SOW yapısı

Daha büyük çalışmalar genellikle ana yasal çerçeveyi (MSA) proje özel koşullarından (SOW) ayırır. MSA, IP, gizlilik, sorumluluk ve anlaşmazlık çözümünü bir kez kapsar; her SOW, belirli bir proje için teslimatları, takvimi ve ödemeyi kapsar.

Tüm maddeler eşit ağırlıkta değildir. Bunlar, eksik veya belirsiz dilin gerçek dünya anlaşmazlıklarına neden olduğu maddelerdir.

1. İş kapsamı ve teslimatlar

Projeye dahil olmayan birinin teslim edilip edilmediğini değerlendirebileceği kadar detayla neyin yapılacağını tanımlayın. İşlevsel gereksinimler, teknik özellikler, desteklenen platformlar ve performans kıyaslamalarının hepsi buraya aittir. Kapsam dışı olanları açıkça belirtin.

Belirsiz kapsam, yazılım anlaşmazlıklarının en yaygın tek kaynağıdır. "Bir web sitesi yapın" bir kapsam değildir. "Ek A'da listelenen özelliklerle duyarlı bir React/Next.js uygulaması yapın, mobilde Lighthouse performans puanları 90+ geçsin" bir kapsamdır.

2. Ödeme koşulları ve kilometre taşı programı

Her ödemeyi listeleyin: tutar, tetikleyici olay ve ödeme yöntemi. Kilometre taşı tabanlı ödemeler kabul edilen teslimatlara bağlanmalıdır, yalnızca takvim tarihlerine değil. Para birimini, ödeme takvimini (Net-15 veya Net-30 standarttır) ve geç ödeme cezasını tanımlayın.

3. Fikri mülkiyet sahipliği

Bu, çoğu müşterinin çok hızlı okuduğu maddedir. Özel koda kim sahip olur? Geliştiricinin dahil ettiği önceden var olan koda kim sahip olur? Açık kaynak yazılım kapsanır mı? SDA'nın IP bölümü, teslimattan sonra yazılımı kimin kullanabileceğini, değiştirebileceğini, satabileceğini veya lisanslayabileceğini belirler. Bunu yanlış yaparsanız sonuçları pahalıdır — aşağıdaki IP bölümündeki Cadence v. Avanti davasına bakın.

4. Gizlilik

SDA karşılıklı gizlilik yükümlülüklerini içermelidir. Geliştirici müşteri verilerini veya tescilli iş mantığını açıklayamaz; müşteri geliştiricinin tescilli süreçlerini veya araçlarını açıklayamaz. Daha sağlam NDA koşulları için bağımsız bir anlaşmada, yazılım şirketleri için müteahhit NDA rehberi bununla birlikte okunmaya değer.

5. Kabul testi

Müşterinin her teslimatı nasıl inceleyip kabul ettiğini tanımlayın. İnceleme penceresi (5-10 iş günü yaygındır), geri bildirim formatı, geçme kriterleri ve müşteri inceleme penceresi içinde yanıt vermezse ne olacağı (varsayılan kabul).

6. Garantiler

Geliştirici, yazılımın belirtildiği gibi çalışacağını, kodun özgün olduğunu (veya uygun şekilde lisanslandığını) ve teslimatın üçüncü taraf IP haklarını ihlal etmeyeceğini garanti etmelidir. Lansmandan sonra keşfedilen hatalara karşı müşteriyi koruyan bir garanti süresi — tipik olarak 30-90 gün.

7. Fesih koşulları

Her iki taraf da makul bir bildirimle çıkış yapabilmelidir. Bildirim süresini (30 gün standarttır), devam eden çalışmalara ne olacağını ve erken fesih durumunda son ödemenin nasıl hesaplanacağını tanımlayın. Sebep fesih maddesi (ağır ihlal, iflas veya ödeme yapılmamasını kapsayan) uygunluk fesihinden ayrı olmalıdır.

8. Yöneten hukuk ve yetki alanı

Sözleşmeyi yöneten ülkeyi ve eyaleti/bölgeyi belirtin. Geliştirici ve müşteri farklı ülkelerde olduğunda, bu madde bir anlaşmazlığı hangi mahkemelerin ele alacağına karar verir. Resmi hissettiği için dışarıda bırakmayın — sınır ötesi bir çalışmada en pratik olarak önemli maddelerden biridir.

Bu şablonu anlaşmanızın temeli olarak kullanın. Tüm parantez içindeki alanları kendi koşullarınızla değiştirin. Karmaşık projeler için nihai sürümü — özellikle IP ve garanti bölümlerini — bir yazılım avukatına inceletin.

Birden fazla geliştirme ortağıyla sözleşme yöneten IT şirketleri için tüm SDA'larınızı tek bir belge yönetim sisteminde — sürüm geçmişi ve kurcalamaya karşı korumalı imzalarla — merkezileştirmek, Word belgelerini ileri geri e-postalamaktan doğan kaosu ortadan kaldırır.

Yukarıdaki şablonda doldurulması gereken ondan fazla alan vardır. İşte her birine, daha sonra anlaşmazlığa yol açacak boşluklar bırakmadan nasıl yaklaşacağınız.

Adım 1: Sözleşmeye dokunmadan önce kapsamı tanımlayın

Yazılımın gerçekte ne yapması gerektiğini belgeleyene kadar şablonu açmayın. İşlevsel gereksinimler, teknik kısıtlamalar, desteklenen platformlar, entegrasyon bağımlılıkları — hepsi. SDA'nın kapsam bölümü, arkasındaki spesifikasyon belgesi kadar iyidir.

Karmaşık projeler için, tam spesifikasyonu Ek A olarak ekleyin ve kapsam maddesinden buna atıfta bulunun. Bu, ana sözleşmenin okunabilir kalmasını sağlarken tam teknik detayın yasal olarak bağlı olduğundan emin olur.

Adım 2: Kilometre taşı programını oluşturun

Teslimat tarihinden geriye doğru çalışın. Projeyi aşamalara bölün — keşif, tasarım, geliştirme, test, dağıtım — ve her birine bir dolar tutarı ve son tarih atayın. Aşama ödemeleri, her aşamada teslim edilen değere kabaca eşleşmelidir.

Adil uyarı: bu, özellikle ilk çalışmalarda çoğu tarafın beklediğinden daha uzun sürer. Kilometre taşları ve ödemeleri doğru yapmak için her iki tarafın da hazır bulunduğu 1-2 saat ayırın.

Adım 3: IP sahipliğini açıkça ele alın

1. 3.
   Bölümü dikkatlice okuyun ve tüm boşlukları doldurun. Geliştirici bu projeden önce geliştirdiği tescilli çerçeveler veya araçlar kullanıyorsa, önceden var olan çalışma ayrımında listeleyin. Açık kaynak kütüphaneler kullanıyorsanız, lisansları adlandırın.

Özel çalışma devri (Bölüm 3.1) tipik olarak müşteriler için en önemli maddedir: teslim edilen kodun sahipliğini geliştiriciden size devreden şey budur. Belirsiz bırakmayın.

Adım 4: İnceleme penceresini ve kriterleri belirleyin

Doldurmadan önce inceleme penceresine karar verin. On iş günü yaygındır. İki hafta, meşgul müşterilere teslimatı gerçekten test etmek için yeterli zaman verir; daha kısa süreler, inceleyenler seyahatte veya meşgul olduğunda anlaşmazlık yaratma eğilimindedir.

1. 5.
   Bölüm için kabul kriterleri Ek A'ya aittir. Spesifik, test edilebilir kriterler yazın: "Mobil uygulama, 4G bağlantısında kontrol panelini 3 saniyeden kısa sürede yükler" ifadesi, "uygulama hızlı olmalı" ifadesinden üstündür.

Adım 5: Yöneten hukuku bilinçli seçin

Yerel projeler için geliştiricinin ana eyaletini/ülkesini kullanın (yerel mahkemelere daha aşinadırlar). Sınır ötesi projeler için, her iki taraf da tarafsız bir yargı bölgesini tercih edebilir. Delaware hukuku, ABD merkezli teknoloji sözleşmeleri için yaygındır; İngiliz hukuku uluslararası teknoloji anlaşmalarında sık kullanılır. Ne seçerseniz seçin, her iki taraf da açıkça kabul etmelidir — bu alanı boş bırakmayın.

Adım 6: Uyumlu bir e-imza ile imzalayın

Bir PDF üzerindeki el yazısı imzanın taranmış görüntüsü çoğu yargı bölgesinde yasal olarak zayıftır. Belge hash değeri ve zaman damgalı tamamlama sertifikası üreten elektronik imzalar, reddetmek çok daha zordur. ABD'de ESIGN Act ve UETA, Avrupa Birliği'nde ise eIDAS kapsamında, elektronik imzalar ticari anlaşmalar için tam yasal güce sahiptir. İmzalama platformu, her imzayı belgenin kriptografik hash değerine bağlamalıdır — böylece imzadan sonraki herhangi bir değişiklik hemen tespit edilebilir.

Çoğu şablon temelleri kapsar. Bunlar, ucuz veya hızlı hazırlanmış sözleşmelerden çıkarılan ve bir şeyler ters gittiğinde en çok önem kazanan maddelerdir.

Geçme/kalma kriterleriyle kabul testi

Yukarıdaki şablondaki 5. Bölüm, müşterinin teslimatları *ne zaman* ve *nasıl* incelediğini tanımlar. Çoğu anlaşmanın atladığı şey: geçme için gerçek kriterler. Ölçülebilir geçme/kalma kıyaslamaları olmadan, kabul bir müzakere haline gelir. Müşteri her zaman yazılımın "yeterince iyi" olmadığını savunabilir. Geliştirme başlamadan önce Ek A'ya nesnel kriterler yazın.

Kaynak kod emanet

İşiniz özel yazılıma bağlıysa ve geliştirici iflas ederse, kaynak koduna erişmeniz gerekir. Bir kaynak kod emanet maddesi, geliştiricinin kaynak kodunu tarafsız bir emanet acentasına yatırmasını gerektirir. Geliştirici faaliyetlerini durdurursa veya anlaşmayı maddi olarak ihlal ederse, emanet kodu müşteriye verir. Çoğu müşteri bunu istemeyi asla düşünmez — ihtiyaç duyana kadar.

Teslimat sonrası sorumluluk dönemi

1. 7.
   Bölüm toplam sorumluluğu sınırlar, ancak çoğu şablon zamansal pencereyi ele almaz. Sorumluluk ne zaman biter? Teslimattan 18 ay sonra bir hata veri kaybına neden olursa, geliştirici hâlâ sorumlu mudur? Garanti süresini ve teslimat sonrası sorumluluk penceresini açıkça tanımlayın. Garanti süresinden sonra, geliştiricinin tek yükümlülüğü tipik olarak kendi neden olduğu hataları gidermektir — müşteri değişiklikleriyle oluşturulan hatalar değil.

Değişiklik kontrol süreci

1. 9.
   Bölüm kapsam değişiklikleri için imzalı bir Değişiklik Emri gerektirir. Çoğu anlaşmanın kaçırdığı şey: Değişiklik Emirlerini imzalama yetkisinin kimin olduğunu tanımlamak. Müşteri tarafında bir proje yöneticisi sözlü olarak yeni bir özellik talep ederse ve geliştirici bunu inşa ederse, geliştiriciye ödeme yapılır mı? Yalnızca Değişiklik Emri süreci takip edilmişse. Değişiklikleri onaylama yetkisine sahip olan belirli rolleri (başlıkları değişen kişiler değil) adlandırın.

Açık kaynak lisans uyumu

Linux Foundation raporlarına göre, ticari yazılımın %92'si açık kaynak bileşenler içerir. Her bileşenin lisansı, yazılımın nasıl kullanılabileceği, değiştirilebileceği ve dağıtılabileceği konusunda koşullar getirir. Örneğin GPL lisanslı bir kütüphane, tescilli kodunuzu açık kaynak yapmak zorunda bırakan copyleft yükümlülüklerini tetikleyebilir. SDA, geliştiricinin tüm açık kaynak bileşenleri açıklamasını ve bunların müşterinin amaçlanan kullanımıyla uyumluluğunu onaylamasını gerektirmelidir.

IP sahipliği, çoğu müşterinin gözden geçirdiği madde — ve yanlış yapmanın sonuçlarının en büyük olduğu madde.

Cadence v. Avanti davası: 265 milyon dolarlık bir ders

2002'de bir California mahkemesi, Avanti Corporation'ın çalınan Cadence kaynak kodunu rakip bir üründe kullandığını tespit etti. Hasar tazminatı 265 milyon dolara ulaştı. Bu dava, yazılım IP davalık süreçlerinde sıkça atıfta bulunulur çünkü kaynak kodu sahipliği tartışmalı olduğunda veya daha da kötüsü, bir ürüne asla dahil edilmemesi gereken kod oraya girdiğinde neler olduğunu gösterir. İyi hazırlanmış bir IP maddesi, yalnızca nihai teslimatın kime ait olduğunu tanımlamaz — geliştiricinin herhangi bir üçüncü taraf IP'sinin usulsüz dahil edilmediğini garanti etmesini de gerektirir.

Dört IP modeli

Önceden var olan çalışma vs. özel çalışma

Çoğu geliştirici, projeniz başlamadan önce geliştirdiği araçları, çerçeveleri ve kütüphaneleri getirir. Bunlar "önceden var olan çalışmalar" veya "arka plan IP'si" dir. SDA, dahil edilecek önceden var olan çalışmanın ne olduğunu açıkça belirlemeli ve müşteriye bunu teslim edilen yazılımın bir parçası olarak kullanması için lisans vermelidir — bu temel araçların sahipliğini devretmeden.

Bireysel geliştirici sözleşmelerinde IP devrinin nasıl çalıştığına daha derin bir bakış için, geliştiriciler için IP devri anlaşması rehberi kod sahipliğinin devri ve lisanslanması mekanizmalarını kapsar.

İşe göre çalışma doktrini

ABD'de, bir çalışanın iş kapsamında yazdığı kod otomatik olarak işe göre çalışma kapsamındadır ve işverene aittir. Bağımsız bir yüklenici tarafından yazılan kod *otomatik olarak* işe göre çalışma kapsamında değildir — yüklenici, anlaşma açıkça devretmedikçe telif hakkını saklı tutar. Bu ayrım, ödeme yaptıkları için koda sahip olduklarını varsayan müşterileri şaşırtır. Devir maddesi olmadan sahip değillerdir.

Bu üç belge sürekli karıştırılır. Her birinin farklı bir rolü vardır ve yanlış olanı kullanmak — veya onları birleştirmek — hesap verebilirlik boşlukları yaratır.

Tek seferlik projeler için, bu rehberdeki şablon gibi bağımsız bir SDA her şeyi kapsar. Zamanla birden fazla proje yürüttüğünüz bir geliştirme ortağıyla devam eden çalışmalar için MSA + SOW yapısı daha verimlidir. MSA, yasal çerçeveyi bir kez müzakere eder; her proje yeni bir SOW ekler. İş Tanımı Beyanlarına ilişkin kapsamlı rehberimiz SOW yapısını detaylı olarak kapsar.

İmzalı bir SDA almak eskiden yazdırmak, taramak, e-posta göndermek ve diğer tarafın sürümünün sizinkiyle eşleştiğini ummak anlamına gelirdi. Artık bunu yapmak için iyi bir neden yok.

Elektronik imzayı yasal olarak geçerli kılan nedir

ABD'de ESIGN Act ve eIDAS (AB) kapsamında, bir elektronik imza ticari anlaşmalar için şu koşullarda yasal olarak geçerlidir:

• İmzalama niyeti olan biri tarafından uygulanması
• İmzalanan belirli belgeyle ilişkilendirilmesi
• İmzalayanın kimliğine atfedilebilir olması
• Kaydın daha sonra erişilebilir bir formda saklanması

Kriptografik imzalar daha ileri gider: her imza, belgenin hash değerine matematiksel olarak bağlıdır. İmzaladıktan sonra tek bir karakter değiştirin ve hash değeri değişir, kurcalamayı hemen tespit edilebilir hale getirir. Bu inkar edilemezlik, anlaşmayı mahkemede savunulabilir kılar — hiçbir taraf daha sonra belgenin değiştirildiğini iddia edemez.

İmzalama iş akışı nasıl çalışır

IT şirketleri için belge yönetimi tipik olarak aynı anda birden fazla SDA, SOW ve NDA yürütür. Özel olarak tasarlanmış bir iş akışı, e-posta tabanlı imzalamanın getirdiği sürüm kontrol kabusunu önler:

1. 1.
   Nihai SDA'yı bir sözleşme yönetimi platformuna yükleyin
2. 2.
   Her imzalayanın e-posta adresini ve imzalama sırasını ekleyin
3. 3.
   Her taraf güvenli bir imzalama bağlantısı alır — imzalamak için hesap gerekmez
4. 4.
   İmzalar uygulanır; platform zaman damgaları, IP adresleri ve belge hash değeri içeren bir tamamlama sertifikası üretir
5. 5.
   Her iki taraf da otomatik olarak tam olarak yürürlüğe girmiş belgeyi alır
6. 6.
   Denetim izi, gelecekteki referans veya anlaşmazlık çözümü için erişilebilir şekilde değiştirilemez olarak saklanır

İmzalama ile bağlı kilometre taşı ödemeleri

Modern bir sözleşme platformundaki en kullanışlı özellik imzanın kendisi değil — imzanın sonrasında ne olduğuna bağlamasıdır. Bir geliştirici bir kilometre taşı teslim ettiğinde ve müşteri kabul formunu imzaladığında, ödeme tetikleyicisi otomatik olarak devreye girer. Manuel fatura takibi yok, "faturayı ayrı göndereceğini sanıyordum" kafa karışıklığı yok. Sözleşmeye bağlı ödemeleri yöneten ekipler için bu, kabul ile faturalama arasındaki boşluğu ortadan kaldırır.

Sözleşme yönetimi planlarının tam fiyatlandırma dökümü için Chaindoc'un fiyatlandırma sayfası her kademede nelerin dahil olduğunu kapsar.