Time and material o prezzo fisso: le ore non hanno più senso

Time and material o prezzo fisso: la risposta corta è che il prezzo fisso funziona solo se il perimetro è davvero chiuso prima di firmare, e il time and material funziona solo se qualcuno dalla tua parte controlla ogni settimana cosa è stato fatto con quelle ore. Se nessuna delle due condizioni è vera, e nei progetti che crescono di solito non lo sono, esiste una terza formula: il canone mensile a prezzo fisso, con il perimetro deciso strada facendo.

Siamo di parte, e lo diciamo subito: sviluppiamo app e abbiamo scelto come farci pagare. Nella pagina sviluppo sta scritto così: “Il preventivo a corpo va bene per i progetti piccoli. Le ore di lavoro, nel 2026, non hanno più senso”. Questo articolo spiega il ragionamento dietro quella frase, con i numeri che pubblichiamo e con quello che le pagine in prima pagina su Google non dicono.

1. Le due formule, e cosa dice il Codice civile

Prezzo fisso, o preventivo a corpo: il fornitore si impegna a consegnare un elenco di funzioni a una cifra concordata. Se ci mette il doppio del previsto, il problema è suo. Se ci mette la metà, il margine è suo.

Time and material, o a ore: paghi il tempo effettivamente lavorato a una tariffa oraria o giornaliera, più eventuali costi vivi. Se il progetto cambia, cambia la fattura, non il contratto.

In Italia il contratto con cui si compra sviluppo software ricade spesso nelle regole dell’appalto, e il Codice civile le due formule le conosce da decenni. L’articolo 1659 dice che l’appaltatore non può cambiare l’opera senza autorizzazione scritta del committente, e aggiunge una frase che chi compra a prezzo fisso dovrebbe leggere due volte: anche quando le modifiche sono autorizzate, “se il prezzo dell’intera opera è stato determinato globalmente, non ha diritto a compenso per le variazioni o per le aggiunte, salvo diversa pattuizione”.

Tradotto: il prezzo fisso protegge il cliente dalle variazioni che chiede, a meno che il contratto non dica altro. E il contratto, nella pratica, dice sempre altro: la clausola di “diversa pattuizione” è il listino delle modifiche, il change request, una frase del tipo “ogni funzionalità non prevista nel presente preventivo sarà quotata a parte”. Non siamo avvocati e il tuo contratto va letto con uno. Ma il punto economico è semplice: il prezzo è fisso finché il perimetro è fisso. Quando il perimetro si muove, si torna a trattare.

2. Perché il prezzo fisso costa più di quanto sembra

Chi fa un preventivo a corpo deve stimare mesi di lavoro su un documento di poche pagine. Il cono dell’incertezza, il grafico reso famoso dal libro Software Estimation di Steve McConnell, la sua società Construx lo descrive così: “Estimates created at Initial Concept time can be inaccurate by a factor of 4x on the high side or 4x on the low side”. Quattro volte in più o quattro volte in meno, quando l’idea è ancora un’idea. Il cono si stringe man mano che i requisiti si chiariscono, ma nessun fornitore serio firma un prezzo sull’estremo basso di quella forchetta.

Quindi fa una delle due cose. Nella pagina sviluppo lo abbiamo scritto senza giri di parole: “Se il progetto cambia, si ricalcola tutto. Oppure paghi da subito un margine alto per gli imprevisti”. La prima strada è il preventivo che si rifà a ogni richiesta nuova. La seconda è il margine di rischio dentro la cifra: stai pagando l’assicurazione del fornitore contro le sue stesse stime. Nessuna delle due è un imbroglio. È il prezzo di spostare il rischio da una parte sola del tavolo.

C’è una terza conseguenza, meno visibile. Quando il prezzo è bloccato e il tempo finisce, qualcosa si taglia: i test, la gestione degli errori, la parte di codice che non si vede dalla demo. Il cliente riceve “quello che c’era scritto”, nel senso più stretto possibile. In 7 errori che costano 6 mesi e 30.000 euro abbiamo descritto le aziende arrivate da noi dopo aver bruciato budget con un altro fornitore: “founder con un’app a metà che non funziona, CTO con un codice che nessuno riesce più a toccare”. Non abbiamo contato quante di quelle avessero firmato un prezzo fisso. Ma è lo scenario in cui il taglio invisibile è più facile, perché nessuno lo vede dalla demo.

Quando il prezzo fisso funziona davvero

Quando il perimetro è piccolo e chiuso. Per noi la soglia è pubblica: “Progetti piccoli e chiari, sotto i 20.000 €”. Un MVP con tre funzioni, un modulo che si aggiunge a un software esistente, un’integrazione con un contorno preciso. Sotto quella cifra il cono dell’incertezza è corto, perché il lavoro si vede quasi tutto in partenza, e un preventivo a corpo è onesto per tutti e due.

A una condizione, che per noi è una regola di metodo dal 2024: “Progettiamo ogni flusso prima di scrivere codice”. I mockup approvati sono il perimetro vero. Un preventivo a corpo fatto prima dei mockup è una stima sul cono largo; lo stesso preventivo fatto dopo è una stima su schermate che il cliente ha già visto e approvato. Se ti propongono un prezzo fisso per un’app intera senza aver disegnato niente, chiedi cosa succede al prezzo quando arriveranno i mockup.

3. Perché abbiamo smesso di vendere ore

Il time and material risolve il problema del perimetro: se cambi idea, cambi idea, e paghi le ore in più. Il difetto è dove lo mette l’incentivo. Sempre dalla pagina sviluppo: “Paghi il tempo, non il risultato. Più lo sviluppatore è lento, più ti costa. Chi è bravo, paradossalmente, guadagna meno”.

Nel 2026 questo paradosso è diventato più grande. Nella pagina del canone rispondiamo alla domanda su come facciamo a costare meno di uno sviluppatore assunto: “Lavoriamo con l’AI: scrive la parte ripetitiva del codice, così un senior developer fa molto di più nello stesso tempo. Ogni riga però la legge, la testa e la firma una persona”. Pensa a cosa significa dentro un contratto a ore. Il fornitore che adotta questi strumenti fattura meno ore per lo stesso risultato. Quello che non li adotta fattura di più. La tariffa oraria premia chi resta lento. Come abbiamo organizzato il lavoro con l’AI lo abbiamo descritto in Sviluppare con l’AI: il protocollo dal ticket al push; venderlo a ore avrebbe reso quel protocollo un costo, non un vantaggio.

Il secondo difetto è il carico di controllo che passa a te. Un contratto a ore senza un referente tecnico dalla parte del cliente, che legga i report e sappia se cinquanta ore per una schermata sono tante o poche, è un contratto in cui il budget lo decide il fornitore. Se hai quella persona in casa, il time and material può funzionare. Se non ce l’hai, stai comprando ore al buio.

Quando il time and material ha comunque senso

Tre casi. Un intervento breve su codice che nessuno dei due conosce, dove qualunque stima sarebbe un’invenzione. Un team tecnico interno che ha bisogno di braccia e sa già cosa fargli fare, con un tetto massimo di ore scritto nel contratto. E la fase di analisi di un progetto grande, prima del preventivo vero: poche giornate pagate per arrivare a un perimetro su cui poi si può fissare un prezzo. In tutti e tre, la condizione è la stessa: report settimanale delle ore e un tetto oltre il quale ci si ferma a parlare.

4. La terza formula: il canone

Il canone è un prezzo fisso al mese, non per il progetto. Uno sviluppatore senior entra nel tuo team, lavora nel tuo repository, e le richieste le metti in fila tu, in ordine di priorità, cambiandole quando vuoi. Il perimetro è aperto come nel time and material, il prezzo è fisso come nel preventivo a corpo. Il rischio delle stime non lo paga nessuno, perché non ci sono stime da difendere: c’è una coda di richieste e un ritmo.

I numeri che pubblichiamo nella pagina del canone sono questi. Si parte da 2.200 euro al mese con una richiesta in lavorazione alla volta; con due richieste in parallelo 3.000, con tre 3.800, con quattro 4.500. Sempre incluso: test prima di ogni consegna, gestione del progetto, codice del cliente al 100%, disdetta con 30 giorni di preavviso. Lo sviluppatore entra nel team in 5 giorni. Per confronto, sempre dalla stessa pagina: “uno sviluppatore senior assunto costa all’azienda 7.000-8.000 € al mese tra stipendio, strumenti, ricerca e inserimento”. Quel confronto è una nostra stima, non un dato di terzi, e lo diciamo.

Chi vende ore ti dirà che il canone è time and material con un altro nome. Non lo è, per una ragione precisa: l’incentivo è rovesciato. A ore, la lentezza del fornitore è un ricavo. A canone, la lentezza del fornitore è una richiesta in meno consegnata nel mese, e il cliente la vede. “Più andiamo veloci, più funzionalità ricevi” è la frase sulla pagina, ed è anche il motivo per cui il canone è compatibile con gli strumenti AI e il time and material no.

Un esempio che possiamo citare perché è pubblico: Combiyou, l’app per mangiare meglio in modo guidato, con oltre 50.000 download e una valutazione di 4,1 stelle su più di 300 recensioni. Le ultime funzionalità, la lista della spesa e la chat, le abbiamo sviluppate con questo metodo. Non c’era un preventivo per “lista della spesa”: c’era una richiesta in cima alla coda, e il mese dopo un’altra.

Il principio non lo abbiamo inventato noi. Il secondo dei dodici principi del Manifesto Agile, del 2001, dice: “Welcome changing requirements, even late in development”. Il prezzo fisso per progetto è la formula contrattuale che più punisce quel principio. Il canone è quella che lo paga.

Quando il canone non è la risposta

Progetto piccolo e chiuso: meglio a corpo, e lo facciamo anche noi. Un unico rilascio con una data e un perimetro bloccato, per esempio per un bando o per un budget approvato come cifra unica: a corpo, dopo i mockup. Un’azienda che non ha nessuno che possa mettere in fila le richieste e approvare le consegne ogni settimana: il canone chiede quel tempo, poco ma costante, e senza quel tempo la coda si ferma. “Parti a corpo, cresci a canone” è la regola che usiamo noi: il primo blocco a prezzo fisso, poi il prodotto cresce a canone. Come si passa dall’MVP al prodotto lo abbiamo scritto in MVP: cos’è e perché serve.

5. Le tre formule in una tabella

6. Le domande da fare su qualunque preventivo

Qualunque formula ti propongano, le righe che contano non sono quelle con le cifre. Sono quelle che dicono cosa succede quando qualcosa cambia.

Le righe che invece mancano quasi sempre dal documento, dal backend alla manutenzione, le abbiamo elencate una per una in Preventivo per un’app: la riga più cara è quella che manca.

• Se è a corpo: cosa succede alle variazioni? Chiedi che la “diversa pattuizione” sia scritta prima, non dopo: come si quota una richiesta nuova, con quale tariffa, in quanto tempo. Chiedi se il prezzo include i mockup o se il prezzo arriva dopo i mockup. E chiedi cosa non è incluso: la pubblicazione sugli store, la manutenzione, le modifiche dopo il collaudo. Le voci che di solito mancano le abbiamo messe in Quanto costa pubblicare un’app e in Quanto costa mantenere un’app.
• Se è a ore: c’è un tetto massimo? Chi lo approva quando viene superato? Ogni quanto arriva il report, e con quale dettaglio? Chi decide l’ordine delle cose da fare? Se la risposta all’ultima domanda è “il fornitore”, il budget lo decide lui.
• Se è a canone: cosa è incluso nella cifra, chi è la persona che lavora sul tuo codice, quanto preavviso serve per fermarsi, e di chi è il codice il giorno che ti fermi. Sull’ultima domanda la nostra risposta è pubblica: “Tuo, dal primo giorno, nei tuoi repository. Se un giorno smetti, tieni tutto”.

Le domande valgono anche per il fornitore in sé, non solo per la formula: i controlli da fare prima di firmare sono in Come scegliere una software house. E se stai leggendo questo articolo perché il contratto a ore che hai già non ti convince più, l’ordine delle operazioni per cambiare è in Cambiare software house: prima gli accessi, poi la disdetta.

Domande frequenti

Time and material: cosa significa in un contratto di sviluppo software?

Significa che paghi il tempo lavorato, a tariffa oraria o giornaliera, più i costi vivi (i “materiali”: licenze, servizi, dispositivi). Non c’è un prezzo per il progetto, c’è una tariffa e un consuntivo. Il perimetro può cambiare in qualunque momento, e con lui la fattura.

Il prezzo fisso è la formula più sicura per il cliente?

È la più prevedibile, finché non cambi niente. Il Codice civile, all’articolo 1659, dice che con un prezzo determinato globalmente le variazioni autorizzate non danno diritto a compenso “salvo diversa pattuizione”: e quella pattuizione, nei contratti reali, c’è quasi sempre. In più il fornitore mette nel prezzo un margine per i propri imprevisti. Sicuro, quindi, solo se il perimetro è piccolo e chiuso prima di firmare.

Quanto costa un’app a prezzo fisso?

Dipende dal perimetro, e il perimetro va disegnato prima di dare una cifra. Le fasce di mercato che pubblichiamo sono in Quanto costa sviluppare un’app nel 2026. Noi facciamo preventivi a corpo per progetti piccoli e chiari sotto i 20.000 euro; sopra quella soglia proponiamo il canone, da 2.200 euro al mese.

Si può partire a prezzo fisso e passare a canone?

Sì, è la sequenza che consigliamo: il primo blocco a corpo, con i mockup approvati prima di scrivere codice, e quando il prodotto è in mano agli utenti e inizia a cambiare si passa al canone. Il codice resta nei repository del cliente in entrambe le fasi, quindi il passaggio non comporta nessun trasferimento.

Se hai un preventivo sul tavolo e non sai se la formula è quella giusta per il tuo progetto, scrivici: in una call gratuita di 30 minuti parli direttamente con chi sviluppa, e ti diciamo noi se conviene a corpo o a canone. Anche quando la risposta è “a corpo, e con un altro fornitore”. I tre modi di lavorare, uno accanto all’altro, sono nella pagina sviluppo app e software.

Fonti

• Spaghetti Coders, Sviluppo app e software, a canone o a corpo: le tre formule a confronto, soglia dei 20.000 euro, “Le ore di lavoro, nel 2026, non hanno più senso”, “Progettiamo ogni flusso prima di scrivere codice”.
• Spaghetti Coders, Sviluppo software a canone, da 2.200 € al mese: piani da 2.200 a 4.500 euro al mese, cosa è incluso, partenza in 5 giorni, disdetta con 30 giorni, confronto con un senior assunto (7.000-8.000 euro al mese, stima nostra), uso dell’AI, caso Combiyou (oltre 50.000 download, 4,1 stelle con più di 300 recensioni).
• Spaghetti Coders, Creare un’app: il nostro metodo (2024): le quattro fasi, sviluppo solo dopo l’approvazione dei mockup; 7 errori che costano 6 mesi e 30.000 euro (2026): le aziende arrivate dopo un altro fornitore.
• Brocardi, Art. 1659 Codice Civile, Variazioni concordate del progetto: testo dell’articolo, aggiornato al 29/04/2026.
• Construx, The Cone of Uncertainty: errore di stima fino a 4x in più o in meno nella fase di Initial Concept.
• Manifesto Agile, Principles behind the Agile Manifesto (2001): “Welcome changing requirements, even late in development”.
• Per contesto sulla prima pagina di Google in italiano: Innowise, Tempo e materiali vs prezzo fisso (traduzione, 28/02/2025, conclude con “l’approccio ibrido”); Context Studios, Fixed price vs time and materials (riporta una statistica “Gartner (2025) 70%+” senza dire cosa misuri). Nessuna delle due dichiara quale formula usa chi scrive.