Contratto di sviluppo software: le clausole che ti salvano (o ti fregano)

Molti contratti di sviluppo software vengono firmati guardando soprattutto una cosa: il prezzo. Le clausole che determinano davvero cosa succede se qualcosa va storto — di chi è il codice, cosa vuol dire “consegnato”, cosa succede a un ritardo grave — restano spesso quelle scritte dal fornitore, per proteggere il fornitore. Non per malafede: è normale che chi scrive il contratto lo scriva a proprio favore, se dall’altra parte nessuno lo rinegozia.

Di chi è il codice quando il progetto finisce

È il punto meno scontato di tutti: per default, i diritti di utilizzazione economica su un software sviluppato su commissione non passano automaticamente al committente solo perché lo ha pagato. Va scritto esplicitamente: la cessione dei diritti patrimoniali sul codice a tuo favore, con data certa (di norma al saldo, non prima). Senza questa clausola, hai pagato un software che, in un contenzioso, potrebbe non essere legalmente tuo.

Cosa significa davvero “consegna del codice sorgente”

Non basta “vi diamo il codice”. Il contratto dovrebbe specificare cosa include la consegna: repository con lo storico delle versioni, credenziali di accesso, librerie e dipendenze usate, file di configurazione, documentazione tecnica minima (architettura, procedure di deploy). Il codice sorgente senza questo contorno è spesso inutilizzabile per chiunque non sia chi lo ha scritto.

Collaudo: quando puoi dire che il lavoro non va bene

Il contratto deve stabilire quali verifiche vengono fatte, entro quale termine puoi segnalare anomalie, e cosa succede se il collaudo non viene superato. Fondamentale: distinguere difetti bloccanti (impediscono l’uso) da quelli non bloccanti, e legare l’ultima tranche di pagamento al superamento del collaudo — non alla semplice consegna.

Penali e conseguenze di un ritardo grave

Un fornitore sicuro del proprio lavoro accetta clausole penali per ritardi oltre una soglia definita, e criteri chiari per il recesso anticipato in caso di inadempimento prolungato. La loro assenza non è neutra: significa che il rischio del ritardo, in pratica, lo porti solo tu.

La clausola che quasi nessuno mette: cosa succede se il fornitore sparisce

Fallimento, chiusura, o semplicemente un fornitore che smette di rispondere: senza una tutela esplicita — tipicamente un deposito del codice sorgente presso un terzo indipendente (escrow), liberato al verificarsi di condizioni predefinite — resti senza codice e senza chi lo conosce, nello stesso momento. Vale la pena prevederla soprattutto sopra una certa soglia di valore o criticità del progetto.

Gestione delle modifiche a progetto avviato

Cambierà qualcosa: è fisiologico. Il contratto dovrebbe definire come si valuta una richiesta di modifica (impatto su tempi e costi), chi la approva prima che diventi lavoro fatto, e come viene prezzata. Senza questo, ogni variazione diventa una trattativa da zero, di solito nel momento in cui hai meno margine per discutere.

In sintesi

Sei clausole fanno la differenza tra un contratto che ti protegge e uno che protegge solo chi lo ha scritto: proprietà del codice esplicita, definizione puntuale della consegna, criteri di collaudo, penali per ritardo, tutela in caso di sparizione del fornitore, e un processo per le modifiche. Se stai per firmare un contratto di sviluppo importante e vuoi un secondo parere tecnico prima di mettere la firma, con i percorsi di Advisory IT lo verifichiamo insieme.