How to scope and build an MVP without building the wrong thing

What an MVP actually is

A minimum viable product is the smallest version of a product that can test whether the idea works, with real users doing real work. Two words in that sentence do the heavy lifting. Minimum means it is as small as it can be and still answer the question. Viable means someone can genuinely use it to get something done — not a demo, not a mock-up, a working thing.

The term comes from lean startup practice, where Eric Ries defined it as the version that lets a team collect the maximum validated learning with the least effort. The emphasis on learning is the part most often lost. An MVP is an experiment that happens to be shipped software. If you are not going to change your plans based on what it tells you, you are not building an MVP, you are building version one on a tight budget — which is a legitimate thing to do, but it needs a different conversation about scope.

The UK government's own service standard uses the same logic under different names, moving a service through discovery, alpha and beta before committing to live. Each phase exists to kill bad ideas cheaply.

The wrong thing people usually build

The characteristic failure is not building too little. It is building a complete, small product that answers no particular question.

It looks like this: the team lists everything the product should eventually do, cuts the list roughly in half, and builds that. The result has a bit of everything — user accounts, a settings page, an admin area, three of the eight core features — and none of it is complete enough for anyone to actually run their work through. Users try it, get to the point where the thing they needed is missing, and leave. The team learns that people "weren't ready for it", which is not information you can act on.

Halving a feature list feels like prudent scoping, and it is the most reliable way we know of to waste a first budget. The alternative is to narrow rather than halve, which is what the next two sections cover.

Start from the riskiest assumption

Before scoping anything, write down the assumption that, if wrong, makes the whole idea pointless. Not the biggest technical unknown — the biggest commercial one.

For most products it is one of a small set. Will anyone change their current behaviour to use this? Will they pay? Can we reach them affordably? Does the work actually get done faster this way? Is the data good enough to make this useful?

Then ask what the smallest thing is that would test it. Frequently that is not software at all: if the assumption is "people will pay for this", a landing page and a deposit tests it faster than a build. If the assumption is "this can be made to work technically", you want a proof of concept, not an MVP. Reserve the MVP for the assumption that genuinely needs real users doing real work to settle.

Naming the assumption also gives you a way to end arguments about scope. Every proposed feature gets one question: does this help us test the assumption? If not, it goes on the list for later, without anyone having to claim it is unimportant.

Cut scope by narrowing, not halving

The method that works is to narrow three dimensions and keep the fourth complete.

• One user type. Pick the single audience whose problem is sharpest. Not "businesses and consumers" — one.
• One job. The single task they will use it for, not the four adjacent ones.
• One path. The happy path through that job. Edge cases, bulk actions, imports and integrations wait.
• But complete. That one path works end to end, properly, for a real user with real data.

This is the opposite of the half-a-feature-list approach, and it produces something people can genuinely use. It also gives you clean evidence: if the one user type doing the one job does not come back, you have learned something real rather than something confounded by a half-finished product.

The second lever is deciding what to fake. An MVP does not need everything automated. Manual onboarding, a human reading submissions, a report assembled by hand, a spreadsheet behind the scenes — all fine, as long as the user's experience is real. Faking the back end is cheap and reversible; faking the user's experience is what makes an MVP useless.

MVP vs prototype vs proof of concept

These get used interchangeably and they answer different questions, which is why the confusion is expensive.

• A proof of concept answers "can this be built at all?" There are no real users, and the software only partly works — enough to prove the mechanism and no more.
• A clickable prototype answers "do people understand it, and is this the right shape?" Real users test it, but nothing works underneath: the screens look real and do nothing.
• An MVP answers "will people use it, and does it deliver value?" Real users in the wild, with genuinely working software behind the screens.

The sequence matters commercially. A clickable prototype is dramatically cheaper than an MVP and catches most design and comprehension problems, and in our projects the full prototype process completes in approximately 3 to 4 weeks. Skipping it to "save time" usually means discovering the same problems in built software, where changing them costs many times more.

Set the success criteria before you build

Write down, before the build starts, what result would make you continue, change direction, or stop. Be specific about the number and the window: how many users, doing what, how often, by when.

This is the single most skipped step, and skipping it has a predictable consequence. Without a pass mark, every MVP result looks ambiguous, and the default interpretation is always "it needs a few more features". That is how a four-week experiment becomes an eighteen-month build with no decision point.

Pick measures of behaviour rather than opinion. People telling you they like it is not evidence; people using it twice in a week without being chased is. Gov.uk's user research guidance is a good, free grounding in watching what users do rather than asking what they think.

Agree in advance who makes the call, too. A criterion nobody owns is a criterion that gets renegotiated the day the data arrives.

What an MVP costs and how long it takes

In our projects, MVPs are built in fixed two-week Velocity Sprints, and most aim to launch a functional, usable MVP within 2 to 8 weeks — typically spanning 2 to 4 sprints. Most clients start with 2 to 4 sprints, you commit one sprint at a time, and you can stop at the end of any current sprint rather than signing up for the whole programme.

Each sprint is a fixed price with a predictable number of Output Units, which are units of finished work rather than time spent. That structure exists to answer the question this guide keeps returning to: it lets you stop when you have learned enough, instead of when the budget runs out.

On the total, our quote page publishes a floor rather than a price list — apps and portals take hundreds of hours, so a bespoke project under £7.5k is unlikely and most of our projects are more than that. Payment tracks delivery; the worked example there is a £20,000 project over three months, split into a deposit plus one payment at each month end.

If you want the scope and estimate settled before committing to a build at all, Quickstart App Planning typically completes within 3 to 6 weeks.

The mistakes we see most

Five recur across the MVP projects we take on, and none of them are technical:

• No first users lined up. The build finishes and there is nobody to give it to. Recruit the first ten before commissioning anything; if you cannot find ten people who want it, that is the finding.
• Admin before product. Weeks spent on user management, permissions and settings screens before the thing that delivers value exists. Do the value first, even if you administer it by hand.
• Scope creep dressed as feedback. Early users will ask for things. Log them; do not build them until the original assumption is settled.
• Building for the pitch, not the user. An MVP shaped to impress investors optimises for a demo and teaches you nothing about usage.
• No decision meeting. The criteria were written, the data arrived, and nobody ever sat down to decide. Book that meeting when you start the build.

After the MVP

There are only three honest outcomes, and all three are successes in the sense that matters: you now know something you did not.

If it worked, the next question is what to harden rather than what to add. The shortcuts you took deliberately — the manual onboarding, the missing edge cases, the spreadsheet in the middle — now need paying off before load makes them expensive, and that is the point at which technical debt stops being a sensible trade and starts being a risk.

If it half-worked, the useful move is to narrow further rather than broaden: find which slice of users got real value and serve them properly before widening.

If it did not work, stop. That is the outcome the whole approach is designed to make cheap, and a four-week answer is a good result. The expensive version of that answer takes two years.

If you would like help deciding what your MVP has to prove and what the smallest version looks like, see how our sprints work or ask for a quote against your own scope.