Un contract dezvoltare software valabil pentru o firmă din România trebuie să conțină obligatoriu opt elemente: obiectul contractului cu anexe tehnice detaliate, cesiunea expresă a drepturilor de proprietate intelectuală, criterii clare de acceptanță (acceptance testing), jaloane de livrare legate de plăți, un acord de procesare a datelor conform Art. 28 GDPR, clauze de confidențialitate, garanție și mentenanță post-livrare și limitarea răspunderii. Fără o clauză expresă de cesiune, codul rămâne, din punct de vedere legal, proprietatea dezvoltatorului, chiar dacă firma a plătit integral proiectul.
Înainte de a semna, cereți furnizorului specificații tehnice detaliate și un calendar de livrări. Un contract fără anexe de specificații deschide ușa unor dispute costisitoare la recepție.
Elementele pe care nu trebuie să le omiteți dintr-un contract dezvoltare software:
- Obiectul contractului și anexele cu specificații tehnice
- Cesiunea explicită a drepturilor de proprietate intelectuală
- Criterii obiective de acceptanță și procedura de recepție
- Jaloane (milestones) și termene de plată corelate
- Acord de procesare a datelor (DPA) conform GDPR
- Clauze de confidențialitate și NDA
- Garanție și mentenanță post-livrare
- Limitare a răspunderii și penalități pentru întârzieri
Concluzii principale
Un contract dezvoltare software funcționează doar dacă leagă explicit cesiunea drepturilor, criteriile de acceptanță și plățile de livrabile verificate, nu de promisiuni generale.
| Punct | Detalii |
|---|---|
| Cesiunea drepturilor | Includeți o clauză expresă de transfer al drepturilor patrimoniale, altfel codul rămâne al dezvoltatorului. |
| Anexe tehnice obligatorii | Specificațiile detaliate în anexă previn disputele de interpretare la recepție. |
| Plată pe jaloane | Legați fiecare plată de un livrabil verificat și aprobat în scris, nu de termene calendaristice. |
| DPA pentru date personale | Includeți un acord de procesare a datelor conform Art. 28 GDPR ori de câte ori aplicația prelucrează date. |
| Revizuire cu Axiobyte | Axiobyte oferă revizuire de contract, definire de specificații și implementare cu probe documentate la fiecare jalon. |
This article is general information, not a substitute for advice from a qualified lawyer. Consult a qualified legal professional about your own circumstances before acting on anything here.
Cuprins
- Clauzele esențiale: ce să scrieți concret pentru fiecare secțiune
- Proprietatea intelectuală și cesiunea drepturilor: formulări practice și riscuri în România
- Testare, acceptanță și recepție: proceduri clare pentru deblocarea plăților
- Termene, plată și costuri: cum negociezi structura financiară și protecțiile financiare
- Garanție și mentenanță post-livrare: ce acoperire să ceri și ce costuri să negociezi
- Confidențialitate și GDPR: când e necesar un DPA și ce trebuie să conțină
- Răspunderea părților și rezilierea: cum limitați riscurile și ce prevederi cere un client
- Gestionarea modificărilor: procedură de change request și prevenirea „scope creep“
- Perspective Axiobyte — cum implementăm practic clauzele și ce probe păstrăm
- Serviciile Axiobyte: revizuire contract, definire specificații și management proiect
- Surse
Clauzele esențiale: ce să scrieți concret pentru fiecare secțiune
Un contract profesionist de dezvoltare software nu se limitează la a descrie codul livrat. El structurează întregul proces de lucru, pe faze, astfel încât fiecare plată să corespundă unui livrabil verificabil.
Obiectul contractului trebuie să facă trimitere explicită la o anexă de specificații tehnice, nu doar la o descriere generală de tipul „aplicație de gestiune“. Anexa ar trebui să includă arhitectura propusă, tehnologiile folosite, integrările necesare și criteriile de performanță așteptate. Fără acest nivel de detaliu, orice diferență de interpretare între client și furnizor devine un motiv de conflict la recepție.
Iată structura pe care o recomandăm pentru secțiunea de jaloane și plăți:
- Jalon de analiză și proiectare — livrarea documentației funcționale și a machetelor, cu plată conform acordului părților.
- Jalon de dezvoltare — versiuni intermediare demonstrabile, cu plăți eșalonate pe module funcționale.
- Jalon de testare și corectare — remedierea defectelor identificate, fără plată suplimentară dacă defectele țin de neconformitate cu specificațiile.
- Jalon de recepție finală — plata restului de sumă, condiționată de semnarea unui proces verbal de recepție.
Modelul de plată pe etape protejează clientul mai bine decât plata integrală în avans, dar necesită o descriere clară a fiecărui livrabil. Plata în regim „timp și materiale“ oferă flexibilitate pentru proiecte cu cerințe schimbătoare, însă expune clientul la depășiri de buget dacă nu există un plafon lunar stabilit contractual.
Sfat profesional: Cereți întotdeauna ca fiecare jalon să aibă un document de aprobare semnat, nu doar un e-mail de confirmare. În caz de litigiu, procesul verbal de recepție este proba care contează.
Proprietatea intelectuală și cesiunea drepturilor: formulări practice și riscuri în România
Cea mai frecventă greșeală în contractele de dezvoltare software din România este omiterea unei clauze exprese de cesiune a drepturilor patrimoniale de autor. Fără ea, drepturile asupra codului rămân dezvoltatorului potrivit Legii nr. 8/1996, indiferent de suma plătită.
Clauza de cesiune trebuie să prevadă explicit că drepturile patrimoniale (cod sursă, documentație, machete, baze de date) trec la client în momentul plății integrale sau al recepției finale, în funcție de ce ați negociat. O formulare eficientă include:
- Momentul exact al transferului (plată integrală sau semnare proces verbal de recepție)
- Domeniul de acoperire: cod sursă, documentație tehnică, machete UI/UX, configurări server
- O anexă separată cu lista componentelor open-source folosite și licențele aferente
Componentele open-source merită atenție specială. O licență de tip copyleft, precum GPL, poate obliga furnizorul să publice părți din codul dezvoltat pentru client, ceea ce anulează practic exclusivitatea urmărită prin contract. Auditul acestor componente înainte de recepție elimină acest risc. Pentru protecție suplimentară, verificați și opțiunea de înregistrare a programului în Registrul național al programelor pentru calculator administrat de ORDA.
Testare, acceptanță și recepție: proceduri clare pentru deblocarea plăților
Procedura de acceptance testing decide, practic, când se face plata finală. Ea trebuie descrisă pas cu pas, nu lăsată la nivel de intenție.
- Testarea o efectuează clientul, într-o perioadă stabilită contractual, de obicei 5-15 zile lucrătoare de la livrare, cu sprijin tehnic din partea furnizorului.
- Criteriile de acceptanță trebuie să fie măsurabile: funcționalități conform specificațiilor din anexă, absența erorilor critice, respectarea timpilor de răspuns stabiliți.
- Procedura de remediere stabilește un termen fix, de regulă 5-10 zile, pentru corectarea defectelor semnalate, fără costuri suplimentare pentru client.
La livrare, furnizorul trebuie să predea build-ul funcțional, codul sursă complet, documentația tehnică și rapoartele de testare. O descriere tehnică suficient de detaliată, cu criterii de acceptanță incluse din start, este cea mai eficientă apărare împotriva disputelor de recepție.
Termene, plată și costuri: cum negociezi structura financiară și protecțiile financiare
Alegerea modelului de plată influențează direct riscul financiar al proiectului. Prețul fix oferă predictibilitate, dar funcționează doar când specificațiile sunt complete de la început. Modelul „timp și materiale“ se potrivește proiectelor cu cerințe evolutive, dar necesită plafoane lunare. Plata pe etape rămâne cea mai echilibrată variantă pentru majoritatea firmelor românești.
Elementele financiare pe care contractul trebuie să le acopere:
- Penalități pentru întârzieri, calculate procentual din valoarea jalonului afectat
- O reținere de garanție (5-10% din valoarea totală), eliberată după perioada de garanție tehnică
- Costuri suplimentare de anticipat: hosting, licențe software terțe și mentenanța ulterioară
Estimările practice arată intervale orientative de câteva mii de lei pentru etapele de analiză (discovery), design și testare (QA) ale unui proiect mediu, sume care se adaugă la costul propriu-zis de dezvoltare, dacă nu sunt bugetate din start.
Garanție și mentenanță post-livrare: ce acoperire să ceri și ce costuri să negociezi
Garanția tehnică standard acoperă de obicei 3-6 luni de la recepție și include remedierea gratuită a defectelor care nu au fost cauzate de modificări ulterioare făcute de client sau de terți.
Pentru mentenanța ulterioară perioadei de garanție, există trei modele frecvente, descrise în detaliu în serviciile de mentenanță oferite de partenerii noștri din domeniul marketing și servicii digitale:
- Abonament lunar cu un număr fix de ore incluse pentru intervenții
- Pachet de ore preplătite, folosite pe măsura nevoilor
- Tarif per intervenție, potrivit pentru firme cu volum redus de solicitări
Contractul trebuie să stabilească și timpi de răspuns diferențiați: intervenție rapidă pentru incidente critice (de obicei sub 4 ore) și termene mai relaxate pentru cereri minore. Fără această diferențiere, orice solicitare ajunge tratată la fel, indiferent de urgență.
Confidențialitate și GDPR: când e necesar un DPA și ce trebuie să conțină
Un acord de procesare a datelor (DPA), conform Art. 28 GDPR, devine obligatoriu de fiecare dată când furnizorul procesează date cu caracter personal în numele clientului, de exemplu date ale utilizatorilor unei aplicații.
DPA-ul trebuie să conțină:
- Lista subprocesatorilor implicați și măsurile tehnice de securitate aplicate
- Procedura de notificare a incidentelor de securitate, cu termen concret de raportare către client
- Modalitatea de portabilitate a datelor și termenul de ștergere completă la încetarea contractului
Sfat profesional: Cereți întotdeauna ca DPA-ul să specifice locul fizic de stocare a datelor. Un server găzduit în afara Uniunii Europene poate ridica probleme suplimentare de conformitate pentru compania dumneavoastră.
Răspunderea părților și rezilierea: cum limitați riscurile și ce prevederi cere un client
Limitarea răspunderii protejează ambele părți, dar trebuie formulată cu excepții clare: neglijența gravă, încălcările de confidențialitate și breșele de securitate a datelor nu ar trebui plafonate, chiar dacă restul răspunderii contractuale este limitat la valoarea contractului.
Clauzele de reziliere trebuie să prevadă:
- Plata proporțională a muncii deja efectuate și verificate până la momentul rezilierii
- Transferul obligatoriu al tuturor livrabilelor existente, indiferent de stadiul finalizării
- O clauză de forță majoră care suspendă termenele, nu anulează obligațiile
Pentru dispute transfrontaliere, cu furnizori sau clienți din alte state membre UE, platforma europeană de soluționare online a litigiilor oferă o alternativă la procedurile judiciare clasice, alături de mediere sau arbitraj stabilite direct în contract.
Gestionarea modificărilor: procedură de change request și prevenirea „scope creep“
Fără o procedură formală de change request, orice proiect de dezvoltare software riscă să depășească bugetul și termenele inițiale prin cereri adăugate „pe parcurs“.
- Documentul de change request descrie modificarea cerută, impactul estimat asupra termenelor și costul suplimentar.
- Aprobarea se face în scris, de ambele părți, înainte de implementare, de regulă printr-un act adițional la contract.
- Prevenirea derapajelor se face printr-un backlog de cereri, revizuit periodic, și printr-o limită clară a numărului de modificări incluse gratuit per jalon.
Perspective Axiobyte — cum implementăm practic clauzele și ce probe păstrăm
La Axiobyte, tratăm contractul ca document de lucru, nu ca formalitate semnată o dată și uitată. Păstrăm commit-uri Git, rapoarte de sprint și changelog-uri pentru fiecare proiect, exact probele care demonstrează conformitatea la recepție și susțin plata pe jaloane fără ambiguități.
Recomandarea noastră, din experiența directă cu zeci de proiecte: negociați clauza de cesiune și criteriile de acceptanță înainte de a discuta prețul. Un preț bun pe un contract slab redactat costă mai mult pe termen lung decât diferența de ofertă dintre furnizori.
— Axiobyte
Serviciile Axiobyte: revizuire contract, definire specificații și management proiect
Axiobyte este alternativa la un contract redactat rapid, fără anexe tehnice și fără proceduri clare de recepție. Lucrăm cu firme din România la revizuirea contractelor de dezvoltare software, definirea specificațiilor tehnice și implementarea propriu-zisă a proiectului, cu documente de aprobare la fiecare jalon.
Procesul începe cu o discuție inițială despre proiectul dumneavoastră, urmată de o evaluare tehnică și o ofertă personalizată, cu jaloane și criterii de acceptanță stabilite de la început, nu negociate ulterior sub presiune. Puteți vedea exemple concrete de livrabile și moduri de lucru în portofoliul Axiobyte, inclusiv proiecte unde diferența dintre o soluție construită pe cod propriu și una bazată pe șabloane generice a contat direct pentru client, așa cum explicăm și în comparația dintre dezvoltarea web personalizată și page builderele. Dacă aveți deja un proiect în discuție și vreți o a doua opinie asupra contractului propus de un alt furnizor, scrieți-ne pe pagina principală Axiobyte pentru o evaluare inițială.
Surse
- Contracte Software și SaaS: Ce clauze sunt esențiale și ce greșeli să eviți
- Contract Dezvoltare Software - Model Redactat de Avocați
- Model de contract de dezvoltare software la comandă - Geek Blog
- Costurile Ascunse ale Dezvoltării Software: Ghidul Complet 2026 - Brig