"MVP" has been used to mean a prototype, a demo, a first version, a cheap version, and a full product with a smaller budget. When a client and a studio use the same word for different things, the project is already in trouble.
Here is the definition we use, because it is the one that makes decisions easier.
An MVP is an experiment with a hypothesis
Not a smaller product. Not a cheaper product. The smallest thing that can prove or disprove the riskiest assumption in your business.
That framing forces a useful question: what do you actually not know? Every new product rests on a belief that might be wrong. Restaurants will pay for this. Drivers will accept these jobs. People will trust a stranger with this. The MVP exists to test that belief for the least money possible.
If you cannot say what your riskiest assumption is, you are not ready to scope an MVP, and any number a studio gives you is arbitrary.
The test: what would falsify it?
Once the assumption is named, ask what result would tell you that you are wrong.
This is where most MVPs quietly fail. They get built, they launch, some people use them, and the team concludes it is working — because no outcome was defined in advance that would have counted as failure. An experiment that cannot fail is not an experiment, it is an expensive way to feel productive.
Decide beforehand: what does success look like at week four, and what result means we stop?
What twelve weeks actually buys
For a competent team on a focused scope, roughly:
- One user type, done well, rather than three done partially
- The core loop — the single sequence that delivers your value — polished, with everything around it plain
- Real authentication, real data, real payments if payment is part of the hypothesis
- Enough admin tooling for you to operate it manually
- Web, generally; native apps if the hypothesis genuinely requires them, which is rarer than people assume
What it does not buy: multiple user roles, extensive settings, automated onboarding, an analytics suite, integrations, or the polish of a product that has had two years of feedback. Those are all reasonable things to want and none of them test your hypothesis.
The manual-first principle
The highest-leverage thing we tell clients: anything a human can do behind the curtain should not be software yet.
Matching supply to demand can be someone with a phone. Verification can be someone looking at a document. Onboarding can be a call. Every one of these becomes software eventually — but building the automated version before you know the manual version works is how you spend three months automating a process you are about to change.
This feels wrong to founders because it does not scale. That is the point. You are not scaling yet. You are finding out whether the thing is worth scaling, and doing it manually teaches you what the automated version should actually do — knowledge you cannot get any other way.
Where MVPs go wrong
Scope creep disguised as necessity. Every addition sounds essential. The discipline is asking whether it tests the hypothesis. Usually it does not.
Building for the second-year user. Architecture chosen for a million users, spent on a product that has zero. Some decisions are genuinely expensive to reverse and deserve thought. Most are not.
Skipping the admin panel. The one place teams underbuild that always costs them. You will operate this product by hand for months. Give yourself tools.
Treating it as version one of the real thing. Sometimes the right outcome of an MVP is throwing it away, having learned the thing was wrong. Budget emotionally for that.
What we do first
Before scoping, we ask three things: what is the riskiest assumption, what result would prove it wrong, and what is the smallest thing that produces that result.
Sometimes the answer is a twelve-week build. Sometimes it is a landing page and forty phone calls, and we say so — we would rather tell you that than take money to build something you did not need yet.
If you are trying to figure out what your actual MVP is, tell us the assumption you're worried about.