Contratto software: cosa deve contenere e cosa controllare

Stai per firmare un contratto con una software house. Il documento è di venti pagine, scritto in legalese, e il tuo referente ti rassicura: "È il nostro contratto standard, lo firmiamo con tutti i clienti." A questo punto hai due opzioni: fidarti e firmare, oppure sapere esattamente cosa stai sottoscrivendo. Il contratto software è il documento che protegge il tuo investimento — e ignorarne le clausole chiave può costarti caro, anche con un partner onesto.

In questa guida trovi tutte le clausole che un contratto di sviluppo software deve contenere, i red flag da riconoscere prima di firmare e una checklist operativa per non farti trovare impreparato.

Cos'è un contratto software e perché è diverso dagli altri

Un contratto software — detto anche contratto di sviluppo software o accordo di fornitura IT — è l'accordo formale tra te (il cliente) e la software house (il fornitore) che regola la realizzazione di un prodotto digitale: un'app, una piattaforma web, un gestionale su misura o qualsiasi altro software personalizzato.

A differenza di un contratto per la fornitura di beni fisici, il software ha caratteristiche particolari che lo rendono più complesso da tutelare:

• È immateriale: non puoi "restituirlo" se non funziona come ti aspettavi
• È difficile da valutare per un non tecnico: come fai a sapere se la consegna è conforme?
• Evolve nel tempo: la versione 1.0 non sarà mai l'ultima
• La proprietà intellettuale del codice è spesso ambigua se non definita esplicitamente

Per questo il contratto software deve essere molto più preciso di un qualsiasi accordo commerciale standard.

Le clausole che non possono mancare in un contratto software

1. Proprietà intellettuale del codice

È la clausola più importante e quella su cui si litiga di più. Devi avere chiaro chi è il proprietario del codice sorgente a sviluppo completato. Le opzioni sono due:

• Il codice è tuo: alla consegna, diventi proprietario del codice sorgente e puoi farne ciò che vuoi — modificarlo, affidarlo ad altri, venderlo
• Il codice rimane della software house: ti viene concessa una licenza d'uso, ma non puoi toccare l'interno. Questo è il modello che crea vendor lock-in

Se il contratto non specifica nulla, in Italia la legge tende a lasciare i diritti al creatore dell'opera, non al committente. Assicurati che la clausola di proprietà intellettuale sia esplicita e a tuo favore.

2. Specifiche funzionali e deliverable

Il contratto deve fare riferimento a un documento tecnico — le specifiche funzionali, il capitolato o un allegato con le funzionalità da sviluppare. Senza questo riferimento, non hai un metro di valutazione per sapere se la consegna è conforme.

Controlla che il contratto indichi: cosa viene consegnato, in quale formato, con quale documentazione allegata (codice sorgente, manuale tecnico, credenziali di accesso agli ambienti).

3. Milestone, tempi e penali

Un contratto senza date di consegna non è un contratto — è una promessa. Il contratto di sviluppo software deve includere un piano di milestone con date specifiche e, idealmente, penali in caso di ritardi imputabili al fornitore.

Attenzione: le penali devono essere bilaterali. Se sei tu a ritardare l'approvazione di una milestone o a cambiare i requisiti in corsa, il fornitore ha diritto a richiedere una proroga. Questo è normale — l'importante è che il meccanismo sia scritto.

4. Prezzo, pagamenti e gestione delle varianti

Specifica chiaramente il prezzo totale (o le tariffe orarie, in caso di contratto T&M), il piano di pagamento e le condizioni per eventuali extra. Le voci da chiarire sono:

• Acconto iniziale e percentuale
• Pagamenti legati alle milestone
• Saldo finale: quando scatta e a quale condizione
• Come vengono gestite le richieste di modifica fuori scope (change request): a tariffa oraria? Con un preventivo separato?

Se il contratto prevede un prezzo fisso ma non definisce esattamente lo scope, rischi di trovarti in un negoziato continuo su cosa è "incluso" e cosa no.

5. Garanzie e bug fix post-consegna

Qualsiasi software contiene bug. La domanda non è "se" ne troverai, ma "chi li corregge e in quanto tempo". Il contratto deve definire:

• Durata del periodo di garanzia (di solito 30-90 giorni dalla consegna)
• Cosa si intende per "bug" (difetto funzionale) vs "modifica" (nuova richiesta)
• Tempi massimi di risposta per i bug critici

Se il tuo fornitore non vuole inserire una clausola di garanzia, è un red flag serio.

6. NDA e riservatezza

Se condividi con la software house informazioni sui tuoi processi, sul tuo business model o sui tuoi dati, hai bisogno di una clausola NDA (Non-Disclosure Agreement) o di un accordo di riservatezza separato. Verifica che copra:

• Informazioni riservate condivise durante il progetto
• Dati degli utenti finali (importantissimo in ottica GDPR)
• Codice sorgente e architettura tecnica

Se stai valutando il tuo progetto e cerchi un partner tecnologico affidabile, possiamo aiutarti: contattaci dalla sidebar per una consulenza gratuita.

7. SLA e supporto post-lancio

Se il contratto include anche la gestione e manutenzione del software dopo il lancio, deve esserci uno SLA (Service Level Agreement) che definisce: uptime garantito, tempi di risposta in caso di problemi, canali di supporto e orari di disponibilità.

Senza SLA, non hai nessuna leva per chiedere conto di un'interruzione del servizio o di un'assistenza lenta.

8. Clausola di exit e portabilità dei dati

Prima o poi potresti voler cambiare fornitore. Il contratto deve prevedere una clausola di exit che regoli: il trasferimento del codice sorgente, la migrazione dei dati, la documentazione da consegnare e i tempi di transizione. Senza questa clausola, sei in balia del fornitore.

Red flag: cosa non deve mai essere nel contratto

Alcune clausole, spesso nascoste nel corpo del contratto, possono trasformare un accordo apparentemente standard in una trappola. Ecco le più comuni:

• Proprietà intellettuale ambigua: frasi come "il software viene sviluppato sulla piattaforma proprietaria del fornitore" significano che non sarai mai il vero proprietario del codice
• Diritto unilaterale di modifica: alcune software house si riservano il diritto di modificare le condizioni contrattuali con un semplice avviso. Non accettarlo
• Rinnovo automatico senza preavviso: nei contratti di manutenzione o SaaS whitelabel, il rinnovo automatico a lungo termine ti lega le mani
• Esclusione totale di responsabilità: il fornitore può limitare la propria responsabilità, ma azzerarla del tutto — anche in caso di dolo o colpa grave — non è accettabile
• Foro esclusivo in altra città: se il foro competente per eventuali controversie è distante da te, diventa un disincentivo a far valere i tuoi diritti

Accordo software personalizzato vs contratto standard: cosa scegliere

Molte software house usano un contratto standard che hanno fatto redigere una volta e applicano a tutti i clienti. Non è necessariamente sbagliato — dipende da quanto è ben scritto e da quanto rispecchia le tue esigenze specifiche.

Per progetti piccoli e ben definiti (sito vetrina, landing page, integrazione API semplice), il contratto standard è spesso sufficiente, a patto che contenga le clausole essenziali descritte sopra.

Per progetti complessi — piattaforme SaaS, marketplace, app mobile con backend articolato — vale la pena farsi affiancare da un legale specializzato in contratti IT. Il costo di qualche ora di consulenza legale è trascurabile rispetto al valore del progetto e ai rischi di un contratto mal scritto.

Checklist: cosa controllare prima di firmare

Prima di apporre la firma, verifica punto per punto che il contratto risponda "sì" a queste domande:

1. Il codice sorgente sarà di tua proprietà alla consegna?
2. Ci sono specifiche funzionali allegate o richiamate esplicitamente?
3. Le milestone e le date di consegna sono scritte nel contratto?
4. Il piano di pagamento è chiaro e legato ai deliverable?
5. Esiste una clausola di garanzia con durata e tempi di intervento?
6. È presente un NDA o una clausola di riservatezza?
7. C'è uno SLA se il fornitore gestirà il software post-lancio?
8. La clausola di exit definisce come recuperare codice e dati?
9. Hai letto le clausole sulla responsabilità del fornitore?
10. Il foro competente per le controversie è accettabile?

Conclusione

Un buon contratto software non serve a complicare il rapporto con il fornitore — serve a renderlo più chiaro e a proteggere entrambe le parti. Una software house seria non avrà problemi ad accettare le clausole descritte in questa guida: sono standard di settore, non pretese eccessive.

Se una software house si irrigidisce alla sola richiesta di chiarire la proprietà del codice o di inserire una garanzia sui bug, hai già una risposta su quanto vale quel partner.

Hai bisogno di supporto per valutare un contratto o scegliere la software house giusta per il tuo progetto? Scrivici: trovi il form di contatto qui a destra e ti risponderemo entro 24 ore.