Most MVPs fail for one of two opposite reasons: they ship so little that nobody can tell what the product does, or they ship so much that the team runs out of money before finding out whether anyone wants it. The useful definition sits in between — the smallest thing that lets a real user complete the core job end to end.
Start from the one job
Write a single sentence: 'A [user] can [action] so that [outcome].' Everything that does not sit on the path of that sentence is a candidate for cutting. Admin dashboards, role hierarchies, notification preferences, and dark mode almost never sit on that path in version one.
The 80/20 of MVP scope
- Ship: the core flow, authentication, payment if you are charging, and one honest empty state.
- Fake: reporting (a CSV export), onboarding (a scheduled call), and moderation (your inbox).
- Defer: integrations nobody asked for, granular permissions, multi-language, and offline support.
- Never skip: error handling on the money path, and a way to contact you when it breaks.
Manual work behind the curtain is not technical debt — it is market research you get paid for.
Pick boring technology on purpose
An MVP is a race against learning, not a showcase of architecture. A well-understood stack with a large hiring pool and mature libraries removes an entire class of problems that have nothing to do with your product. Save your novelty budget for the thing that is actually novel: your product.
Design for the first 100 users
A single database, a single deployable, and a managed host will carry you further than most founders expect. What matters at this stage is not horizontal scale — it is deploy speed, the ability to read production logs, and analytics good enough to tell whether people came back on day seven.
- 1Instrument the core flow before launch: signup, activation, and the one action that defines value.
- 2Ship behind a flag so you can turn off a bad idea without a rollback.
- 3Keep a written 'not now' list. It stops good ideas from becoming scope creep without losing them.
- 4Set a review date, not a feature list, for version two.
The MVPs that grow are rarely the most complete ones. They are the ones that answered a real question fast enough to still have runway when the answer arrived.