Architetture Enterprise su progetti Early Stage
Erano le 22:30 di un martedì qualsiasi quando mi è arrivato quel messaggio su WhatsApp.
Un founder che conoscevo di vista, solitamente calmo e pragmatico, sembrava sull'orlo di una crisi di nervi.
"Manuel, ti prego, dimmi che sto sbagliando io. Mi hanno appena mandato il preventivo finale per la piattaforma. Dicono che dobbiamo rifare tutto da zero. 120k. 6 mesi di roadmap. Se firmo questo, chiudo tra un anno."
Mi sono fatto girare il PDF. Ho aperto il file. E ho capito subito che non stava sbagliando lui.
Quello che avevo davanti agli occhi non era un preventivo tecnico. Era un crimine contro l'agilità.
L'Anatomia del Disastro
La startup in questione era in una fase delicata: avevano trovato il Product-Market Fit, stavano iniziando a scalare, e il vecchio MVP in PHP iniziava a scricchiolare.
La richiesta era semplice: rifattorizzare per scalare.
La risposta dell'agenzia "top tier" a cui si erano rivolti? Un'architettura a microservizi su Kubernetes, con eventi asincroni gestiti via Kafka, tre diversi database (SQL, NoSQL e TimeSeries), e un frontend micro-frontend federato.
Sulla carta? Bellissimo. Sembrava l'architettura di Netflix o Uber. Nella realtà? Era un Boeing 747 comprato per andare a comprare il prosciutto dal salumiere sotto casa.
La Trappola della Complessità Enterprise
Ho chiamato il founder immediatamente.
"Ascolta," gli ho detto, "non firmare nulla."
Il problema non era solo il costo (120.000€ per una startup seed sono un'enormità). Il problema vero, quello che avrebbe ucciso l'azienda, era la complessità operativa.
Gli stavano vendendo una soluzione che richiedeva un team di 5 DevOps solo per essere mantenuta accesa. Una modifica che oggi richiedeva 2 ore, con quella nuova struttura ne avrebbe richieste 20 tra coordinamento, deploy distribuiti e test di integrazione.
Stavano comprando vincoli. Stavano pagando per risolvere problemi che forse avrebbero avuto tra 5 anni, ignorando i problemi che avevano oggi.
L'Intervento: Chirurgia d'Urgenza
Nei giorni successivi ho fatto un deep dive nella loro codebase attuale e nei requisiti di business.
Ho organizzato una call con il CTO dell'agenzia proponente. È stato imbarazzante. Alla mia domanda "Perché avete proposto Kafka per un sistema che gestisce 500 ordini al giorno?", la risposta è stata un vago "Per garantire la scalabilità futura e il disaccoppiamento".
Traduzione: "Perché fa figo sul curriculum dei nostri sviluppatori e ci permette di fatturare il triplo delle ore."
Ho presentato al founder un piano alternativo.
- Niente riscrittura totale: Il core in PHP funzionava. Andava solo pulito.
- Estrazione mirata: Abbiamo isolato solo le due funzionalità che causavano colli di bottiglia (la gestione dell'inventario real-time e le notifiche) spostandole su due semplici servizi serverless in Node.js.
- Infrastruttura noiosa: Niente Kubernetes. Un semplice PaaS gestito (tipo Vercel o Heroku) che scala da solo senza bisogno di assumere un ingegnere sistemista.
- Refactoring progressivo: Invece di fermare lo sviluppo per 6 mesi, avremmo migliorato il codice esistente mentre rilasciavamo nuove feature.
Il Risultato: Matematica, non Magia
Il nuovo piano?
- Costo stimato: 35-40k (invece di 120k).
- Tempo di rilascio: 2 mesi per la stabilizzazione critica (invece di 6 mesi di buio totale).
- Team richiesto: I suoi attuali sviluppatori, più un senior part-time per la supervisione (invece di un team esterno dedicato).
Il founder ha stracciato il preventivo da 120k. Hanno implementato la mia strategia.
Oggi, a distanza di un anno, gestiscono il triplo del traffico con la stessa infrastruttura "noiosa". Hanno usato gli 80.000€ risparmiati per assumere un Head of Sales e due sviluppatori junior che stanno crescendo internamente.
La Lezione
Se sei un founder, ricorda questo: La complessità tecnica non è un asset. È un debito che contrai con il futuro.
Agenzie e consulenti spesso hanno l'incentivo opposto al tuo: loro guadagnano sulla complessità, tu guadagni sulla velocità e sulla semplicità.
Non hai bisogno dell'architettura di Google. Hai bisogno di un sistema che funzioni, che costi poco mantenere e che ti permetta di cambiare direzione domani mattina se il mercato lo richiede.
Il mio lavoro non è scrivere codice. Il mio lavoro è impedirti di comprare un aereo quando ti serve solo una bicicletta elettrica. E a volte, questo significa farti risparmiare 100.000€ con una sola conversazione.