Contratti con agenzie software: 8 clausole da controllare nel 2026

La riga più costosa in un contratto con un'agenzia software è di solito quella che nessuno legge. Un founder paga una fattura a sei cifre, manda il prodotto in produzione, poi prova a passare a un altro team e scopre che l'agenzia è ancora proprietaria del codice. È lo schema dietro la maggior parte dei segnali d'allarme in questi contratti: le clausole che decidono proprietà, pagamento e uscita stanno sotto il testo sullo scope, ed emergono solo quando qualcosa è già andato storto.

Noi costruiamo prodotti SaaS, e a volte li ereditiamo da altri team. Abbiamo letto abbastanza di questi accordi da vedere ricorrere gli stessi otto segnali d'allarme. Nessuno richiede una laurea in legge per essere individuato. Richiede di sapere dove guardare. Questo non è un parere legale: per qualsiasi contratto che impegna denaro reale, fatelo rivedere da un avvocato qualificato prima di firmare. Quello che segue è come queste clausole si comportano davvero quando il progetto è in corso, così sapete quali frasi passare per prime al vostro legale.

Segnale 1: nessuna cessione esplicita dell'IP, solo "work made for hire"

È il malinteso più costoso nei contratti software. Molti accordi etichettano i deliverable come "work made for hire" e si fermano lì. Secondo il diritto d'autore statunitense, quella sola formula spesso non trasferisce la proprietà del software commissionato. La dottrina del work made for hire è pensata per i dipendenti e per una breve lista di categorie specifiche, e il codice su commissione spesso ne resta fuori. I tribunali hanno più volte rifiutato di trattare il software come work made for hire solo perché il contratto lo affermava (CCBJournal, Association of Corporate Counsel).

La soluzione è una clausola di cessione separata ed esplicita: al saldo finale, l'agenzia cede a voi ogni diritto, titolo e interesse sul lavoro prodotto, compresi copyright, brevetti e segreti industriali. Pagare per il lavoro non significa, di default, esserne proprietari. Se il contratto ha l'etichetta "work made for hire" ma nessuna cessione di riserva, è un segnale d'allarme, non una formalità.

Segnale 2: pagamento tutto anticipato o legato al calendario

Un fornitore che chiede il 100% prima di un lavoro significativo, o che lega i pagamenti alle date invece che ai deliverable accettati, ha rimosso il proprio incentivo a finire. Una struttura sana prevede un anticipo del 20-30%, un 40-50% distribuito su due o tre milestone legate a funzionalità completate, e un 20-30% all'accettazione finale. Ogni milestone dovrebbe corrispondere a qualcosa di verificabile, non a una settimana sul calendario.

La trappola più frequente è il founder che paga il 50% anticipato per uno "sconto". Lo sconto è quasi sempre inferiore al costo del rifacimento quando il progetto va alla deriva. Il pagamento legato alle milestone tiene oneste entrambe le parti.

Segnale 3: nessun criterio di accettazione, nessuna definizione di "finito"

Se il contratto non dice mai cosa significa "finito", ogni scadenza diventa negoziabile e ogni contestazione diventa la vostra parola contro la loro. I criteri di accettazione sono la checklist che definisce un deliverable completato. Se l'agenzia non sa scriverli prima di iniziare, non ha ancora capito il lavoro.

Cercate anche una finestra di revisione definita, spesso cinque giorni lavorativi, in cui accettate una milestone o sollevate problemi specifici. Un contratto in cui l'accettazione non ha scadenza, o in cui il silenzio non conta né come accettazione né come rifiuto, lascia il progetto in un limbo permanente. Requisiti e gestione dello scope restano le prime ragioni per cui i progetti software falliscono: la ricerca CHAOS dello Standish Group tiene da anni il successo pieno sotto un progetto su tre, con requisiti poco chiari e scope creep tra le cause principali (ReqSuite, su Standish CHAOS).

Segnale 4: nessun accesso al codice durante lo sviluppo

Dovreste vedere il repository dal primo giorno, non ricevere un file zip alla fine. Quando il codice vive solo sulle macchine dell'agenzia fino alla consegna finale, non potete verificare l'avanzamento, non potete chiedere una seconda opinione e non avete leva se il rapporto si rompe a metà progetto. Pretendete la vostra organizzazione di controllo versione, con l'agenzia che lavora al suo interno. Un contratto che consegna il codice "a completamento" e non dà accesso intermedio è un meccanismo di lock-in travestito da comodità.

Segnale 5: nessuna garanzia e nessuna finestra per correggere i difetti

Il software esce con dei bug. La domanda è chi li corregge, e per quanto tempo, dopo il lancio. Un contratto senza periodo di garanzia e senza un livello di servizio sui difetti tratta il giorno della consegna come la fine di ogni responsabilità. Un termine ragionevole è una finestra definita, spesso da 30 a 90 giorni, in cui l'agenzia corregge i difetti nello scope consegnato senza costi aggiuntivi. Senza, il primo bug in produzione diventa un nuovo incarico a pagamento.

Segnale 6: lock-in tramite infrastruttura proprietaria

Alcune agenzie legano i deliverable al proprio hosting, alle proprie librerie interne o a un CMS proprietario che non potete far girare senza di loro. Il codice può essere "vostro" sulla carta e restare inutilizzabile da un altro team. Ponete una domanda diretta prima di firmare: posso prendere l'intero codice e farlo girare con un altro team domani. Se la risposta non è un sì immediato, siete davanti a un lock-in. Qui contano più gli strumenti standard e portabili di qualsiasi clausola.

Segnale 7: change request non definite e scope creep silenzioso

I requisiti cambiano in quasi ogni progetto. Il contratto dovrebbe dire come. Un processo chiaro di change request definisce come il nuovo lavoro viene quotato, approvato e fatturato prima di iniziare. Quando quel processo manca, succede una di due cose: l'agenzia assorbe le modifiche e la qualità cala, oppure le fattura in silenzio e l'importo cresce. Circa tre progetti software su quattro subiscono scope creep, quindi trattate il processo di modifica come un termine centrale, non come boilerplate.

Segnale 8: responsabilità e manleva a senso unico

Leggete la sezione sulla responsabilità dal vostro lato del tavolo. Uno squilibrio comune: l'agenzia limita la propria responsabilità alle somme pagate (o meno), mentre chiede a voi una manleva ampia. Quella combinazione significa che portate voi gran parte del rischio per un lavoro che non avete scritto. Non eliminerete ogni rischio da un contratto di servizi, e non dovreste provarci. Dovreste assicurarvi che la responsabilità non sia gravemente asimmetrica e che ogni manleva che concedete sia legata alla vostra condotta, non a quella dell'agenzia.

Come rimediare a ciò che c'è già

Se avete già firmato e ora riconoscete un segnale d'allarme, non siete senza opzioni. Chiedete una modifica scritta sulla clausola specifica: cessione dell'IP al saldo finale, finestra per la correzione dei difetti, accesso al repository. Le agenzie che intendono lavorare bene di solito accettano, perché la richiesta è ragionevole e l'alternativa è un cliente nervoso. Un'agenzia che rifiuta una cessione pulita dell'IP dopo che avete pagato vi sta dicendo qualcosa che vale la pena ascoltare. Legate ogni nuovo lavoro o milestone alla modifica, così c'è un momento naturale per firmarla.

Come prevenirlo la prossima volta

La prevenzione inizia prima del contratto. Un brief serrato e uno scope chiaro riducono la superficie su cui queste clausole possono farvi male. Scrivere un capitolato specifico che attrae i fornitori giusti filtra le agenzie il cui margine dipende dall'ambiguità. Capire come ingaggiare uno studio di product engineering e quale modello si adatta alla vostra fase vi dice come appare un contratto equo prima ancora che arrivi nella vostra casella. Tenete una checklist breve e fissa: cessione esplicita dell'IP, pagamenti a milestone, criteri di accettazione, accesso live al repo, garanzia sui difetti, infrastruttura portabile, processo di modifica e responsabilità bilanciata. Otto righe. Rileggetele ogni volta.