The word 'MVP' has been stretched so far it's nearly meaningless. We've heard it used to describe everything from a Figma prototype to a fully featured SaaS application with 20,000 lines of code. The ambiguity costs real money.
Here's what an MVP is actually supposed to do: answer a specific question with the minimum investment possible. Not 'is this idea good?' — that's too vague. A specific question. 'Will this user segment pay £29/month for this specific feature?' is a specific question. 'Can we process KYC onboarding in under 3 minutes on mobile?' is a specific question.
The question-first approach
Before scoping any MVP, we ask founders to name the one assumption their business dies if it's wrong. Not the ten assumptions that might be wrong — the one that would kill the company if it turned out to be false.
That assumption determines what the MVP needs to prove. Everything else is a feature request.
If the assumption is 'users will pay for this', you need a checkout flow. If the assumption is 'users can complete this workflow without support', you need the full workflow but probably not the analytics dashboard. If the assumption is 'this can be built in a way users trust', you need the security and UX but probably not the API integrations.
What always ships in an MVP
The core user journey, start to finish. Not a partial journey, not a demo mode — the actual thing the user needs to do to get value. If there's friction in that journey, it belongs in the MVP because friction kills conversion and you need to know about it before you scale.
Authentication and basic security. This is non-negotiable for anything handling real user data. Skipping security for speed is a false economy — security retrofits are expensive and sometimes architecturally impossible.
A way to capture feedback. Even a simple Typeform at the end of a key workflow gives you signal. Ship analytics from day one. The data you collect in the first two weeks is usually the most valuable data you'll ever have.
What never ships in an MVP
Admin dashboards. Reporting. Notification preferences. API documentation for third-party developers. Multi-language support. Dark mode. These are all things that feel important during planning and prove completely irrelevant in the first user cohort.
The test we apply: 'If we removed this feature, would the first 10 users notice or care?' If the answer is no, it doesn't ship.
The cost of building too much
Building a full product before talking to users has two costs that aren't always obvious. The first is the obvious one: you've spent money building things users don't want. The second is subtler: you've reduced your ability to change direction. Every line of code you write is a small constraint on your future flexibility.
We've rebuilt more products than we care to admit because the original build was based on assumptions about users that turned out to be wrong. The founders who shipped earliest and gathered real signal first spent far less total on their products than the ones who got it 'right' on paper before shipping.
A working rule of thumb
If your MVP takes longer than 12 weeks to build, it's not an MVP. It's a v1. That's fine — v1s ship too — but be honest about what you're building and why. A 12-week build should be validating multiple assumptions with a product that has genuine commercial viability, not just proving a single hypothesis.
Scope ruthlessly. Ship fast. Learn from real users. Repeat.