Prezzo fisso o retainer per un SaaS: quale conviene e quando

Scegliere tra prezzo fisso e retainer vuol dire scegliere tra comprare un risultato definito a un prezzo stabilito e comprare ogni mese il tempo di un team, su un backlog che continua a cambiare. Con il prezzo fisso si bloccano cosa si consegna, quando e a quanto, e il rischio della stima passa al fornitore. Con il retainer si bloccano il costo mensile e il team, mentre cosa si rilascia può cambiare da un mese all'altro.

La domanda arriva sul tavolo di un founder due volte. Una volta prima dello sviluppo, quando un consiglio o un investitore chiede un numero solo. E di nuovo dopo il lancio, quando il backlog è più lungo del budget. Nei due momenti la risposta giusta cambia. Qui mettiamo a confronto i due modelli come deve farlo chi compra: cosa compri con ciascuno, dove ciascuno si inceppa, e come capire da una proposta quale dei due ti stanno vendendo davvero.

La risposta breve: quale scegliere e quando

Il prezzo fisso conviene quando quello che va sviluppato si può descrivere per intero prima di cominciare, e un cambio a metà strada sarebbe l'eccezione. Un sito istituzionale, un'integrazione ben definita, una fase di discovery, una migrazione con uno stato finale noto.

Il retainer conviene quando il prodotto è online, gli utenti ti dicono cosa fare dopo e fra sei settimane la lista sarà un'altra. In mezzo c'è la prima versione di un SaaS nuovo, dove nessuno dei due modelli calza bene. Lì funziona meglio una sequenza di entrambi (ne parliamo più avanti).

Prezzo fisso e retainer a confronto

• Cosa compri. Prezzo fisso: un elenco di deliverable con i criteri di accettazione. Retainer: il tempo di un team ogni mese, contato in ore, giornate o persone.
• Cosa resta fermo. Prezzo fisso: prezzo, perimetro e data, tutti e tre. Retainer: il costo mensile e il team; il perimetro si muove.
• Chi si prende il rischio della stima. Prezzo fisso: il fornitore, che lo mette nel prezzo come margine di sicurezza. Retainer: tu, attraverso il numero di mesi che servono.
• Come si gestisce un cambio. Prezzo fisso: una richiesta di modifica, quotata e firmata prima di andare avanti. Retainer: si riordina il backlog alla pianificazione successiva.
• Su cosa si discute. Prezzo fisso: se una richiesta è un cambio o era nel perimetro fin dall'inizio. Retainer: se il team rilascia abbastanza per quello che costa al mese.
• Forma del budget. Prezzo fisso: un totale approvato una volta, di solito pagato a milestone. Retainer: un costo operativo che continua finché una delle due parti non dà disdetta.
• Dove funziona meglio. Prezzo fisso: lavori con uno stato finale noto. Retainer: un prodotto con utenti veri e un backlog che cambia.

Quando vince il prezzo fisso

Quando lo stato finale si può mettere per iscritto

Il prezzo fisso funziona se i requisiti sono abbastanza stabili da elencarli con i criteri di accettazione. Un'integrazione di pagamento con un fornitore preciso. Una migrazione dati da uno schema all'altro. La ricostruzione di un prodotto esistente, funzione per funzione. In tutti questi casi la stima è in buona parte una somma di attività note, e il fornitore la quota senza gonfiarla troppo.

Quando chi approva vuole un numero solo

Consigli di amministrazione, uffici acquisti e bandi approvano totali. Un prezzo fisso con pagamenti a milestone è il formato che sanno già firmare. Anche un retainer si può approvare, ma si legge come un costo operativo senza fine, e in un'azienda che non ha ancora deciso se il prodotto esisterà fra un anno è una conversazione più difficile.

Quando stai comprando una decisione

La discovery è l'acquisto a prezzo fisso più pulito che ci sia: una durata stabilita, un risultato definito (ricerca, architettura, prototipo, un piano con i costi) e un prezzo concordato prima. Trasforma uno sviluppo pieno di incognite in qualcosa che due parti possono stimare. Quanto dovrebbe costare, e cosa rifiutare, l'abbiamo scritto in quanto costa la discovery nel 2026.

Quando il lavoro è breve

Più la data è lontana, più la stima peggiora. In una ricerca su oltre 5.400 progetti IT, McKinsey e l'Università di Oxford hanno trovato che ogni anno in più di durata prevista fa crescere lo sforamento dei costi del 15% (McKinsey). Erano progetti sopra i 15 milioni di dollari, molto più grandi di un SaaS. Il meccanismo però è lo stesso a ogni scala: più la consegna è lontana, più il mondo cambia prima che ci arrivi. Un prezzo fisso di sei settimane è una scommessa molto più sicura di uno di nove mesi.

Quando vince il retainer

Quando la roadmap la scrivono gli utenti

Dopo il lancio, la guida migliore per decidere cosa fare dopo è quello che le persone fanno con quello che hai rilasciato. Con un retainer queste informazioni arrivano al team alla pianificazione successiva. Con il prezzo fisso arrivano come richiesta di modifica, e ogni richiesta di modifica è una piccola trattativa.

Quando il perimetro cambierà comunque

Secondo il Pulse of the Profession 2018 di PMI, il 52% dei progetti chiusi nei dodici mesi precedenti ha subito scope creep o cambi non controllati, contro il 43% di cinque anni prima (PMI). Se un cambio è così probabile, un contratto costruito per resistergli spende le energie nella resistenza. Martin Fowler l'aveva detto già nel 2003: il contratto a perimetro fisso mette cliente e fornitore su fronti opposti, a litigare su cosa sia un cambio e su chi debba pagarlo (Fowler, Scope Limbering).

Quando la continuità vale dei soldi

Un team che lavora su una codebase da sei mesi sa dove sono i punti fragili, quali test contano e perché un campo si chiama come si chiama. In una serie di progetti a prezzo fisso separati, questa conoscenza può andarsene tra un contratto e l'altro, e ogni progetto nuovo paga per ricostruirla. Con il retainer le stesse persone restano sullo stesso codice.

Quando il lavoro è un flusso continuo

Patch di sicurezza, aggiornamenti delle dipendenze, lavoro sulle performance, piccole correzioni, una funzione ogni tanto. Niente di tutto questo è abbastanza grande da quotarlo a parte, e tutto va fatto. Quel costo ricorrente l'abbiamo scomposto in quanto costa mantenere un sito web nel 2026, e le fasce mensili dei retainer di design in prezzi del retainer di product design.

Perché la prima versione di un SaaS non sta in nessuno dei due

Un SaaS nuovo cade proprio nello spazio tra i due modelli. Il perimetro è troppo incerto per un contratto del tutto fisso: quello che scopri alla quarta settimana cambierà l'ottava. Ed è troppo presto per un retainer aperto: nessuno ha ancora usato il prodotto, e un canone mensile senza una prima release definita non ti dà nessuna data da far rispettare.

La via d'uscita è smettere di bloccare prezzo, perimetro e data tutti insieme. L'alternativa di Fowler era fissare budget e data di rilascio, poi decidere insieme il miglior insieme di funzioni che ci sta dentro (Fowler, Fixed Price). Il Manifesto Agile diceva la stessa cosa in poche parole: la collaborazione con il cliente conta più della negoziazione del contratto (Agile Manifesto). In uno sviluppo SaaS, questo diventa una sequenza di tre contratti:

1. Una discovery a prezzo fisso. Qualche settimana, un prezzo stabilito e un risultato che puoi portare a qualsiasi fornitore: la prima versione messa per iscritto, un'architettura e un piano con i costi.
2. Una prima release a budget fisso. Un prezzo e una data di lancio, con un elenco di funzioni in ordine di priorità al posto di uno congelato. Quando entra qualcosa di nuovo, esce qualcosa della stessa taglia, o slitta a dopo il lancio. Il contratto stabilisce la regola dello scambio, non ogni singola funzione.
3. Un retainer dopo il lancio. Lo stesso team con un canone mensile, su un backlog che adesso prende forma dall'uso reale, con un preavviso per entrambe le parti.

Ogni passo usa il modello adatto all'incertezza di quel momento. E ognuno ti lascia un'uscita: il risultato della discovery può andare a un altro fornitore, e il retainer si può chiudere se il lavoro smette di valere il canone. Il costo di ogni scenario l'abbiamo stimato in quanto costa sviluppare un SaaS nel 2026.

Come leggere una proposta con ciascun modello

L'etichetta di una proposta conta meno delle sue clausole. Un "prezzo fisso" con un perimetro vago si comporta come un retainer, fatturato a colpi di richieste di modifica. Un "retainer" senza report non ti dà modo di giudicare il canone. Cinque cose da controllare:

• I criteri di accettazione. In una proposta a prezzo fisso, ogni deliverable dovrebbe dire come capirai che è finito. Se c'è scritto "gestione utenti" e nient'altro, la discussione su cosa includa comincia il primo giorno.
• Il processo di modifica. Chi quota un cambio, in quanto tempo e a quale tariffa giornaliera. Un prezzo fisso con un processo di modifica lento o caro finisce sopra il preventivo.
• Il margine di sicurezza. Un fornitore che si prende il rischio della stima lo mette nel prezzo. Chiedi come è stata costruita la stima. Un totale senza dettaglio nasconde quanta parte è riserva.
• I report del retainer. Cosa è stato rilasciato ogni mese, cosa viene dopo e dove sono andate le ore. Senza, non puoi sapere se il canone compra avanzamento.
• Ore non usate e preavviso. Se le ore non usate si accumulano o scadono, e quanto preavviso deve dare ciascuna parte. Insieme decidono quanto costa andarsene.

La struttura del contratto conta quanto il modello di prezzo. Un accordo quadro con statement of work separati ti fa gestire una discovery a prezzo fisso e un retainer successivo con le stesse condizioni; i due documenti li abbiamo confrontati in SOW e MSA. Per le clausole da controllare prima di firmare, vedi le 8 clausole da controllare.

Come appare la sequenza in uno sviluppo vero

Prendiamo un caso ipotetico. Un founder ha un'idea B2B validata, un round seed e un consiglio che vuole una data di lancio. Una discovery a prezzo fisso trasforma l'idea in un elenco di funzioni ordinato, un'architettura e un budget per la prima release. La release procede con quel budget fisso e una data fissa. A metà strada, un cliente pilota chiede il single sign-on, e un export dei report di taglia simile slitta a dopo il lancio. La release esce alla data prevista, con le funzioni che a quel punto contavano di più. Dal lancio, lo stesso team passa a un retainer, e l'export è la prima voce del backlog.

Nessun contratto di questa sequenza prova a prevedere il prodotto intero. Ognuno mette un prezzo solo su quello che si può sapere il giorno in cui lo si firma.