SOW e MSA: quale contratto protegge il tuo progetto SaaS

MSA e SOW sono due metà dello stesso contratto software. Il contratto quadro (MSA, master service agreement) fissa i termini legali che governano tutto il rapporto: chi possiede il codice, chi risponde quando qualcosa si rompe, come si tratta l'informazione riservata, come finisce l'accordo. Il capitolato di lavoro (SOW, statement of work) definisce il singolo progetto dentro quei termini: i deliverable, i tempi, il prezzo, i criteri di accettazione. Si firma un MSA per fornitore, poi si allega un nuovo SOW per ogni progetto che segue.

Se sei un founder o un CTO che sta per ingaggiare uno studio, un'agenzia o un freelance per costruire un SaaS, la struttura che firmi non è burocrazia. Decide chi possiede ciò che hai pagato, e chi paga quando un progetto va per le lunghe. Questa è una guida a come i due documenti si dividono il lavoro, e a cosa un compratore deve controllare in ciascuno prima di firmare. Non è consulenza legale: per un contratto che muove soldi veri o proprietà intellettuale vera, fai revisionare il testo a un avvocato.

SOW e MSA: la versione in 30 secondi

Firma un MSA quando prevedi più di un progetto con lo stesso fornitore, o un progetto che pensi di estendere. Negozia i termini legali difficili una volta sola, così non li riapri a ogni progetto. Firma un SOW per ogni pezzo di lavoro: è breve, specifico, ed è l'unico documento che deve cambiare quando cambia lo scope. L'MSA è la cornice. Il SOW è il quadro. Chi salta l'MSA e firma un unico contratto tutto-in-uno scopre il buco la prima volta che aggiunge un secondo progetto, o la prima volta che qualcosa va storto.

Cosa governa davvero l'MSA

Nell'MSA vivono i termini che sopravvivono al progetto. Cinque clausole ricevono in pratica l'esame più duro: proprietà intellettuale, limitazione di responsabilità, manleva, recesso e sicurezza dei dati. Sono quelle che conviene leggere con attenzione prima di firmare (SMVRT Legal).

Proprietà intellettuale. L'MSA deve dire che il lavoro prodotto per te è ceduto a te, e deve dire quando quella cessione ha effetto. La proprietà può maturare alla creazione, alla consegna e accettazione, o al pagamento (Icertis). Maturare al pagamento è comune e ragionevole, ma leggila: se contesti una fattura, potresti non possedere il codice finché non è saldata. L'MSA deve anche separare la tua IP dall'IP preesistente del fornitore e da eventuali componenti di terzi o open source, con una licenza d'uso per tutto ciò che il fornitore riusa tra i clienti.

Limitazione di responsabilità. Quasi tutti gli MSA limitano la responsabilità totale di ciascuna parte alle somme pagate nei dodici mesi precedenti (Icertis). Tre cose decidono se quel tetto ti protegge: l'importo, la finestra a cui si riferisce, e cosa ne resta escluso. Violazioni di IP, di riservatezza e colpa grave sono di solito escluse dal tetto, quindi la responsabilità per quelle resta senza limite. Un tetto pari a un mese di compensi su un progetto lungo un anno non è una protezione vera.

Manleva. La manleva decide chi paga quando fa causa un terzo. Le parole pesano più del titolo: una clausola che ti rende responsabile per pretese "relative a" un lavoro è molto più ampia di una limitata alle pretese "derivanti da" tue azioni (SMVRT Legal). La manleva reciproca, dove il fornitore copre le pretese di terzi che nascono dalla sua violazione di IP, è la base equa.

Cosa definisce davvero il SOW

Il SOW è il documento in cui vivono i tuoi team di prodotto e sviluppo. Nomina i deliverable, li spezza in milestone, fissa i tempi, fissa il prezzo o la tariffa, e definisce l'accettazione: come decidi che il lavoro è finito. Un SOW vago è dove muoiono i budget. I contratti che non tracciano una linea netta tra lo scope iniziale e le aggiunte successive invitano discussioni su se una funzione fosse sempre prevista o sia lavoro nuovo (Genie AI).

La clausola che tiene onesto un SOW è il processo di change order. Lo scope si muoverà. L'unica domanda è se muoverlo sia una decisione messa per iscritto o una lite sei settimane dopo. Le indagini di settore stimano le perdite da scope creep tra circa il 15 e il 27 percento del budget di progetto (Digital Applied). Una clausola di change order che funziona dice chi può approvare una modifica, chiede una stima scritta dell'impatto su costo e tempi prima di iniziare, e stabilisce che la scadenza non si sposta se non lo dice il change order stesso.

La clausola che decide i conflitti: l'ordine di prevalenza

Poiché i due documenti possono contraddirsi, ogni coppia MSA più SOW ha bisogno di una clausola di ordine di prevalenza. Dice quale documento vince quando i termini confliggono. Ci sono due approcci comuni, e puntano in direzioni opposte.

Il default in quasi tutti gli MSA è che l'MSA prevale, a meno che uno specifico SOW non lo deroghi in modo esplicito e per iscritto (Aaron Hall). Così i termini legali negoziati non vengono riscritti di nascosto dentro un perimetro di progetto. L'alternativa, comune dove i SOW sono molto personalizzati, è che il SOW prevalga solo per quel progetto, sulla logica che il documento più specifico debba vincere (American Bar Association). Entrambe reggono. Ciò che non regge è il silenzio: senza una clausola di prevalenza, un conflitto diventa una discussione tra avvocati, e scopri chi aveva ragione in una controversia invece che nel contratto.

Cosa controllare prima di firmare

1. C'è un MSA? Un unico contratto combinato va bene per un piccolo lavoro. Oltre, chiedi la struttura a due documenti così i termini legali smettono di essere rinegoziati a ogni progetto.
2. La IP matura in modo pulito, e quando? Verifica che codice e design siano ceduti a te, che i componenti preesistenti e open source siano separati, e che tu conosca il momento esatto in cui scatta la proprietà.
3. Qual è il tetto di responsabilità, e cosa resta escluso? Leggi importo, finestra temporale ed esclusioni. Un tetto molto sotto il valore del contratto è un allarme, non una formalità.
4. Il processo di change order è messo per iscritto? Se le modifiche di scope si gestiscono via email e buona volontà, si gestiranno via controversia dopo. È uno dei campanelli d'allarme da controllare prima di firmare.
5. C'è una clausola di ordine di prevalenza? Se manca, aggiungila. Decidi ora quale documento vince, non durante un conflitto.
6. Come funziona il recesso, e cosa tieni? Un'uscita pulita consegna tutto ciò che è stato costruito fino a quel punto. Verifica che la consegna sia un diritto, non un favore.

Definire bene lo scope prima di tutto questo è un lavoro a parte. Una fase di discovery breve e pagata produce la lista di deliverable di cui un SOW vero ha bisogno, ed è per questo che trattiamo il prezzo della discovery e il brief al fornitore come lavoro che avviene prima che il SOW sia scritto, non dopo.

Cosa usiamo noi e perché

Firmiamo un MSA per cliente, poi un SOW breve per progetto. L'MSA porta i termini che non vogliamo mai riaprire: IP ceduta al cliente al pagamento, un tetto di responsabilità reciproco, riservatezza, e un percorso di recesso pulito che consegna tutto ciò che abbiamo costruito. Il SOW resta volutamente breve, così si legge in fretta e si modifica in fretta, con una clausola di change order che trasforma una richiesta di scope in una decisione di due righe invece che in un braccio di ferro. Quando un progetto è un singolo piccolo lavoro senza aspettativa di un secondo, un contratto combinato è più semplice e lo diciamo. Oltre, separare la cornice legale dal perimetro di progetto è ciò che permette a un rapporto di aggiungere progetti senza rinegoziare la legge ogni volta.