An MVP in production is something a person who is not you can use, with their data, without you in the room. A prototype (Figma, demo, passworded staging) is not. At Snowinch that is the threshold; below it, we do not call the work "live".
The mix-up is convenient. "MVP" sounds adult. "Prototype" sounds unfinished. So the Figma becomes an MVP, the video becomes a launch, staging becomes "we are online".
Two objects, two jobs
A prototype is there to see whether a shape holds in a room. You click. The data is fake. Someone says wow. End of job. It has a low cost and a low lie, if you stay honest about what it is.
An MVP in production is there to see whether a hypothesis holds outside. Someone creates an account. They put in a work email, a file, a card. The system has to hold without you. If their data can be lost or read by mistake, you are not testing the market. You are delaying an incident.
The two can sit in sequence. The problem is when you use the second word to sell the first. To yourself, especially.
A passworded environment, sent to three friends, is a prototype with guests. A landing with a form, and nothing behind it that holds, is a sign. A commented Figma is a Figma. None of these is in production. Production is when the system is on for people who owe you nothing, and the data is treated as theirs, not as a development dump.
We already broke this into pieces in the usual "MVP" mistakes: the mini-product locked in staging, the empty shell, Wizard of Oz declared or not. Here the cut is drier. Not "how finished". Where it lives, and whose data it is.
The mistake that does more damage
The most frequent is not the sign. It is staging dressed as a launch. Polished interface, onboarding, plans. Real time. Then you send the URL to people who already know you, or you do not send it. You validated your patience. Not live.
The second is the opposite: you throw out something raw, with no access control, no deletion, no idea who has the keys, and you call it an MVP because "it is the first version". First version of what. Of a risk.
I would rather have something thin and true, switched on, than a glossy object that lives on my hosting. It looks unfinished. It teaches. Gloss in private reassures and does not pay.
There is a moment when the prototype is the right move. You need two people aligned on a flow before you write auth. You need a technical person to see where the story breaks. You do it, you call it a prototype, and you do not raise money by saying you are live. The day that distinction starts to annoy you, you are already lying.
A small aside: I still have a founder who said "we are in production" and meant Vercel with the preview flag. The URL changed on every push. The users were him and his brother. The deploy was real. The product was not.
The signal that counts
It is not the number of screens. It is not whether the design "looks like a product". The signal is economic or costly in another way: a payment, an action you would not do out of politeness, a return from someone who is not in your address book. And, with that, the fact that that person's data sits somewhere you answer for.
Without that, you are still trying on costumes. Validating an idea and stopping at the prototype is the point where most people treat an arrival. It is not.
When it makes sense to build (really build, not another Figma) is when the riskiest hypothesis has a sufficient yes, and what you raise from there has to stay on. Not certainty. A reason to hold users and data, knowing secondary hypotheses will show under real load.
On services that is the door: MVP as production, same standard, not a toy. If you want a yes on a scope that stays in demo "because it is an MVP", that is not us.
The limit of this page: it is not a checklist of minimum features, nor no-code vs custom. It does not tell you "how small". It tells you when to stop using the wrong word.
If you already have a signal and you need live, not another dress rehearsal, we talk perimeter on contact.
