Vuoi un MVP in 90 giorni che non sia una slide: cosa si può (davvero) consegnare e cosa stai sognando

MVP non è il brand e tre schermate su Figma

Sei un founder, hai un’idea, e ti hanno detto la parola magica: MVP. «Facciamo un MVP in 90 giorni e lo mettiamo sul mercato.» Il problema è che “MVP” vuol dire cose molto diverse a seconda di chi la pronuncia, e la distanza tra queste versioni è la distanza tra un prodotto che valida la tua idea e una fattura per delle slide. Prima di firmare qualsiasi cosa, vale la pena mettere a fuoco cosa sta davvero dentro un MVP software in 90 giorni — e cosa, invece, stai sognando.

Cominciamo da cosa un MVP non è. Non è il logo, il brand, la palette di colori e tre schermate disegnate su Figma. Quello è un mockup: bellissimo da mostrare agli investitori, inutile da usare, perché non funziona — è un disegno. Non è nemmeno un prototipo cliccabile dove “sembra” che le cose succedano ma sotto non c’è niente. Un MVP — Minimum Viable Product, prodotto minimo funzionante — è software vero: qualcosa che una persona reale usa, sui dati veri, per fare davvero la cosa. La parola chiave è viable, funzionante: se non funziona, non è un MVP, è una presentazione.

Questa confusione non è innocente: è dove si bruciano tempo e soldi dei founder. Paghi pensando di avere un prodotto da testare sul mercato, e ti ritrovi con delle schermate belle che non fanno niente, e la scoperta che “ora serve il vero sviluppo” — cioè che il grosso deve ancora cominciare. Questo articolo serve a darti aspettative oneste: cosa ci sta in 90 giorni, cosa no, perché il frontend senza backend è un tradimento, e cosa succede il giorno 91. Così sai cosa stai comprando, e riconosci chi ti vende un sogno da chi ti costruisce un prodotto.

Mockup, prototipo, MVP, prodotto: quattro cose diverse

Gran parte dei malintesi (e delle fregature) nasce dal chiamare con lo stesso nome cose diverse. Vale la pena mettere ordine, perché sapere di cosa parli ti fa capire cosa stai comprando e cosa stai pagando.

Il mockup è un disegno: schermate statiche, belle, fatte con uno strumento di design. Serve a decidere l’aspetto e a mostrare l’idea. Non funziona: non salva niente, non fa niente. Costa relativamente poco ed è utile, ma se qualcuno te lo vende come “l’MVP”, ti sta ingannando.

Il prototipo è un mockup che si può cliccare: passi da una schermata all’altra e sembra che le cose succedano, ma sotto non c’è logica né dati veri. Serve a testare il percorso dell’utente e a fare colpo in una presentazione. È ancora un disegno animato, non software: nessun dato reale, nessuna azione vera.

L’MVP è software vero, minimo ma funzionante: un flusso completo che una persona usa sui dati veri, con utenti e logica sotto. È la prima cosa dell’elenco che funziona davvero — e per questo costa di più del mockup e del prototipo, perché sotto la superficie c’è il lavoro invisibile (backend, dati, logica). È la differenza tra un prototipo che sembra e un prodotto che è.

Il prodotto completo è l’MVP cresciuto: tutti i flussi, i casi limite, le integrazioni, la scala. È mesi o anni di lavoro, e ci si arriva dopo aver validato l’idea con l’MVP, non prima.

La confusione costosa è tra il prototipo (un disegno che sembra funzionare) e l’MVP (software che funziona). Molti founder pagano pensando all’MVP e ricevono un prototipo, scoprendo poi che “il vero sviluppo” deve ancora cominciare. Quando parli di budget e tempi, chiarisci quale di questi quattro stai comprando: la parola “MVP” da sola non basta a proteggerti.

Cosa sta in 90 giorni: un flusso, utenti veri, dati veri

Novanta giorni sono pochi e sono tanti: bastano per un MVP vero, se sai cosa metterci e cosa lasciare fuori. La regola d’oro è: un flusso, fatto bene, funzionante, con utenti veri e dati veri. Non dieci cose a metà: una cosa che funziona davvero.

Cosa vuol dire in concreto “un flusso”? Significa scegliere il cuore della tua idea — l’azione centrale che risolve il problema del tuo utente — e costruire quella, completa, dall’inizio alla fine. Se la tua idea è un marketplace, il flusso non è “tutto il marketplace”: è, per esempio, “un utente pubblica una cosa, un altro la trova e la prenota”. Se è uno strumento gestionale, il flusso è la sequenza principale che l’utente fa ogni giorno. Tutto il resto — le mille funzioni accessorie, i casi limite, le sezioni secondarie — si lascia fuori dai 90 giorni.

E questo flusso dev’essere vero su due dimensioni. Utenti veri: c’è un login, ci sono ruoli, le persone entrano ed è davvero loro — non “un utente finto per la demo”. Dati veri: il sistema lavora sui dati reali (o realistici), che vengono da qualche parte di preciso, non su un esempio incollato. Un MVP con utenti veri e dati veri è qualcosa che puoi mettere in mano a persone vere e vedere se la tua idea regge. È esattamente il tipo di prodotto minimo di cui parlo per chi vuole productizzare un’idea e non fermarsi alla demo: piccolo, ma vero — un prodotto in miniatura, non una dimostrazione.

Cosa NON sta in 90 giorni

Altrettanto importante è sapere cosa non ci sta, perché è quello che i founder sognano e che fa saltare i tempi (e il budget). Se qualcuno ti promette queste cose in 90 giorni, o non le farà, o farà una versione finta.

Il marketplace completo. “Facciamo Airbnb del settore X” in 90 giorni non si fa. Un marketplace maturo è due lati (domanda e offerta), pagamenti, recensioni, ricerca, gestione dispute, moderazione, notifiche… In 90 giorni ci sta un flusso di quel marketplace, per validare l’idea centrale, non l’intera piattaforma.

L’AI magica. “E poi ci mettiamo l’AI che fa tutto.” L’AI seria, integrata bene sui dati veri con gestione dell’errore, è un progetto in sé; buttarla in un MVP di 90 giorni come se fosse un ingrediente gratis è la strada per un PoC che finisce nel cassetto. In 90 giorni l’AI può fare un pezzo delimitato e verificato, non “tutto magicamente”.

Dieci integrazioni. “Si collega al gestionale, a Stripe, a Salesforce, a WhatsApp, alle spedizioni…” Ogni integrazione seria è lavoro vero, con i suoi casi limite. In 90 giorni ci stanno una, forse due integrazioni essenziali al flusso, non un ecosistema.

Tutti i casi limite. L’MVP gestisce il caso normale, quello che capita l’80% delle volte. I casi strani, le eccezioni rare, gli scenari particolari si affrontano dopo, quando hai validato che l’idea di base funziona. Volerli tutti subito è il modo per non consegnare niente.

In 90 giorni ci sta	In 90 giorni NON ci sta
Un flusso centrale, completo e funzionante	La piattaforma completa con tutte le funzioni
Utenti veri (login, ruoli)	Dieci integrazioni con sistemi esterni
Dati veri da una fonte precisa	“L’AI che fa tutto”
Una, forse due integrazioni essenziali	Tutti i casi limite ed eccezioni
Il caso normale, fatto bene	Il marketplace/ecosistema maturo

La disciplina di tagliare — decidere cosa NON fare nei 90 giorni — è la competenza che distingue chi consegna un MVP vero da chi ti fa sognare e poi sfora. Un buon partner ti dice “questo sì, questo no, questo dopo”, non “sì a tutto”.

Frontend senza backend: il tradimento

C’è un modo specifico in cui i founder vengono traditi, e vale la pena nominarlo perché è frequente: ti consegnano un frontend senza backend. Cioè le schermate — belle, cliccabili, che sembrano funzionare — ma sotto non c’è la logica, i dati non si salvano davvero, le azioni non fanno succedere niente di reale. È un guscio: sembra un prodotto, è un disegno animato.

Perché succede? Perché il frontend si vede e il backend no. Un fornitore che vuole impressionarti in fretta (o che sa fare solo la facciata) ti mostra schermate meravigliose, tu sei contento, e la parte difficile e invisibile — il backend, i dati, la logica — resta indietro o non c’è. Poi provi a usarlo davvero, scopri che “non salva”, che “quel pulsante non fa niente”, che i dati spariscono, e ti dicono “eh, quello è il prossimo step”. Hai pagato per un prodotto e hai una demo cliccabile.

È lo stesso tradimento del sito vetrina venduto come prodotto: la facciata c’è, lo stato no. Per un MVP la regola è netta: deve funzionare per davvero, non sembrare che funzioni. Meno schermate ma vere, che salvano, che tengono lo stato, che fanno succedere le cose — non tante schermate belle e vuote. Quando valuti un MVP in corso, la domanda è: “posso usarlo davvero, i dati restano, le azioni hanno effetto?”. Se la risposta è “quasi”, stai guardando un frontend senza backend.

Dati: se non sai la fonte, non c’è MVP

Un punto che i founder sottovalutano sempre: i dati. Un MVP lavora su dati, e la prima domanda seria non è “che schermate”, è “da dove vengono i dati e in che stato sono”. Se la tua idea ha bisogno di dati (e quasi tutte ce l’hanno) e non sai da dove arrivano, non hai ancora un MVP: hai un’idea con un buco al centro.

Facciamo esempi. Il tuo prodotto confronta prezzi? Da dove prendi i prezzi, e sono affidabili, aggiornati, ottenibili? Aggrega informazioni? Da quali fonti, e hai il diritto di usarle? Lavora sui dati del cliente? In che formato sono, quanto sono sporchi, chi te li dà? La fonte dei dati è spesso il vero collo di bottiglia di un MVP, molto più delle schermate: puoi avere l’interfaccia più bella del mondo, ma se i dati che deve mostrare non ci sono o sono un pantano, non funziona niente.

Per questo un partner serio, prima di parlare di schermate, ti chiede dei dati: dove stanno, in che stato, chi li possiede, come si ottengono. Se chi ti propone l’MVP salta questa domanda e parte dal design, è un segnale d’allarme — sta costruendo la facciata prima di sapere se ci sono le fondamenta. È lo stesso principio che vale per ogni prodotto dati serio: sotto ogni interfaccia c’è uno strato di dati, e se quello non regge, l’interfaccia è teatro. Se non sai la fonte dei dati, non c’è MVP: c’è un rischio non affrontato.

Come si lavora, settimana per settimana

Un buon progetto MVP non è una scatola nera in cui butti soldi e dopo 90 giorni esce qualcosa: è un percorso visibile, settimana per settimana, dove vedi crescere il prodotto e puoi correggere la rotta. Questo ritmo è anche la tua protezione: se vedi qualcosa ogni settimana, ti accorgi in tempo se sta andando storto, invece di scoprirlo alla fine.

Grosso modo, un ritmo settimanale sano assomiglia a questo. Le prime settimane non sono di codice: sono di messa a fuoco — quale flusso esatto, quali utenti, da dove vengono i dati, cosa sta dentro e cosa fuori. Saltare questa fase è la causa numero uno degli MVP che sforano. Poi si entra nella costruzione, e da lì ogni settimana dovresti vedere qualcosa di concreto crescere: prima lo scheletro del flusso, poi i pezzi che si riempiono, poi il flusso che funziona end-to-end sui dati veri. Verso la fine, il collaudo con utenti veri, che fa emergere gli aggiustamenti prima del lancio.

Il segnale di un progetto sano è che ogni settimana c’è qualcosa da vedere e provare, e una conversazione onesta su cosa è fatto, cosa manca, cosa va tagliato per restare nei tempi. Il segnale di un progetto malato è il silenzio: “stiamo lavorando”, per settimane, senza niente da mostrare, fino a una consegna finale che o non arriva o non è quello che pensavi. Pretendi la visibilità settimanale: è normale, è sana, ed è come ti accorgi in tempo se serve correggere. Vale per un MVP la stessa disciplina di collaudo incrementale di ogni prodotto che va validato con utenti veri.

Budget: forchette, non un numero magico

Parliamo di soldi con onestà. Un MVP serio ha un costo, e chi ti dà un numero magico preciso senza aver capito il tuo flusso e i tuoi dati o sta indovinando o ti sta agganciando con un prezzo che poi crescerà. Il modo onesto di parlare di budget è a forchette, legate a cosa determina il costo.

Cosa fa variare il budget di un MVP? La complessità del flusso (quanti passaggi, quanta logica), lo stato dei dati (una fonte pulita e accessibile costa poco da integrare, un pantano costa molto), il numero di integrazioni essenziali, e quanto è definita l’idea (un’idea chiara si costruisce dritta, un’idea confusa fa perdere tempo in ripensamenti). Un MVP focalizzato su un flusso, con dati accessibili e un paio di integrazioni, sta in una forchetta; lo stesso “MVP” ma con dati da ripulire e cinque integrazioni sta in un’altra, più alta.

La cosa importante, come founder, è ragionare sul budget in rapporto a cosa ti serve: l’MVP serve a validare l’idea spendendo il meno possibile per scoprire se funziona, non a costruire l’azienda intera. Se il budget che ti propongono è quello di un prodotto completo, ti stanno vendendo troppo; se è sospettosamente basso, probabilmente è un frontend senza backend o un mockup. La forchetta giusta è quella che ti compra un flusso vero, funzionante, testabile — abbastanza per sapere se vale la pena continuare. Su come valutare cosa stai comprando quando commissioni uno sviluppo, e come non farti agganciare da un numero magico, vale tutto quello che dico nella guida a comprare software su misura.

Cosa succede al giorno 91

Ecco la domanda che pochi si fanno e che invece è cruciale: cosa succede il giorno dopo la consegna? Perché un MVP non è la fine, è l’inizio. Il giorno 91 hai un prodotto minimo funzionante in mano, e comincia la parte vera: metterlo davanti agli utenti, imparare, decidere se e come continuare.

Ci sono, sostanzialmente, tre esiti possibili al giorno 91, e un buon MVP li rende tutti gestibili. Funziona e cresci: gli utenti lo usano, l’idea regge, e allora si costruisce il flusso successivo, poi il prossimo — il prodotto si allarga a strati, sulla base di ciò che hai imparato. Funziona ma va corretto: gli utenti ti dicono cose che non avevi previsto, e allora si aggiusta il flusso prima di allargare — ed è oro, perché l’hai scoperto con un MVP economico e non con un prodotto completo costoso. Non funziona: l’idea, messa alla prova con utenti veri, non regge come pensavi — e anche questo è un successo dell’MVP, perché l’hai scoperto spendendo 90 giorni invece di due anni e tutto il budget.

Perché tutti e tre gli esiti siano gestibili, però, il giorno 91 devono essere vere due cose: che il codice e i dati siano tuoi (puoi continuare con chi vuoi, non sei ostaggio), e che ci sia un accordo su come si prosegue (chi mantiene, chi sviluppa il prossimo pezzo, a che ritmo). Un MVP consegnato senza pensare al giorno 91 — codice che non è tuo, nessun piano per il dopo — è un vicolo cieco anche quando funziona. Il giorno 91 va progettato insieme al giorno 1.

Un caso tipo: dal sogno al flusso che gira

Un profilo tipico, architetturale, senza nomi. Un founder arriva con un’idea ambiziosa — una piattaforma con molte funzioni, due tipi di utente, pagamenti, AI, integrazioni — e la vuole “in 90 giorni per andare sul mercato”. Aveva già in mano dei mockup bellissimi fatti da un designer: schermate curate che sembravano un prodotto finito. Il malinteso era proprio lì: pensava di essere a metà strada, ed era all’inizio, perché sotto quelle schermate non c’era niente.

Cosa si è fatto. Prima la conversazione scomoda ma necessaria: cosa sta in 90 giorni e cosa no. Si è isolato il flusso centrale — l’azione che risolveva il vero problema dell’utente — e si è deciso di costruire solo quello, completo e funzionante, rimandando tutto il resto. Si è affrontata subito la domanda dei dati (da dove venivano, in che stato), che era il vero rischio nascosto. E si è lavorato a ritmo settimanale visibile: ogni settimana il founder vedeva qualcosa crescere e poteva dire la sua.

Al giorno 90 non c’era la piattaforma dei sogni: c’era un flusso vero, con utenti veri e dati veri, che il founder poteva mettere davanti ai primi utenti reali. E lì è successo il valore dell’MVP: gli utenti hanno usato la cosa, e hanno rivelato che una parte dell’idea funzionava e un’altra andava ripensata — una scoperta che, senza MVP, sarebbe costata due anni e tutto il budget. Il giorno 91 il founder aveva codice suo, dati suoi, e una decisione informata su come proseguire. La nota onesta: il prodotto consegnato era molto più piccolo del sogno iniziale, ed è esattamente questo che l’ha reso utile — un flusso vero batte dieci flussi finti.

È per te se / non è per te se

È per te se: sei un founder con un’idea e vuoi validarla con un prodotto vero, non con delle slide; capisci che un MVP è un flusso funzionante con utenti e dati veri, non l’intera piattaforma; sei disposto a tagliare (a decidere cosa NON fare nei 90 giorni); vuoi visibilità settimanale e codice tuo, per gestire qualsiasi esito al giorno 91.

Non è per te se: vuoi “tutta la piattaforma” in 90 giorni e non sei disposto a tagliare (allora o sfori, o ti danno una versione finta); cerchi delle belle schermate per gli investitori più che un prodotto funzionante (allora ti serve un mockup, non un MVP, e costa e vale un’altra cosa); non sai da dove vengono i dati e non vuoi affrontarlo (senza la fonte dei dati, non c’è MVP); pensi che il giorno 91 “vedremo” — perché senza un piano per il dopo, anche un MVP riuscito è un vicolo cieco.

Domande frequenti

Cos’è davvero un MVP? Un prodotto minimo funzionante: un flusso centrale, completo, che una persona reale usa sui dati veri, con login e ruoli. Non è il brand e tre schermate su Figma (quello è un mockup), non è un prototipo cliccabile che sembra funzionare. La parola chiave è “viable”, funzionante: se non funziona per davvero, è una presentazione, non un MVP.

Cosa ci sta in 90 giorni? Un flusso, fatto bene, con utenti veri e dati veri, e una o due integrazioni essenziali. Non l’intera piattaforma, non dieci integrazioni, non “l’AI che fa tutto”, non tutti i casi limite. La disciplina di tagliare — decidere cosa lasciare fuori — è ciò che distingue chi consegna un MVP vero da chi ti fa sognare e poi sfora.

Perché non posso avere tutta la piattaforma subito? Perché una piattaforma completa è mesi o anni di lavoro, e costruirla tutta prima di aver validato l’idea è il modo di spendere tanto per scoprire tardi se funziona. L’MVP serve proprio a validare spendendo poco: un flusso vero davanti a utenti veri ti dice se vale la pena continuare, prima di costruire il resto.

Come riconosco un frontend senza backend? Prova a usarlo davvero: i dati si salvano? le azioni fanno succedere qualcosa di reale? tornando domani, ritrovi quello che hai fatto? Se “quasi”, se “quel pulsante è il prossimo step”, se i dati spariscono, hai un guscio: schermate belle senza la logica sotto. Un MVP deve funzionare per davvero, non sembrare che funzioni.

Perché mi chiedete tanto dei dati? Perché la fonte dei dati è spesso il vero collo di bottiglia di un MVP, più delle schermate. Se il prodotto ha bisogno di dati e non sai da dove arrivano, in che stato sono, chi te li dà, hai un buco al centro. Un partner serio affronta i dati prima del design: costruire la facciata senza sapere se ci sono le fondamenta è un rischio non affrontato.

Quanto costa un MVP? Dipende dalla complessità del flusso, dallo stato dei dati, dal numero di integrazioni e da quanto è definita l’idea: si parla a forchette, non con un numero magico. Un numero preciso dato senza aver capito il tuo caso è un aggancio. La forchetta giusta è quella che ti compra un flusso vero, funzionante e testabile — abbastanza per sapere se continuare.

Come faccio a controllare che stia andando bene? Pretendendo visibilità settimanale: ogni settimana qualcosa da vedere e provare, e una conversazione onesta su fatto/manca/da tagliare. Il silenzio (“stiamo lavorando” per settimane, senza niente da mostrare) è il segnale di allarme. La visibilità è come ti accorgi in tempo se serve correggere la rotta, invece di scoprirlo alla consegna.

Cosa succede dopo i 90 giorni? Metti l’MVP davanti agli utenti e impari: funziona e cresci, funziona ma va corretto, o non funziona (e l’hai scoperto in 90 giorni invece di due anni). Perché tutti gli esiti siano gestibili, al giorno 91 il codice e i dati devono essere tuoi e ci dev’essere un accordo su come si prosegue. Il giorno 91 va progettato insieme al giorno 1.

In una riga

Un MVP in 90 giorni si può, ma non è il brand e tre schermate su Figma: è un flusso centrale, funzionante per davvero, con utenti veri e dati veri. Ci sta un flusso fatto bene; non ci stanno la piattaforma completa, dieci integrazioni, l’AI magica e tutti i casi limite — e la disciplina di tagliare è la competenza che conta. Diffida del frontend senza backend (schermate belle e vuote) e affronta subito la fonte dei dati (senza, non c’è MVP). Pretendi visibilità settimanale, budget a forchette e codice tuo, così il giorno 91 — qualunque sia l’esito — è gestibile.

Se sei un founder e vuoi un MVP vero, non delle slide, guarda i progetti che ho costruito o scrivimi due righe: partiamo dal flusso che conta e dalla fonte dei tuoi dati, e ti dico onestamente cosa sta in 90 giorni e cosa stai sognando.