In pratica, una proof of concept (PoC) serve a capire se un’idea si può costruire: prova che una tecnologia funziona. Un MVP serve a capire se si deve costruire: è una prima versione del prodotto, messa in mano a persone vere per vedere se la usano. Per validare un’idea sul mercato serve l’MVP; la PoC, quando il dubbio è tecnico.
Le due domande sono il modo in cui usiamo queste parole a dotenv, e si appoggiano su due riferimenti pubblici: la scala della maturità tecnologica usata da NASA e dalla Commissione europea, dove la proof of concept ha un posto preciso, e la definizione di MVP data da Eric Ries nel 2009.
Che cos’è una proof of concept?
È una prova sperimentale che una tecnologia può funzionare. Il riferimento più usato è la scala dei Technology Readiness Levels (TRL) della NASA, nove livelli dal TRL 1 al TRL 9. Al TRL 3 servono studi analitici e di laboratorio per vedere se una tecnologia è praticabile, e la NASA scrive: «Often during TRL 3, a proof-of-concept model is constructed». Spesso, a quel livello, si costruisce un modello di proof of concept.
La Commissione europea usa la stessa scala negli allegati generali del programma di lavoro Horizon Europe 2026-2027, adottato con la decisione C(2025) 8493 dell’11 dicembre 2025. Lì il TRL 3 si chiama «Experimental proof of concept», prova di concetto sperimentale. Il TRL 9 è «Actual system proven in an operational environment», un sistema provato nell’ambiente in cui deve lavorare.
Nel software la domanda di una PoC di solito è concreta: se un algoritmo regge i dati veri, se due sistemi riescono a parlarsi, se un’integrazione con un sistema che esiste già si può fare, e con quali limiti.
Una proof of concept è un prototipo?
Nella scala della NASA sono due livelli diversi. La proof of concept sta al TRL 3, un prototipo pienamente funzionante arriva al TRL 6, e una tecnologia si dice TRL 9 solo dopo aver funzionato in una missione reale. Negli allegati di Horizon Europe il TRL 7 è la «System prototype demonstration in an operational environment», la dimostrazione di un prototipo di sistema nell’ambiente operativo.
Con un fornitore conviene dire quale delle due si sta chiedendo: la prima prova una tecnologia, il secondo mostra un sistema che funziona.
Che cos’è un MVP?
È la versione di un prodotto nuovo che serve a imparare il più possibile sui clienti con il minimo sforzo. La definizione è di Eric Ries, nel post «Minimum Viable Product: a guide» del 3 agosto 2009: «the minimum viable product is that version of a new product which allows a team to collect the maximum amount of validated learning about customers with the least effort».
La parola che conta è validated learning, apprendimento convalidato: un MVP si giudica da quanto fa imparare sui clienti. Nello stesso post Ries avverte che l’MVP, «despite the name, is not about creating minimal products», e che la definizione chiede giudizio: quale MVP abbia senso dipende dal contesto.
Che differenza c’è tra MVP e proof of concept?
Rispondono a due domande diverse, e il metodo Lean Startup le tiene separate. Il sito del metodo descrive ogni startup come un grande esperimento che cerca di rispondere a una domanda, e la domanda «is not “Can this product be built?” Instead, the questions are “Should this product be built?” and “Can we build a sustainable business around this set of products and services?”». Cioè se il prodotto si deve costruire, e se ci si può costruire sopra un’attività che sta in piedi. Il primo passo, secondo lo stesso sito, è capire il problema da risolvere; poi si sviluppa un MVP «to begin the process of learning as quickly as possible».
Leggere «si può costruire?» come la domanda della PoC e «si deve costruire?» come quella dell’MVP è una lettura nostra: il sito Lean Startup parla di startup, la scala TRL di tecnologie. Messe accanto, le due cose si ordinano così:
| Proof of concept | MVP | |
|---|---|---|
| La domanda | Si può costruire? | Si deve costruire? |
| Che cosa prova | Che una tecnologia è praticabile | Che cosa si impara sui clienti |
| Dove sta | TRL 3 nella scala di NASA e Horizon Europe | Nel metodo Lean Startup, dopo aver capito il problema da risolvere |
Per validare un’idea serve una PoC o un MVP?
Dipende dal dubbio che l’idea porta con sé: se è tecnico una PoC, se è il mercato un MVP. I dati sulle startup che chiudono dicono quale dei due dubbi pesa di più.
CB Insights, nel report del 5 marzo 2026, ha analizzato post-mortem pubblici, interviste ai fondatori e annunci di chiusura di 431 startup finanziate da venture capital che hanno chiuso dal 2023. Le percentuali che seguono si riferiscono alle startup di cui si conoscono i motivi, e superano 100 perché molte ne citano più di uno.
In cima alla lista c’è la fine dei capitali, «ran out of capital», con il 70%, e il report la considera quasi sempre la causa finale. Le cause che spiegano perché i capitali sono finiti sono:
- un product-market fit scarso, 43%;
- il tempismo sbagliato, 29%;
- un’economia unitaria non sostenibile, 19%.
Secondo lo stesso report, due terzi dei fallimenti per product-market fit riguardano aziende in fase iniziale che non hanno mai trovato un mercato, e fra l’ultimo round di finanziamento e la chiusura passano in mediana 22 mesi.
Un product-market fit scarso è un rischio di mercato, e una prova di fattibilità tecnica non lo misura. Il campione è di startup finanziate da venture capital e la fonte non dice di quali paesi siano: per un’idea finanziata in un altro modo i numeri vanno presi come un’indicazione.
Se la tecnologia è nuova si fanno tutte e due, prima la PoC e poi l’MVP. Se è nota, come per un’app o un portale, si può partire dall’MVP.
Serve un MVP se il prodotto è già deciso?
Di solito no: se la domanda «si deve costruire?» ha già una risposta, serve una squadra che costruisca quello che è stato deciso. La pagina del nostro prodotto lo dice così: «Allora è sviluppo su misura, con un preventivo normale.»
Quanto tempo serve per un MVP?
Dipende da che cosa deve far imparare. Nel post del 2009 Ries racconta che l’MVP originale di IMVU richiese sei mesi per arrivare sul mercato. In un altro caso la squadra passò due settimane a costruire una funzione che nessuno voleva, e un semplice smoke test con AdWords l’avrebbe rivelato prima.
Il tempo si può anche fissare prima di cominciare. From idea to business è il prodotto di dotenv per portare un’idea a un prodotto che qualcuno usa, in otto settimane dalla firma. La data non si sposta per una richiesta nuova né per un ritardo, e le stesse persone ci lavorano dal primo giorno all’ultimo. Ogni venerdì si decide insieme cosa entra e cosa esce: cambia il contenuto, e la scadenza resta quella. Alla fine c’è un dossier per decidere se finanziare la fase successiva. Se si decide di fermarsi, codice, documentazione, dati raccolti e analisi restano vostri.
Dentro dotenv abbiamo fondato Neurally, un’azienda di AI. È l’unica volta in cui il committente eravamo noi, con l’idea e il rischio di scoprire che non stava in piedi.