Luglio 2023, terzo cliente Romiltec, prima call di scoping di un progetto Laravel di taglia media. Apro il foglio Excel del preventivo che avevo preparato il giorno prima e scopro un errore: il prezzo fisso al mese che gli avevo proposto via email era sotto del 18% rispetto al costo reale che avrei sostenuto. Non fallout grave, ma sufficiente per sedermi a riscrivere la formula da zero. In questo post, parte degli articoli di Workshop, racconto come ho costruito il preventivo a prezzo fisso mensile la prima volta, dove ho sbagliato e come l’ho ricalibrato dopo i primi tre clienti.
Perché prezzo fisso al mese (e non a ore o a corpo)
Il modello di pricing di Romiltec è una scelta tecnica prima che commerciale. Le tre opzioni classiche per una software house sono:
- Time and materials: il cliente paga ore di lavoro, le ore contate dal dev. Margine sul rate orario.
- Preventivo a corpo per progetto: prezzo fisso per delivery di un perimetro definito a contratto.
- Prezzo fisso al mese / abbonamento di delivery: il cliente compra capacità di sviluppo, in sprint mensili rinnovabili.
Per Romiltec ho scelto la terza fin dal primo giorno, per due motivi tecnici:
Uno. Il time and materials premia il dev lento. Più tempo passa sul ticket, più fattura. È un incentivo perverso che si combatte solo con un PM rigoroso, e in una società zero commerciali (vedi il post precedente di questa rubrica) il PM rigoroso non c’è.
Due. Il preventivo a corpo è un disastro sui progetti software con perimetro fluido. In quindici anni nel tech ho visto tre preventivi a corpo su quattro finire in cause di scope creep, con margini erosi dalle modifiche fuori contratto. Lo evito strutturalmente.
Il prezzo fisso al mese sposta tutto il rischio di stima su Romiltec: se sbaglio le stime di velocità, perdo io. Ma in cambio ho un flusso di cassa prevedibile, contratti rinnovabili senza rinegoziare, e il dev concentrato sulla qualità del codice invece che sul cronometro.
La formula del primo preventivo (quella sbagliata)
A maggio 2023, quando ho proposto il primo preventivo a un cliente, la formula che avevo in testa era questa:
prezzo mensile = (costo lavoro mensile dev) × (1 + margine)
Dove:
– costo lavoro mensile dev = stipendio lordo + contributi + tredicesima/quattordicesima ratealizzata
– margine = 30% sopra al costo, per coprire spese generali e profitto
Esempio numerico (con cifre arrotondate per chiarezza, non sono il mio costo reale): un dev senior costa all’azienda ~5.000 € al mese fully loaded. Con margine al 30%, prezzo cliente per uno sprint full-time: ~6.500 € al mese.
Sembrava ragionevole. Era sbagliato di brutto.
I quattro errori che ho fatto
Sotto al margine del 30% si nascondevano quattro voci di costo che avevo sottostimato o ignorato del tutto. Le elenco con il fix che ho applicato dopo il terzo cliente.
Errore 1: tempo non fatturabile
Un dev senior in Romiltec non fa quaranta ore a settimana di codice produttivo per un singolo cliente. Mai. Il calcolo realistico, su un mese, è:
- Call settimanali col cliente (1-2 ore × 4 settimane): ~6 ore
- Onboarding di nuovi requisiti, scrittura di proposte tecniche, scoping di sprint successivi: ~8 ore
- Code review interna fra dev senior (mutual review tra due dev): ~6 ore
- Setup ambiente, gestione VPN, accessi, problemi infrastrutturali del cliente: ~4 ore
- Ferie/malattia ratealizzate (~22 giorni l’anno = ~13 ore al mese): ~13 ore
- Aggiornamento tecnico (lettura newsletter, prove di nuovi tool, blog): ~4 ore
Totale tempo non fatturabile: circa 40 ore al mese su 160. Il 25% del tempo del dev non è codice consegnabile. Nel margine del 30% questa voce era già mangiata, prima ancora di parlare di profitto.
Fix: il prezzo cliente parte non dal “costo lavoro × 1.3” ma dal “costo lavoro × (1 / 0.75) × 1.3”, cioè dal costo del tempo realmente fatturabile, non del tempo totale del dev.
Errore 2: il sysadmin invisibile
Per ogni cliente Romiltec serve qualcuno che gestisca gli ambienti server: setup VM, configurazione Hestia, certificati SSL, backup, monitoring, intervento in caso di alert notturno. Nei primi preventivi avevo dato per scontato che fosse “incluso” nel costo dev senior, perché ero io a farlo.
Il problema: anche se lo facevo io, il tempo che ci dedicavo era reale. Su tre clienti, il tempo settimanale di gestione sistemista era già intorno alle 4-6 ore: una mezza giornata che non compariva nel preventivo perché non l’avevo modellata.
Fix: nel costo del progetto compare una voce infrastruttura + sysadmin, calcolata come 8-12% del costo dev del progetto, indipendente dal volume di codice scritto. È un costo fisso che il cliente paga indipendentemente da quante feature consegniamo nel mese.
Errore 3: il cap di scope (mancante)
Il prezzo fisso al mese ha senso solo se il cliente capisce che lo sprint è capacità, non delivery infinita. Nei primi preventivi non avevo formalizzato questo concetto: ho passato un mese intero in cui un cliente assumeva, in buona fede, che “lo sprint costa 6.500 e tu mi consegni qualunque cosa ti chieda”.
Risultato: il dev di Romiltec ha lavorato 50 ore di overflow non fatturate, perché il cliente continuava a chiedere “una piccola cosa in più, che dici, ce la facciamo?”.
Fix: ogni contratto a prezzo fisso include il concetto di story point capacity mensile. Un dev senior consegna, in media, X story point al mese (dove la calibrazione di X dipende dalla complessità del backlog). Tutto quello che eccede passa allo sprint successivo. Niente “una piccola cosa in più” senza prezzare l’impatto sullo sprint.
Errore 4: la riserva tecnica per gli imprevisti di produzione
I bug critici in produzione, gli incident notturni, i rollback urgenti: capitano. Ho ignorato questa voce nel primo preventivo e me la sono ritrovata addosso al primo deploy infelice (un’integrazione OAuth con un SDK di terze parti che si è comportata diversamente in produzione rispetto allo staging).
Fix: il preventivo ora include una riserva tecnica implicita pari al 10% del tempo del dev per gestire imprevisti, senza fatturarla esplicitamente al cliente. È un cuscino che protegge il prezzo fisso da spostare ogni volta che capita un incidente.
La formula corretta (quella che uso da luglio 2023)
Dopo i tre clienti iniziali, ho ricalibrato la formula. Eccola:
prezzo mensile = (costo lavoro dev fully loaded)
× (1 / fatturabilità effettiva) ← errore 1, ~0.75
× (1 + quota infra/sysadmin) ← errore 2, ~+10%
× (1 + riserva tecnica imprevisti) ← errore 4, ~+10%
× (1 + margine commerciale) ← profitto vero, ~+25%
Con i numeri del dev senior fully loaded a 5.000 € (esempio chiarificatore, non i miei costi reali):
prezzo mensile = 5.000 × (1/0.75) × 1.10 × 1.10 × 1.25
≈ 5.000 × 1.33 × 1.10 × 1.10 × 1.25
≈ 10.000 €
Quasi il doppio del primo preventivo (6.500 €). La differenza non è “più margine”: è il prezzo che riflette il costo reale di consegnare delivery sostenibile, senza pagare la differenza con qualità del codice o ore di overflow. (Le cifre sopra sono esempi illustrativi, non i miei costi reali.)
La regola operativa che ne è uscita
Per evitare di rifare lo stesso errore a ogni progetto, ho condensato il calcolo in tre regole pratiche.
Regola uno: il prezzo cliente non parte mai dal “costo dev + 30%”. Parte dal tempo fatturabile reale del dev (~75% del tempo totale), e quel rapporto va corretto a monte.
Regola due: ogni progetto a prezzo fisso mensile include esplicitamente, nella proposta scritta al cliente, il cap di scope in story point. Senza cap, il prezzo fisso si trasforma in un buco nero di richieste.
Regola tre: la voce infrastruttura è separata e visibile sul preventivo. Anche se ce la gestiamo noi internamente, il cliente vede che è un costo, e capisce perché esiste. Questo evita la conversazione futura “ma chi ti ha detto di mettere quel server?”.
Il filo che voglio lasciare
Il prezzo fisso al mese è una promessa di qualità delivery, non una promessa di lavoro illimitato. La differenza fra le due cose è esattamente la differenza fra una software house bootstrap che dura nel tempo e una che brucia il team in dodici mesi. Tyler Tringas ha scritto pagine intere su questo principio applicato alle calm companies, e chiunque abbia fatto un anno di prezzo fisso senza cap te lo conferma sul campo.
Ho sbagliato la prima volta. Sto sbagliando ancora, in quantità minori, anche oggi: ogni preventivo è una stima, e ogni stima si rompe sotto carico. Quello che ho imparato in questi tre mesi è che la formula non vale solo se i numeri tornano: vale solo se la conversazione col cliente sul cosa è in scope è esplicita prima della firma. Senza quella, qualunque margine viene mangiato dallo scope creep nel primo trimestre.
Il quarto cliente è entrato a settembre 2023 con la formula corretta. La conversazione di scoping è durata trentacinque minuti in più rispetto al terzo. Sono i trentacinque minuti meglio investiti del trimestre.