northdan.

Întrebări și răspunsuri

Ce conține un contract de dezvoltare software

Contractul bun se recunoaște după ce se întâmplă când lucrurile merg prost.

Un contract de dezvoltare software conține șapte clauze obligatorii: obiectul cu specificațiile anexate (caietul de sarcini devine parte integrantă din contract, nu un e-mail rătăcit), etapele cu livrabile verificabile, plățile legate de livrări acceptate — nu de date din calendar —, cesiunea drepturilor patrimoniale asupra codului către tine, garanția post-lansare pentru corectarea bugurilor (uzual între 3 și 12 luni), confidențialitatea și condițiile de reziliere cu obligația de predare. Lipsa oricăreia dintre ele nu e un detaliu juridic, ci o factură viitoare: fără specificații anexate, orice funcționalitate „subînțeleasă” devine act adițional plătit separat; fără plăți pe livrabile, finanțezi promisiuni; fără cesiune, ai plătit un produs care legal nu e al tău. Regula practică pentru citirea oricărui draft primit: sari peste paragrafele festive de la început și citește întâi ce se întâmplă în scenariile negre — întârziere, neplată, dispută pe calitate, reziliere. Un contract echilibrat descrie ambele sensuri ale fiecărui risc; unul scris exclusiv de avocatul furnizorului descrie doar obligațiile tale.

Hai să vorbim despre proiectul tău

Scrie-ne pe WhatsApp sau trimite un email — vorbești direct cu un programator.

office@northdan.com · +40 752 070 247

Pe scurt

Specificațiile, anexă la contract

Ce trebuie livrat se descrie într-o anexă cu valoare contractuală. Formularea „aplicație web conform discuțiilor” garantează un singur lucru: dispute la recepție.

Plăți legate de livrări, nu de calendar

Fiecare tranșă se achită la acceptarea unui livrabil testabil. Avansul uzual de 20–30% e rezonabil; 50% înainte de orice linie de cod mută tot riscul la tine.

Cesiune de drepturi, nu licență

Codul plătit integral trebuie cedat cu drepturi patrimoniale depline. „Licență de utilizare” înseamnă că furnizorul rămâne proprietar, iar tu chiriaș pe propria aplicație.

Garanție post-lansare scrisă

Bugurile descoperite după lansare se remediază gratuit în perioada de garanție, tipic 3–12 luni. Contractul definește și timpul de reacție, nu doar existența garanției.

Clauzele, una câte una

Obiectul și specificațiile: anexa tehnică descrie funcționalitățile, platformele vizate și criteriile de acceptanță — cum se decide obiectiv că un livrabil e „gata”. Etapele: proiectul se împarte în livrări testabile de câteva săptămâni, fiecare cu conținut definit. Plățile: procent la fiecare acceptare; reține și mecanismul invers, dreptul tău de a refuza motivat recepția, cu termen de remediere. Proprietatea intelectuală: cesiunea drepturilor patrimoniale asupra codului scris pentru tine, cu mențiunea onestă că librăriile open-source și uneltele generale ale furnizorului rămân sub licențele lor.

Garanția: perioada, ce acoperă (defecte față de specificații) și ce nu (cerințe noi, modificări făcute de terți). Confidențialitatea: în ambele sensuri — datele afacerii tale, respectiv know-how-ul furnizorului. Rezilierea: în ce condiții poate ieși fiecare parte, ce se plătește pentru munca deja acceptată și, esențial, obligația de predare a codului, acceselor și documentației în termen definit, indiferent de motivul despărțirii. Penalitățile: procent pe zi de întârziere pentru furnizor, simetric cu penalitățile tale de neplată.

Capcanele care apar frecvent în drafturi

Capcana 1: „licență de utilizare neexclusivă” strecurată la capitolul de proprietate intelectuală — sună tehnic, dar înseamnă că aplicația plătită de tine poate fi revândută concurenței, iar tu nu poți schimba furnizorul fără să pierzi tot. Capcana 2: mentenanța obligatorie pe 2–3 ani legată de contractul de dezvoltare, uneori cu tarife nedefinite „conform grilei furnizorului” — adică un cec în alb. Capcana 3: penalități detaliate pentru neplata ta, zero consecințe pentru întârzierile lor.

Mai subtile: clauza care permite furnizorului să folosească subcontractori nenumiți fără acordul tău, recepția tacită agresivă (livrabilul se consideră acceptat automat în 3 zile dacă nu răspunzi — rezonabil e 10–15 zile lucrătoare cu notificare), și „specificațiile pot fi ajustate de comun acord” fără procedură scrisă de schimbare. Niciuna nu cere avocat ca să fie observată; cere doar să citești draftul integral înainte de avans, cu creionul pe scenariile în care colaborarea nu merge bine.

Întrebări frecvente

Îmi trebuie avocat pentru un contract de dezvoltare software?

La proiecte de peste 10.000–15.000 €, o revizuire juridică de câteva sute de euro e o asigurare ieftină. Sub acest prag, poți verifica singur cele șapte clauze esențiale din acest ghid — majoritatea problemelor din practică vin din clauze lipsă evidente, nu din subtilități pe care doar un jurist le-ar prinde.

Furnizorul zice că modelul lui de contract „nu se negociază”. Ce fac?

Contractele-tip sunt normale; refuzul oricărei modificări, nu. Cere punctual trei lucruri: cesiunea codului, plăți pe livrabile și predarea la reziliere. Un furnizor care nu acceptă nici măcar discuția pe acestea îți arată exact câtă flexibilitate vei primi și după semnare, când vei avea mult mai puțină putere de negociere.

Ce se întâmplă dacă vreau funcționalități noi la mijlocul proiectului?

Contractul bun prevede o procedură de schimbare: ceri scris, furnizorul estimează impactul pe cost și termen, semnați un act adițional, abia apoi se lucrează. Fără această procedură, cererile din mers se transformă fie în facturi-surpriză, fie în termene depășite pentru care nimeni nu mai răspunde.

Garanția de 12 luni acoperă orice problemă apare?

Nu, și e corect așa. Garanția acoperă defectele față de specificațiile convenite: funcționalități care nu merg cum s-a promis. Nu acoperă cerințe noi, incompatibilități apărute din actualizări externe ulterioare sau stricăciuni făcute de alt furnizor în cod. Exact de aceea specificațiile clare din anexă sunt fundația întregii garanții.