La Trappola del Cliente Enterprise: Custom vs Core
Una startup con cui ho parlato gestiva una piattaforma B2B per clienti enterprise. Erano in una fase "felice": primi contratti firmati, primi clienti grossi, prime richieste personalizzate.
L'istinto del team era semplice: "Per questo cliente grande facciamo una variante dedicata, è un grosso contratto, ne vale la pena."
Tradotto in pratica: fork del codice "temporaneo" per il cliente A, condizioni speciali per il cliente B, piccole deviazioni per il cliente C.
Il Miraggio del Fatturato Immediato
Nessuno vedeva costi immediati: in quel momento gli altri clienti erano pochi, la codebase sembrava ancora gestibile, i dev erano gasati dall'idea di "chiudere grandi nomi".
Quando entro io, faccio una delle domande che nessuno ama sentirsi fare:
"Ok, tra 12 mesi, quando avrete 8–10 clienti enterprise tutti con richieste diverse… chi cazzo mantiene 10 varianti del prodotto?"
Metto sul tavolo il film completo:
- ogni "piccola variazione" oggi significa una nuova superficie di bug domani
- ogni feature dovrà essere testata in 5 contesti diversi
- ogni dev dovrà tenere in testa eccezioni, flag, casi particolari
- ogni nuovo cliente importante vorrà "la sua versione"
- e dopo un po' nessuno saprà più cosa è standard e cosa no
Il Conto che Nessuno Aveva Fatto
Nessuno aveva fatto questo conto.
Allora facciamo insieme una stima:
- 1 ora al giorno persa per dev in "friction" e contesto
- 4 dev → 4 ore al giorno
- 4 ore _ 5 giorni _ 52 settimane = oltre 1000 ore/anno solo di attrito
Non sto parlando di nuove feature. Sto parlando di tempo buttato tra:
- capire quale variante toccare
- non rompere il cliente X cambiando qualcosa per il cliente Y
- fix "veloci" che generano altri bug
- allineamenti interni continui
A quel punto gli dico: "State costruendo una prigione di varianti. Ogni cliente enterprise che entra, oggi sembra un successo. Tra un anno sarà un nuovo ostacolo a qualsiasi cambiamento."
La Soluzione: Disciplina Architetturale
La soluzione non è stata "dire di no ai clienti", ma cambiare approccio:
- Progettare un unico core prodotto solido.
- Prevedere estensioni configurabili invece di fork.
- Stabilire subito cosa è "prodotto" e cosa è "progetto su misura".
- Mettere dei limiti chiari ai compromessi commerciali.
Su carta non abbiamo "risparmiato 50k in quel momento".
Ma abbiamo evitato che:
- 4 dev bruciassero un terzo del loro tempo annuo a inseguire varianti.
- Ogni cambiamento importante richiedesse settimane invece di giorni.
- Il prodotto diventasse ingestibile proprio quando la crescita iniziava.
- Servisse un "mega refactor" tra 18 mesi, nel momento peggiore possibile.
La Lezione
Il valore reale dell'intervento è questo: togliere dal tavolo una bomba a orologeria che nessuno vedeva, prima che esplodesse in forma di burnout, ritardi cronici e perdita di opportunità.
Se il tuo commerciale vende "sì" a tutti, il tuo team tecnico finirà per non riuscire a consegnare nulla a nessuno.