"MVP" has drifted to mean "a cheap version". That is not what makes it useful. A minimum viable product is the smallest thing that answers a real question about whether your idea works.
If you scope it as "the cheap version", you usually get software that is too limited to learn from and too poorly built to extend. That is the worst of both.
Start from the question, not the feature list#
Before scoping, write down the single riskiest assumption in your business. Usually it is one of:
- Will people pay for this at all?
- Will they change their existing habit to use it?
- Can we actually deliver the service behind the software profitably?
Your MVP only has to test that. Everything else is a distraction that costs money.
What to leave out on purpose#
Things that can almost always wait:
- Multiple user roles and granular permissions
- A settings screen for things you can change in the database
- Analytics dashboards for data you do not have yet
- Native mobile apps, when a responsive web app answers the same question
- Automated onboarding, when you have few enough users to onboard by hand
What not to cut#
This is where "cheap version" thinking causes damage. Do not skip:
Authentication done properly. Retrofitting auth and roles into a system that assumed one user type is not a small change.
A sane data model. Almost everything else can be rewritten. A data model with the wrong shape leaks into every query, screen and report you build afterwards.
Deployment that is repeatable. If shipping an update is a manual ritual only one person knows, you will ship less often, which defeats the purpose of learning fast.
Backups you have tested. Losing your first hundred users' data is a bad way to learn this lesson.
Build for replacement, not for permanence#
Assume parts of the MVP will be thrown away. That is a success condition, not a failure — it means you learned something. The trick is choosing which parts are disposable and which form the foundation.
Disposable: screens, copy, workflows, integrations. Foundational: data model, auth, deployment, the environment it runs in.
How long should it take#
It depends entirely on the question you are answering. A focused internal tool can be a matter of days to weeks. A platform with multiple user types, payments and integrations takes longer.
What should never happen is a six-month MVP with no user contact in the middle. If the timeline is that long, the scope is answering too many questions at once.
If you do not have a technical co-founder#
This is the common case, and it is the specific gap our startup division exists to fill: you have the idea and the domain knowledge, and you need someone accountable for the architecture and platform decisions rather than just a pair of hands.
If that describes you, tell us the problem and we will tell you what version one actually needs to include.