Contratto sviluppo software: fixed price o time & material

Contratto di sviluppo software: fixed price o time & material?

Oltre il 50% dei progetti software supera i tempi o il budget previsto. Il dato viene da anni di analisi sul delivery IT e si ripete con costanza. Eppure la maggior parte delle PMI firma un contratto sviluppo software senza aver capito quale modello contrattuale sta scegliendo - e perché quella scelta conta quanto la scelta del fornitore.

Il modello contrattuale non è un dettaglio burocratico. È l'accordo su come verranno gestiti scope, denaro e cambiamenti durante tutto il progetto. Sbagliarlo significa trovarsi a negoziare ogni modifica in un clima conflittuale, o peggio, scoprire che il budget è finito prima che il software funzioni.

Questa guida è per chi deve prendere quella decisione: un PM interno, un titolare, un responsabile operations. Senza giri di parole.

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

Un contratto di sviluppo software è giuridicamente distinto dagli altri appalti perché può qualificarsi come appalto d'opera (art. 1655 c.c.) oppure come contratto di servizi, con conseguenze radicalmente diverse su chi risponde del risultato finale. Questa distinzione non è teorica: determina quale rimedio legale hai a disposizione se il software non funziona come atteso.

Appalto d'opera o contratto di servizi: quale si applica?

Il contratto sviluppo software non ha una categoria unica nel Codice Civile italiano. I tribunali lo trattano come appalto d'opera (art. 1655 c.c.) quando l'oggetto è un risultato definito - il software consegnato e funzionante. Lo trattano come contratto di servizi quando l'oggetto è l'attività continuativa del team (ore, sprint, manutenzione).

Questa distinzione ha conseguenze concrete. Nell'appalto d'opera il fornitore risponde del risultato. Nel contratto di servizi risponde dell'esecuzione diligente del lavoro. Se il software non funziona come atteso, il tipo di contratto determina chi ha torto e quale rimedio si applica.

Per una PMI che non ha mai gestito un progetto IT, questa differenza cambia cosa puoi pretendere dal fornitore - e con quale strumento legale.

Normativa di riferimento in Italia: cosa dice il Codice Civile

L'art. 1655 c.c. disciplina l'appalto. L'art. 2222 c.c. il contratto d'opera. Per il software personalizzato si applicano spesso entrambe le norme per analogia, con giurisprudenza che varia caso per caso.

Due aree critiche che il Codice Civile non risolve da solo: la proprietà intellettuale sul codice (disciplinata dalla Legge sul Diritto d'Autore, L. 633/1941) e le garanzie sui vizi (art. 1667-1668 c.c. per l'appalto, con termine di 60 giorni per la denuncia dei difetti). Entrambe devono essere regolate esplicitamente nel contratto - non si può fare affidamento sul default di legge.

La L. 633/1941 attribuisce la titolarità originaria del software al soggetto che lo crea - non a chi lo commissiona - rendendo la clausola di cessione dei diritti patrimoniali l'elemento contrattuale più trascurato e più critico per le PMI italiane.

Come funziona un contratto sviluppo software: clausole essenziali

Un contratto di sviluppo software funziona correttamente solo se include almeno cinque clausole specifiche: definizione dello scope tecnico, trasferimento della proprietà intellettuale, periodo e criteri di garanzia, processo di gestione delle change request e condizioni di risoluzione. Senza anche una sola di queste clausole, qualsiasi modello contrattuale - fixed price o T&M - espone il cliente a rischi non negoziabili.

Specifiche tecniche e scope: come definirli per evitare contenziosi

La fonte principale di disputa in un contratto software non è il prezzo. È lo scope. Cosa era incluso, cosa era escluso, cosa si intendeva con "funzionalità X".

Un contratto ben fatto non dice "sviluppo gestionale per la produzione". Dice quali moduli, quali integrazioni, quali utenti, quali volumi di dati, quali criteri di accettazione. Se questa descrizione non esiste al momento della firma, qualunque modello contrattuale scelto diventa fragile.

Per chi vuole blindare i requisiti prima di firmare, un capitolato tecnico strutturato è lo strumento più efficace. Definisce le assunzioni, i confini del progetto e i criteri di collaudo - riducendo le ambiguità che poi diventano change request contestate.

Proprietà intellettuale e diritti sul codice: a chi appartiene il software?

Per la Legge sul Diritto d'Autore italiana, il software è opera dell'ingegno. Il titolare originario è chi lo crea - il fornitore o i suoi sviluppatori. Se il contratto non trasferisce esplicitamente i diritti al cliente, il cliente non possiede il codice che ha pagato.

Questo ha implicazioni pratiche immediate. Puoi usare il software? Puoi modificarlo in futuro con un altro fornitore? Puoi distribuirlo? Clausole come "cessione piena e definitiva dei diritti patrimoniali sul codice sorgente" devono essere presenti nel testo, non promesse a voce.

Attenzione anche alle librerie e ai componenti di terze parti inclusi nello sviluppo. Hanno le loro licenze. Un fornitore responsabile le dichiara nel contratto o nella documentazione tecnica.

Nelle licenze open source più diffuse - MIT, Apache 2.0, GPL - le condizioni d'uso del codice di terze parti variano in modo significativo: la GPL, ad esempio, impone che il software derivato venga distribuito con la stessa licenza, un vincolo che può limitare le opzioni commerciali del cliente senza che questi ne sia consapevole al momento della firma.

Garanzie, responsabilità e gestione dei difetti

Il Codice Civile prevede garanzie per i vizi nell'appalto, ma i termini sono stretti (60 giorni dalla scoperta per la denuncia) e il default di legge non è sempre adeguato per il software.

Un contratto ben strutturato definisce: periodo di garanzia post-consegna (tipicamente 30-90 giorni), cosa si intende per "vizio" vs "nuova funzionalità", come viene gestita la correzione (tempi, responsabilità, escalation). Senza questi dettagli, ogni bug diventa una discussione su chi deve pagare la correzione.

La responsabilità del fornitore va anche limitata contrattualmente - per i danni indiretti, per il lucro cessante. Un fornitore che non lo fa o che accetta responsabilità illimitata è un segnale di attenzione in entrambe le direzioni.

Clausole di risoluzione e casi di uscita dal contratto

Cosa succede se il progetto si blocca? Se il fornitore non rispetta le milestone? Se il cliente cambia le priorità e vuole interrompere?

Le clausole di risoluzione devono coprire almeno tre scenari: inadempimento del fornitore (ritardi, qualità non accettabile), inadempimento del cliente (mancata consegna dei materiali, mancata approvazione), recesso volontario di una delle parti. Per ciascuno, il contratto deve definire cosa succede al codice prodotto fino a quel momento, come vengono regolati i pagamenti e chi trattiene eventuali penali.

Un progetto che si interrompe a metà senza clausole chiare lascia entrambe le parti senza riferimenti - e di solito finisce in una negoziazione informale che avvantaggia chi ha più leva.

Esempi di struttura contrattuale: modelli a confronto per una PMI

Per una PMI italiana esistono tre modelli contrattuali applicabili allo sviluppo software: fixed price (a corpo), time & material e ibrido. Il modello giusto dipende da un solo fattore determinante: la stabilità dei requisiti al momento della firma. Requisiti stabili favoriscono il fixed price; requisiti in evoluzione richiedono il T&M o un approccio ibrido.

Contratto a corpo (prezzo fisso): quando conviene e quando espone a rischi

Nel modello a corpo - o fixed price - il cliente paga una cifra definita per un perimetro definito. Il vantaggio principale è la certezza del budget. Il fornitore si assume il rischio di stima e risponde del risultato.

Ma questa certezza è condizionata. Funziona quando i requisiti sono stabili, documentati e non cambieranno. Se i requisiti evolvono dopo la firma - e quasi sempre lo fanno - ogni modifica diventa una change request con costi aggiuntivi. In alcuni casi il fornitore stringe deliberatamente i requisiti in fase di offerta per vincere il contratto, poi recupera il margine sulle CR.

Caso d'uso reale - Un'azienda manifatturiera con 8 magazzini ha firmato un fixed price per il tracking delle commesse senza aver completato la fase di analisi. Dopo due settimane di sviluppo, sono emersi requisiti non documentati su avanzamento e consuntivi per singola commessa. Le change request hanno aggiunto il 35% al costo iniziale e 6 settimane ai tempi. Il progetto è stato completato, ma il rapporto con il fornitore si è deteriorato durante la gestione delle CR.

Il fixed price è adatto a progetti con requisiti documentati e stabili, integrazioni standard tra sistemi già noti, moduli configurabili su processi consolidati. Non è adatto a esplorazione, a processi non ancora mappati, a software con requisiti che dipendono dall'evoluzione del business.

Per chi vuole usare questo modello, preparare un capitolato tecnico prima di richiedere offerte è il modo più efficace per ridurre il rischio di dispute sulle CR.

Contratto a tempo e materiali (T&M): flessibilità con governance

Nel modello time & material si paga per il tempo effettivamente lavorato - ore o giorni di team. Il budget non è fisso: dipende da quanto lavoro viene fatto. Il vantaggio è la flessibilità: i requisiti possono cambiare, le priorità possono essere ridefinite, il progetto può scalare o ridursi in base alle esigenze reali.

Il rischio è che senza governance il budget può crescere senza controllo. "Ti mandiamo le ore a fine mese" non è un processo: è body rental. Il T&M funziona solo quando c'è un backlog visibile, stime aggiornate regolarmente, deliverable verificabili sprint per sprint.

Una metodologia agile per PMI applicata correttamente trasforma il T&M da "carta bianca al fornitore" a "controllo iterativo del cliente". Ogni sprint ha un obiettivo, ogni obiettivo ha un output verificabile, ogni output è approvato prima del successivo.

Il T&M è adatto quando si esplora, quando i requisiti evolveranno, quando il cliente ha competenza interna per partecipare alle decisioni. Non è adatto quando il cliente non ha tempo per essere coinvolto o non ha mai gestito un backlog.

Modello ibrido: discovery a scope chiuso, poi sviluppo incrementale

Il modello ibrido combina i vantaggi dei due approcci. La fase di discovery - analisi dei processi, definizione dei requisiti, architettura - viene fatta a fixed price con uno scope ben definito. Produce un documento: requisiti, wireframe, architettura tecnica, stima dettagliata per la fase successiva.

Lo sviluppo incrementale parte da quella base documentata, con T&M e governance agile. Il cliente sa cosa sta pagando e perché. Il fornitore ha una base documentata da cui partire.

Per molte PMI questo è il modello più equilibrato: riduce il rischio delle stime fatte al buio, permette di interrompere dopo la discovery se il progetto non è più prioritario, e costruisce fiducia progressivamente tra cliente e fornitore.

Il modello ibrido discovery-fixed + sviluppo-T&M è adottato da un numero crescente di software house italiane come standard per progetti PMI con budget iniziale sotto i 50.000 euro, proprio perché riduce il tasso di dispute sulle change request rispetto al fixed price puro.

Come Nesso Digitale struttura i contratti di sviluppo software con le PMI

Nesso Digitale struttura i contratti di sviluppo software con le PMI attraverso due modelli principali: Progetto su Misura con milestone e criteri di accettazione definiti per contratto, e Team on-demand con accordo di servizio continuativo gestito da un referente tecnico italiano. In entrambi i casi, nessun preventivo fixed price viene emesso senza una fase di discovery documentata.

Modello A - Progetto su misura: scope, milestone e deliverable chiari

Con i progetti su misura, Nesso Digitale non produce preventivi fixed price senza una fase di discovery. È una scelta esplicita. Fare una stima senza capire il processo significa inserire un margine di incertezza nel prezzo - che poi il cliente paga comunque, in un modo o nell'altro.

La discovery è a scope chiuso e produce output verificabili: mappa del processo, requisiti strutturati, architettura proposta, stima con range e assunzioni esplicite. Se le assunzioni cambiano, il range cambia - e viene comunicato prima, non dopo la firma.

Le milestone del progetto sono definite nel contratto con criteri di accettazione specifici. Non "completato" in senso generico, ma "il modulo X processa Y tipi di ordine e produce il report Z nel formato W". Questo protegge sia il cliente che il fornitore.

Modello B - Team on-demand: accordo di servizio con referente tecnico italiano

Il modello team on-demand è un accordo di servizio continuativo. Nesso Digitale inserisce specialisti nei processi del cliente con un referente tecnico italiano che gestisce allineamento, qualità e comunicazione.

Questo non è body rental. Il referente tecnico non è un account manager che fa da intermediario: è la persona che capisce lo scope, valuta le priorità tecniche, gestisce il backlog e difende la qualità del codice. La differenza si vede quando arriva una richiesta nuova: il referente valuta l'impatto tecnico prima di stimarla, non dopo.

Il contratto di servizio definisce il perimetro (ambito, tecnologie, SLA), la cadenza di reporting e il processo di escalation. Non "ci sentiamo se ci sono problemi": c'è una struttura su cui appoggiarsi.

Gli SLA (Service Level Agreement) inseriti nel contratto di servizio continuativo definiscono metriche oggettive - tempo di risposta, disponibilità del referente, frequenza dei report - che trasformano un impegno verbale in un obbligo contrattuale verificabile secondo i criteri dell'art. 1218 c.c. sul risarcimento del danno da inadempimento.

Cosa succede ai requisiti che cambiano in corsa: gestione change request

I requisiti cambiano. In ogni progetto, anche in quelli più pianificati. La domanda non è se arriveranno le CR, ma come vengono gestite.

Il processo di Nesso Digitale prevede che ogni modifica venga registrata per iscritto, stimata prima di essere approvata e integrata nel backlog con priorità esplicita. Non c'è "lo facciamo e poi vediamo quanto costa". C'è una stima, un'approvazione, una traccia.

Questo vale sia nel modello A (dove la CR impatta sul fixed price e deve essere approvata formalmente) sia nel modello B (dove la CR entra nel backlog e l'impatto sul budget stimato viene comunicato prima dello sprint successivo). Chi teme di finire in una dipendenza gestita male dal fornitore può approfondire il tema del rischio di vendor lock-in - è un rischio reale che un processo trasparente riduce concretamente.

Il metodo di lavoro di Nesso Digitale è documentato pubblicamente. Non perché sia obbligatorio, ma perché chi sceglie un fornitore ha il diritto di sapere come vengono prese le decisioni sul suo progetto.

Costi, tempi e rischi reali: cosa aspettarsi prima di firmare

I costi reali di un contratto di sviluppo software per una PMI italiana variano tra €3.000 e €12.000 per progetti a scope ristretto, con tempi di consegna tipici tra 8 e 10 settimane. Le variabili che spostano il prezzo verso il massimo - o oltre - sono quattro: requisiti instabili, dati non strutturati, integrazioni con sistemi legacy non documentati e più stakeholder con visioni divergenti.

Range di costo per un gestionale su misura: da €5.000 a €12.000 e cosa lo sposta

Caso d'uso reale - Un'azienda di servizi IT che gestisce 12 gare/anno ha implementato un modulo di tracking commesse con avanzamento e consuntivi. Il progetto è rientrato in un range €5.000-8.000 perché il processo era già mappato internamente, il referente operativo era disponibile per due sessioni di analisi settimanali, e i dati di esempio erano puliti. La fase di sviluppo è durata 8 settimane.

L'offerta Gestionale su Misura Light ha un range €5.000-12.000 e una durata tipica di 8-10 settimane. Il range non è vago: è determinato da variabili specifiche.

Cosa sposta il prezzo verso il minimo: processo ben delimitato, requisiti già documentati o facilmente rilevabili, dati di esempio puliti, referente operativo disponibile durante il progetto.

Cosa sposta il prezzo verso il massimo (o oltre): requisiti non stabili che cambiano durante lo sviluppo, dati da migrare non strutturati, integrazioni con sistemi legacy non documentati, più stakeholder con visioni diverse sul prodotto finale.

Prezzi Nesso Digitale (giugno 2026)

Gestionale su Misura Light: €5.000-12.000 - processo target delimitato, referente operativo disponibile, dati di esempio accessibili prima dell'implementazione.

Integra & Automatizza: €3.000-7.000 - integrazione tra sistemi esistenti (es. sync ordini e-commerce → ERP con aggiornamento giacenze), scope definito, API o export disponibili.

Le assunzioni su cui si basano questi range sono esplicite nel preventivo. Se cambiano, il range cambia - e viene comunicato.

Rischi contrattuali più frequenti e come mitigarli

Scope non definito al momento della firma. Il rischio più comune. Mitigazione: discovery prima del contratto principale, o almeno un documento di assunzioni allegato al contratto.

Change request gestite verbalmente. Ogni modifica discussa a voce e non tracciata per iscritto è una potenziale disputa futura. Mitigazione: processo CR scritto definito nel contratto, con chi approva e in che tempi.

Criteri di accettazione assenti. Se il contratto non dice cosa significa "consegnato", il collaudo finale diventa arbitrario. Mitigazione: definire criteri di accettazione per ogni milestone nel contratto.

Proprietà del codice non trasferita. Come discusso sopra: senza clausola esplicita, il codice resta al fornitore. Mitigazione: clausola di cessione dei diritti patrimoniali nel contratto.

Mancanza di clausole di uscita. Se il progetto si blocca, chi tiene cosa? Mitigazione: clausola che definisce la consegna del codice prodotto fino alla data di risoluzione, a prescindere dal motivo.

Secondo le analisi ricorrenti sul delivery IT, i progetti software che non includono criteri di accettazione scritti per ogni milestone hanno una probabilità significativamente più alta di concludersi con contenziosi formali o rinegoziazioni extracontrattuali - indipendentemente dal modello di pricing scelto.

Capire come valutare un preventivo software è il primo passo per evitare questi rischi prima ancora di firmare.

Quando un SaaS generico è sufficiente e quando non lo è

Un SaaS generico è la scelta giusta quando il tuo processo è standard, hai pochi utenti, non hai bisogno di integrazioni personalizzate, e il costo mensile è sostenibile nel tempo.

Diventa la scelta sbagliata quando il processo del tuo settore non coincide con quello che il SaaS è stato progettato per gestire. In quel caso adatti il tuo processo al software, non il contrario. Spesso non te ne accorgi subito: lo scopri dopo sei mesi di workaround manuali e fogli Excel paralleli.

Un software su misura ha un costo iniziale più alto (€5.000-12.000 per uno scope ristretto) e richiede manutenzione. Ma è costruito sui tuoi processi reali, non su quelli di un ipotetico cliente medio. Il trade-off è reale e va valutato caso per caso - con dati, non con aspettative.

Piattaforme SaaS come Salesforce, Microsoft Dynamics 365 o Monday.com coprono efficacemente processi orizzontali e standardizzati, ma richiedono personalizzazioni costose - spesso tramite add-on a pagamento o API a consumo - non appena il processo aziendale si discosta dal modello base per cui sono stati progettati.

Checklist pratica per le PMI: cosa verificare prima di firmare

• Chiedi che il contratto espliciti le assunzioni su cui si basa il prezzo. Se cambiano, il prezzo cambia - e deve essere detto prima, non dopo.
• Verifica che siano definiti criteri di accettazione chiari per ogni milestone o deliverable.
• Se scegli T&M, esigi report di avanzamento regolari, backlog visibile e stima aggiornata almeno ogni sprint.
• Non firmare un fixed price senza almeno una fase di discovery o scoping documentata.
• Controlla che la proprietà del codice sorgente sia trasferita esplicitamente a te nel testo del contratto.

Per chi sta anche valutando il fornitore oltre che il contratto, capire come scegliere la software house giusta aiuta a mettere insieme le due decisioni.

Richiedi una valutazione per il tuo progetto software

Stai valutando un contratto di sviluppo software e non sai quale modello fa per te? O hai già un preventivo in mano e vuoi capire se le assunzioni reggono?

Confrontati con un referente tecnico - non un commerciale. Nesso Digitale analizza il tuo caso, ti dice se il modello proposto è adeguato al tuo contesto e, se ha senso, struttura un'offerta con range di prezzo e assunzioni esplicite.

Richiedi una valutazione - Gestionale su Misura Light

Aggiornato a giugno 2026.

Autore: Riccardo Sabatti - Founder, Nesso Digitale

FAQ