MVP Enterprise: Come bruciare 250k prima del lancio
Una startup early-stage mi racconta che, dopo 6 mesi di sviluppo, non è ancora andata live.
"Stiamo costruendo una piattaforma solida, perché quando scalerà deve reggere migliaia di utenti", dicono.
Poi guardo l'architettura.
Vedo Kubernetes, microservizi separati, Cloud Run, BigQuery, Pub/Sub, autenticazione custom, CDN multiple, pipeline CI/CD estreme…
Tutto questo per un prodotto che NON aveva ancora un primo cliente pagante.
Il team stava letteralmente costruendo un prodotto enterprise per una startup che non aveva ancora validato nulla.
Alla domanda "perché così complesso?", la risposta è sempre la stessa: "Così siamo pronti quando scalerà."
La verità è che non scalerà mai se ci metti 6 mesi per costruire l'MVP.
Il Costo della "Perfezione" Prematura
Risultato finale:
- 250k di burn rate (stipendi + consulenze + cloud)
- 6 mesi di ritardo sul go-to-market
- nessun cliente
- nessun feedback reale
- team scoraggiato
- prodotto da rifare da zero
L'errore non era tecnico. Era CULTURALE.
Hanno progettato l'MVP come il prodotto finale.
Cosa Dovrebbe Essere un MVP
Un MVP (Minimum Viable Product) dovrebbe fare il contrario:
- costare poco
- essere veloce da creare
- servire solo a validare una singola ipotesi
- pensato per essere scalabile senza dover rifare tutto da capo
Per ciò che volevano fare bastava:
- Next.js
- Auth gestita da un provider (es. Auth0, Clerk)
- Un database strutturato bene (Postgres gestito)
- Un paio di funzioni cloud
30€/mese di infrastruttura.
Se fossi entrato da subito avrei tagliato il 70% dei costi e portato la startup live in 4 settimane.
Invece, hanno speso un quarto di milione per costruire ciò che non serviva.
E quando hanno finalmente lanciato… il mercato non lo voleva.
La Lezione
Non costruire una cattedrale se devi solo testare se la gente vuole pregare. Costruisci una tenda. Se si riempie, allora pensi alle fondamenta della cattedrale.
La scalabilità è un problema che ti devi guadagnare. Non comprarla in anticipo.