Most MVPs fail for the same reason: they try to be a smaller version of the final product instead of an answer to a single question. If your MVP has a login system, five user roles, a settings page, and a notifications center before you've confirmed anyone wants the core thing at all, you haven't built a minimum product. You've built a small, expensive one.
Start with the riskiest assumption
Every product idea rests on an assumption that could be wrong. Usually it's one of:
- Will people actually pay for this?
- Will the two sides of this marketplace both show up?
- Does this workflow save enough time to matter?
Your MVP's only job is to test that assumption as cheaply and quickly as possible. Everything else (the polish, the edge cases, the "nice to have" features) can wait until you know the core idea holds up.
Scope by what you'd regret not testing
A useful exercise: list every feature you think the product needs, then ask, for each one, "if this were missing, would the test still be valid?" Most features survive that question. A handful don't. Those are your MVP.
This is uncomfortable, because founders are usually attached to the full vision. But an MVP that tests the wrong thing wastes more time and money than a slightly ugly one that tests the right thing.
Build it to extend, not to throw away
There's a difference between an MVP and a prototype. A prototype exists to be discarded once it's answered its question. A good MVP is architected so that once it validates demand, you keep building on the same foundation rather than starting over.
That means making a few deliberate decisions early: how data is modeled, how authentication works, how the system will need to scale, even while keeping the feature set narrow. This is usually where an experienced technical partner earns their keep: not in writing more code, but in knowing which few decisions are expensive to change later and which ones genuinely don't matter yet.
What this looks like in practice
When we scope an MVP with a founder, the first conversation is rarely about technology. It's about the business question the product needs to answer, and the smallest real version of the product that can answer it. The technical plan follows from that, not the other way around.
If you're trying to figure out whether your idea needs a full platform or a focused first release, that scoping conversation is worth having before any code gets written.