By Manuel Tardivo
Your MVP validates nothing (and often is not even in production)
Many MVPs are not a test and not live: they stay demos, staging, videos. What separates an MVP in production from an incomplete product that validates nothing.
Your MVP validates nothing. Often it is not even in production.
It is a video, a Figma file, a passworded environment, a test account you use yourself. Most of the ones we see at Snowinch are not testing a hypothesis on real users. They are protecting a prototype from any contact that might break it.
What you are calling an MVP
MVP is a word used for different objects. A landing page, a prototype, a version with fewer features than the product in your head, a closed beta, a service done by hand. None of these forms is automatically an MVP. All of them can be, if you are testing something precise.
In practice the hypothesis is missing. There is the product someone wants to build, and the MVP is the first version of that same thing: smaller, less finished. That is not a test. It is an incomplete product.
An incomplete product is judged by how much is left. An MVP is judged by what you learned. The distinction changes the order you build in and the threshold you use to decide whether to continue.
It especially changes one thing that usually stays out of the conversation: where it lives.
Production, not a demo
A test that never leaves your computer is not talking to the market. It is talking to you.
The finished mini-product is the common case. Polished interface, onboarding, pricing plans, a tidy landing page. It took real time. When you "launch" you are already too far in to read a no without rewriting it. And often you do not launch: it stays in staging, or it runs on a URL you send to people who already know you. Too many variables at once (price, copy, channel, features) and zero users who are not in your address book. If something does not convert, you do not know what. If nobody comes in, you have not validated live. You have validated your patience.
The empty shell is the wrong reaction. Headline, a few bullets, an email field. People subscribe if the copy is curious; curiosity costs almost nothing. A long list without a payment, without use, without data that has to stay safe, validates the headline. Not willingness to pay, not whether it holds, not the nights. It is a copy signal.
Then there is the prototype that "works" on a call. You share a screen. You click. The data is fake. Someone says wow. That room is not production. Production is when a person who is not you creates an account, puts something of theirs in it (a file, a card, a work email), and the system has to hold without you being on the line. If that person's data can be lost or read by accident, the test is already a delayed incident.
Or rather: the mini-product locked in staging is worse than the empty landing. The landing at least admits it is a sign. Staging dressed up as a launch convinces you that you "put it online" while the only user is you.
The bar we use is blunt. In production, not a demo. Someone outside can use it. There is an economic signal or a use that costs (a payment, an action you would not do out of politeness). Data is treated as if it belongs to them, not to a development dump. If one of those is missing, you are still trying on costumes.
I would rather have a thin real thing in production than a glossy object that lives on my hosting. It costs in looks: it seems unfinished. I take that. Unfinished in live teaches. Glossy in private reassures.
Wizard of Oz (you do it by hand, the client thinks it is the product) can sit in the doorway. Say it, at least to yourself. The next day you cannot pretend that manual queue is "already scalable". Either you close it in a perimeter, or you admit live is not there yet.
The wrong hypothesis, even online
You can be in production and still test the useless thing.
The risk in a marketplace is whether both sides meet and transact. Building registration, notifications, and a "usable" interface first produces charts. It does not produce the answer. Same for a lot of products: you test onboarding and not payment; you test the AI model and not whether anyone comes back after the first crooked reply.
A clear negative signal (nobody pays, they drop at one point, the hypothesis falls) is an MVP that did its job. An ambiguous signal (someone clicked, you do not know why) is something to redesign. Not because it is "ugly". Because you do not have information.
Distribution matters as much as the artifact. Sending it to generic contacts, followers, people who want you to succeed, dirties the no. The ICP has to be able to refuse in a visible way.
When to stop calling it a test
There is the opposite risk: testing so you never ship. The cycle becomes a way not to face users, data, sleep.
The useful shift is when the riskiest hypothesis has a sufficient yes, and what you build from there has to stand on its own. Not certainty. A reason to invest in the real product, knowing secondary hypotheses will show up under real load.
At that point you are no longer protecting a demo. You are holding a live system. On services that is the transition: from a tight scope to something that can stay on. The published cases came out of that loop, not from endless staging.
If your "MVP" is still a link you are afraid to forward to someone with a card in their hand, you do not have a feature problem. You have an object that is not in production. That does not validate the market. It does not validate you at night either.
If you already have a signal and you need live, not another dress rehearsal, we can talk perimeter. If you want a yes on a scope that stays in demo "because it is just an MVP", this is not the conversation.