Scoping an MVP that survives contact with real users

"Build an MVP" means two incompatible things depending on who says it. To a founder raising money, it means something impressive enough to demo. To an engineer, it means the smallest thing that tests the risky assumption. Projects go wrong in the gap between those two definitions.

Here's how we scope MVPs so they're both credible in a demo and not a liability three months later.

Name the assumption you're actually testing

Every product rests on one assumption that, if wrong, makes everything else irrelevant. Usually it's one of:

• People have this problem badly enough to change what they do.
• They will pay for a solution.
• We can deliver the solution at a cost that works.
• The technology can do this reliably enough to trust.

The MVP's job is to test the riskiest of those. Everything not serving that test is scope you're funding for no return yet.

This sounds obvious and is routinely skipped. We've scoped MVPs where the team could not name the assumption, and in every case the build was substantially larger than it needed to be — because with no test to satisfy, there's no principle for excluding anything.

The four things you cannot skip

"Minimum" gets read as "cut corners everywhere". Four areas are cheaper to do properly at the start than to fix once you have users.

Authentication

Use a proper mechanism from the beginning. Not because an MVP needs enterprise SSO, but because retrofitting identity means touching every table with a user reference and migrating live accounts. Get it right once.

The data model

Everything else is replaceable. UI gets redesigned, endpoints get rewritten, frameworks get swapped — but a bad data model propagates into every query, every report and every migration, and gets more expensive to change every week.

Spend a day on it. Specifically: get the relationships and cardinality right and don't denormalise for a performance problem you don't have yet.

A way to see what's happening

Structured logs and error tracking. When your first real user hits a bug, you need to know what happened without asking them to reproduce it. This is an afternoon of work and it repays itself the first week you have users.

Deployment you can repeat

If shipping a fix requires someone's laptop and a remembered sequence of commands, you will ship fixes slowly at exactly the moment speed matters. Containerised, one-command deploy, from the first week.

What to cut, in order

When scope needs to come down — and it always does — cut in roughly this order:

1. Configurability. Hard-code it. One workflow, one set of statuses. Configuration is a bet on knowing what varies, and you don't yet.
2. Self-service administration. You can create accounts manually for the first fifty customers. It takes minutes and teaches you what onboarding actually needs.
3. Edge-case handling. Handle the main path properly and fail loudly and clearly on the rest. A clear error beats a half-built path.
4. Breadth of integrations. One integration done well beats four done partly. Pick the one most customers actually use.
5. Polish on secondary screens. The main flow should feel finished. Settings pages can look plain.

What not to cut: the core flow's reliability. An MVP that loses data or silently fails doesn't test your assumption — it tests whether users tolerate broken software, and you already know that answer.

The demo trap

MVPs built for investor demos optimise for the eight minutes on screen. That produces impressive-looking things with nothing behind them — and then a real user arrives.

The version we'd argue for: build the core flow genuinely working end to end, narrow but real. It's less visually broad than a mocked demo, but it survives contact with an actual user, and the conversation changes completely when a prospect can use it rather than watch it.

If you need breadth for a specific pitch, be explicit that certain screens are visual only, and keep them out of the codebase you intend to keep. Mixing real and fake in one system is how a demo becomes a maintenance problem.

Where AI features fit

Increasingly the risky assumption is "can the model do this reliably enough". If so, test that first and test it cheaply — before building any product around it.

Collect thirty real examples. Run them through a model with a reasonable prompt. Score the results by hand. That afternoon tells you more than a month of building would, and it's the same evaluation set you'll need later anyway.

If accuracy is nowhere near what's needed, you've learned it for the price of an afternoon. If it's close, you now know exactly how close, and you can design the human review step around a real number instead of an assumption.

Timeline, honestly

Six to twelve weeks is the realistic band for an MVP with a working core flow, real authentication, a considered data model and a repeatable deployment. Under six weeks usually means either a genuinely tiny scope or corners that will be paid for later.

The variable is rarely engineering speed. It's decision speed. Projects that run long almost always do so because a scope question sat unanswered for a week, not because the code took longer than expected.

The single best thing a founder can do for an MVP timeline is be available to answer questions within a day. That is worth more than an extra engineer.

After it ships

The MVP's real output is information. Before launch, agree what you'll measure and what result would change the plan — including the result that means stopping.

Teams that skip this end up interpreting ambiguous early usage as encouragement, and build the next six months of roadmap on it. Decide in advance what "this worked" looks like, in numbers, and you'll get a straight answer instead of a comfortable one.

If you want a sense of effort and timeline for your own scope, the cost estimator covers MVPs alongside the larger project shapes.