Sviluppo MVP: la prima versione da mettere in mano ai clienti
Lo sviluppo di un MVP serve a sapere, con utenti veri e in poche settimane, se un prodotto software merita il resto dell’investimento. Costruiamo solo il percorso che porta l’utente al risultato per cui pagherebbe, e prima di partire fissiamo con voi il numero che dirà se proseguire.
Cosa resta fuori dalla prima versione
Resta fuori quasi tutto quello che finisce nella prima lista dei desideri. Un’agenzia che segue pratiche edilizie per conto dei geometri vuole un portale dove i geometri caricano i documenti e vedono a che punto è la loro pratica. In una settimana la lista arriva a trenta voci: firma digitale, app, notifiche, pagamenti online, statistiche per studio, ruoli per i collaboratori.
Costruirle tutte prima di sapere se i geometri abbandoneranno le email per il portale vuol dire scoprirlo dopo un anno. La prima versione ne tiene tre: il geometra carica i documenti di una pratica, ne vede lo stato, riceve una mail quando cambia. Il resto va in una colonna «dopo» del documento di progetto, così nessuno la dimentica e nessuno la costruisce adesso.
Per chi è
- Founder che devono far provare a investitori o ai primi clienti un prodotto che salva dati veri.
- Aziende che vogliono vendere come servizio uno strumento nato in casa: un foglio di calcolo, un configuratore, un’app che oggi usano solo i loro tecnici.
- Chi ha già un mockup cliccabile e deve capire se le persone lo usano anche quando c’è da inserire i propri dati.
- Responsabili di una nuova linea di business con un budget per un test, non per un prodotto completo.
Cosa include
Il taglio del perimetro
Un workshop in cui ogni voce della lista finisce da una parte o dall’altra: serve al primo utente per arrivare al risultato, oppure aspetta. Chi ha chiesto una voce rimandata sa in che posizione si trova.
Il numero che decide
Prima del codice stabiliamo cosa misurare: quanti utenti completano il percorso, quanti tornano la settimana dopo, quanti accettano di pagare. Senza questo numero un MVP diventa una versione 0.1 che non finisce mai.
Prodotto in produzione
Registrazione, il percorso principale e un pannello per voi con chi si è iscritto e cosa ha fatto. Su un dominio vostro, non su un link di prova che scade dopo un mese.
Le parti fatte a mano
Quello che per i primi venti utenti può restare manuale resta manuale: l’attivazione dell’account, l’invio di una fattura, un controllo sui dati. Si automatizza quando i numeri dicono che ne vale la pena.
Codice che si tiene
Lo stesso stack dei nostri prodotti in produzione, React e .NET, con test sulle parti che toccano i dati. Se l’MVP regge, la versione successiva parte da lì e non da un foglio bianco.
Come lo costruiamo
Cinque passaggi, dal workshop iniziale alla decisione su cosa fare dopo.
Workshop sul perimetro
Con voi e, se si riesce, con due futuri utenti: chi sono, cosa fanno oggi senza il prodotto, cosa li convincerebbe a pagarlo.
Schermate cliccabili
Il percorso principale disegnato in Figma e fatto provare a quelle stesse persone. Di solito qui si toglie ancora qualcosa.
Sviluppo a cicli di due settimane
A ogni ciclo una versione funzionante su un ambiente di collaudo, che potete aprire e far vedere a chi volete.
Primi utenti
Il prodotto va online per un gruppo ristretto. Nelle prime settimane guardiamo insieme dove gli utenti si fermano e dove tornano.
Decisione
Con il numero fissato all’inizio si sceglie: proseguire con la colonna «dopo», cambiare direzione, oppure fermarsi avendo speso poco.
Con cosa si collega
Un MVP si collega al minimo che serve per il test. Pagamenti con Stripe quando la domanda è proprio se qualcuno paga, le email automatiche di benvenuto e di conferma, uno strumento di analisi d’uso per vedere in quale schermata le persone abbandonano.
Le integrazioni con l’ERP di un cliente grande o con i dati delle macchine di solito restano fuori dalla prima versione: un’esportazione in CSV fatta bene basta per capire se il prodotto serve. Quando l’MVP deve diventare un prodotto venduto a molte aziende in abbonamento cambiano le priorità, e ne parliamo nella pagina sullo sviluppo SaaS.
Tempi e costi
Il costo di un MVP dipende quasi tutto da quanto si taglia nel primo workshop: due ruoli utente invece di quattro, un formato di esportazione invece di tre. Ogni ruolo in più porta permessi, schermate e casi da provare; ogni integrazione porta un sistema esterno da cui dipendere già nella prima versione.
La durata si fissa insieme al perimetro, nel workshop. Se il test ha una data, per esempio una fiera o il primo cliente pronto a provarlo, si parte da quella e si taglia fino a starci dentro.
Domande frequenti
Parliamone in 30 minuti
Raccontateci il processo e cosa non funziona: vi diciamo se e come lo risolveremmo, con tempi e costi indicativi.
Matteo Budriesi
CEO e co-founder di Webion, la software house di Modena che sviluppa software su misura e agenti AI per le aziende.
Aggiornato il 30/10/2026