Building an MVP: What to Cut, What to Keep, and What to Fake

"MVP" gets used to describe two very different things: a genuinely minimal product built to test a real assumption, and a slightly smaller version of the full product the founder actually wants. The second one is why so many MVPs take six months and still don't answer the question they were supposed to answer.

Start with the assumption, not the feature list

Before we sketch a single screen, we ask: what's the one thing you're not sure is true yet, that this product needs to prove? "People will pay for this," "businesses will switch from their current tool for this" — these are testable assumptions. An MVP's entire job is to test one of them as fast and cheaply as possible.

The cut list — things that almost never belong in v1

• Account settings and profile customization beyond the bare minimum — nobody churns from an MVP because they couldn't upload a profile photo.
• Admin dashboards and analytics for a product with a handful of users — you can read the database directly for a while.
• Support for edge cases that apply to under 5% of users — handle them manually at first.
• Multiple payment methods, multiple languages, multiple currencies — pick the one that covers your first real customers.
• Pixel-perfect design across every screen size — a clean, consistent design on the primary device your users will actually use beats a polished version of a screen nobody opens.

What to fake instead of build

Some of the most valuable early product decisions come from faking the parts that are expensive to build and cheap to simulate. A "personalized recommendation" can be a person manually curating results behind the scenes for the first fifty users. This isn't cutting corners — it's buying yourself real user feedback before you invest engineering time automating something you haven't validated yet.

If you can't tell whether a feature is essential or just familiar, ship without it and see if anyone asks for it.

What actually needs to be solid on day one

Cutting scope doesn't mean cutting quality on what remains. The core action your product exists to enable needs to work reliably, every time, with no confusing states. Users forgive a product for being simple. They don't forgive it for being broken at the one thing it claims to do. A clear brief helps here too — see how to brief a dev agency for how we scope that core action precisely.

The real test of a good MVP

You'll know your MVP was scoped correctly if it feels slightly too small when you launch it. That discomfort is usually a good sign. The MVPs that feel comfortable and complete on launch day are almost always the ones that took too long to get there.