Un MVP in produzione è una cosa che una persona che non sei tu può usare, con dati suoi, senza che tu sia nella stanza. Un prototipo (Figma, demo, staging con password) non lo è. In Snowinch la soglia è quella; sotto, non chiamiamo il lavoro "live".
La confusione è comoda. "MVP" suona adulto. "Prototipo" suona incompiuto. Allora il Figma diventa MVP, il video diventa lancio, lo staging diventa "siamo online".
Due oggetti, due mestieri
Il prototipo serve a vedere se una forma regge in una stanza. Clicchi tu. I dati sono finti. Qualcuno dice wow. Fine del mestiere. Ha un costo basso e una menzogna bassa, se resti onesto su cosa è.
L'MVP in produzione serve a vedere se un'ipotesi regge fuori. Qualcuno crea un account. Ci mette una mail di lavoro, un file, una carta. Il sistema deve tenere senza di te. Se i suoi dati si possono perdere o leggere per sbaglio, non stai testando il mercato. Stai ritardando un incidente.
Le due cose possono stare in sequenza. Il problema è quando usi la parola della seconda per vendere la prima. A te stesso, soprattutto.
Un ambiente con password, mandato a tre amici, è un prototipo con ospiti. Una landing con un form, senza nulla dietro che tenga, è un cartello. Un Figma commentato è un Figma. Nessuno di questi è in produzione. Produzione è quando il sistema è acceso per gente che non ti deve niente, e i dati si trattano come loro, non come un dump di sviluppo.
Lo abbiamo già spezzettato negli errori tipici da "MVP": mini-prodotto chiuso in staging, guscio vuoto, Wizard of Oz dichiarato o no. Qui conta una distinzione più secca. Non "quanto è finito". Dove vive, e di chi sono i dati.
L'errore che fa più danni
Il più frequente non è il cartello. È lo staging truccato da lancio. Interfaccia curata, onboarding, piani. Tempo vero. Poi l'URL lo mandi a gente che già ti conosce, o non lo mandi. Hai validato la tua pazienza. Non il live.
Il secondo è il contrario: butti fuori qualcosa di crudo, senza accessi, senza cancellazione, senza sapere chi ha le chiavi, e lo chiami MVP perché "tanto è la prima versione". Prima versione di cosa. Di un rischio.
Preferisco una cosa sottile e vera, accesa, a un oggetto lucido che vive sul mio hosting. Sembra incompiuto. Insegna. Il lucido in privato rassicura e non paga.
C'è un momento in cui il prototipo è la mossa giusta. Devi allineare due persone su un flusso, prima di scrivere auth. Devi far vedere a un tecnico dove si rompe la storia. Lo fai, lo chiami prototipo, e non alzi soldi raccontando che siete live. Il giorno in cui quella distinzione ti dà fastidio, stai già mentendo.
Un aside piccolo: mi è rimasto un founder che diceva "siamo in produzione" e intendeva Vercel con il flag di preview. L'URL cambiava a ogni push. Gli utenti erano lui e il fratello. Il deploy era reale. Il prodotto no.
Il segnale che conta
Non è il numero di schermate. Non è se il design "sembra un prodotto". Il segnale è economico o costoso in altro modo: un pagamento, un'azione che non faresti per educazione, un ritorno di qualcuno che non è in rubrica. E, insieme, il fatto che i dati di quella persona stanno in un posto di cui rispondi.
Senza quello, stai ancora provando i costumi. Validare un'idea e fermarsi al prototipo è il punto in cui la maggior parte tratta un arrivo. Non lo è.
Quando ha senso costruire (davvero costruire, non un altro Figma) è quando l'ipotesi più rischiosa ha un sì sufficiente, e quello che alzi da lì deve restare acceso. Non certezza. Un motivo per tenere utenti e dati, sapendo che le ipotesi secondarie si vedranno sotto carico.
Su servizi quella è la porta: MVP come produzione, stesso standard, non giocattolo. Se vuoi un sì su uno scope che resta in demo "perché tanto è un MVP", non siamo noi.
Il limite di questa pagina: non è una checklist di feature minime, né un confronto no-code vs custom. Non ti dice "quanto piccolo". Ti dice quando smettere di usare la parola sbagliata.
Se hai già un segnale e ti serve il live, non un'altra prova generale, si parla di perimetro in contatti.
