How to Scope an MVP That Actually Validates Something

The MVP that tests nothing

A founder shows us a spec: user accounts, admin panel, notifications, billing, a mobile app — "just the MVP." Six months of work that validates nothing except the founder's ability to spend money. The problem isn't ambition. It's that the scope wasn't derived from a question.

Start with the riskiest assumption

Every startup rests on a stack of assumptions. Write them down, then sort by "if this is wrong, the company is dead." Common candidates:

• People have this problem urgently enough to switch tools
• They'll pay this much for a solution
• We can deliver the outcome at acceptable cost
• The channel we plan to acquire through actually converts

Your MVP exists to test the top of that list — nothing else.

Derive scope from the question

If the risky assumption is demand, you might not need software at all: a landing page with real pricing and a waitlist tests demand in a week. If it's willingness to pay, a concierge version — you doing the work manually behind a thin interface — tests it without building the engine. If it's the technology working, build exactly the core loop and skip everything around it.

The features that survive this filter are usually 20% of the original spec.

What to cut without guilt

Admin panels (use the database directly), settings pages (hardcode defaults), multi-tenancy polish (first customers can share a tenant), native apps (responsive web first), SSO (until an enterprise deal demands it). All of it is buildable after evidence arrives.

Ship, measure, decide

An MVP isn't done when it launches — it's done when it answers the question. Define the metric and threshold before launch: "20% of trials convert" or "users return 3+ times a week." Then honor the answer, even when it says pivot.