Un MVP ha un solo scopo: verificare che qualcuno sia disposto a pagare. Tutto ciò che non serve a questa verifica è tempo perso. Ma tra «andare veloci» e «costruire alla rinfusa» c'è un confine, e si trova in punti precisi.
Ciò che si può legittimamente sbrigare
All'inizio queste scorciatoie sono sane:
- Il back office. Un'interfaccia di amministrazione brutta va benissimo per un anno. Nessuno all'esterno la vede.
- L'automazione dei casi rari. Se tre clienti al mese hanno bisogno di un trattamento particolare, fatelo a mano. Automatizzare troppo presto congela una regola di business che sta per cambiare.
- La scalabilità. Un singolo server regge migliaia di utenti. Progettare per un milione quando se ne hanno zero è la forma più costosa di procrastinazione.
- Un design system completo. Cinque componenti fatti bene bastano all'inizio.
Le tre decisioni irreversibili
Tre scelte, invece, strutturano tutto il resto. Rimandarle costa una riscrittura.
1. Il modello dei dati
È il punto di non ritorno. Se partite con un utente che appartiene a una sola organizzazione, e sei mesi dopo un cliente vuole gestire tre filiali, la migrazione tocca ogni query dell'applicazione.
Ponete la domanda il primo giorno: a chi appartiene un dato? A un utente, a un team, a un'organizzazione? Anche se all'inizio vendete solo a liberi professionisti, un identificativo di organizzazione presente fin da subito costa quasi nulla ed evita il peggio.
2. Autenticazione e permessi
Aggiungere ruoli a posteriori significa rileggere ogni controller chiedendosi «chi ha il diritto di fare questo?». Anche uno strato di autorizzazione minimo (due ruoli bastano) introduce la disciplina e il punto in cui definire le regole.
3. I test sul percorso critico
Non una copertura del 100 %, sarebbe assurdo a questo stadio. Ma registrazione, pagamento e azione principale del prodotto devono essere coperti. Sono i tre percorsi il cui guasto costa clienti, e quelli che modificherete più spesso.
Il momento di svolta
Il passaggio dall'MVP al prodotto si gioca raramente sulla tecnica. Si gioca quando il supporto comincia a prendere più tempo dello sviluppo.
I segnali da sorvegliare:
- rispondete più volte a settimana alla stessa domanda;
- correggete dati a mano nel database;
- una nuova funzionalità rompe sistematicamente qualcosa di vecchio.
Il primo segnale richiede documentazione o un cambio di interfaccia. Il secondo, uno strumento di amministrazione. Il terzo, test: ed è il più urgente, perché rallenta tutto il resto.
In pratica
Un MVP onesto si costruisce in sei-dieci settimane. Il prodotto che segue viene sviluppato continuamente, per incrementi brevi, con utenti che vedono ogni consegna.
Ciò che distingue i progetti che durano non è quasi mai la raffinatezza tecnica di partenza. È aver avuto, fin dal primo giorno, un modello dei dati che rispecchia onestamente il mestiere.
