How to scope an MVP you can actually afford

An affordable MVP is not a cheap version of your product. It is the smallest thing that lets one real user complete one valuable job, built so that you learn whether anyone wants it. Everything else — roles, settings, admin screens, integrations — is deferred on purpose, and most of it can be done by hand at first.

What an MVP is not

Three things it gets confused with, all of which cost more:

A prototype. A clickable design that nobody outside your company can use. Useful for testing a concept with a customer, useless for testing demand.

Version one of the real product. If the scope is "the product, but with fewer features", you have not cut anything structural — you have just made everything slightly worse.

A demo. Something that works if you drive it carefully and breaks if anyone else touches it.

An MVP has to survive contact with a real user doing a real job, and it has to produce evidence. Those two constraints are what make it minimum and viable.

The one-sentence test

Write this sentence and fill in the blanks:

A [type of user] can [complete one specific job] and gets [a specific outcome].

If you cannot fill it in without using "and" more than once, you are not scoped yet. If you need three sentences, you have three MVPs and should pick the one that answers the riskiest question.

The riskiest question is the point. You are not building to have a product; you are building to find out whether the thing you believe about your market is true. Scope towards that.

This is not a fringe view. The GOV.UK Service Manual describes the alpha phase of a project in almost the same terms — "a crucial part of alpha is identifying your riskiest assumptions and testing them" — and tells teams to build only what is complex enough to test an idea, expecting to throw the code away afterwards (GOV.UK Service Manual, how the alpha phase works). Government digital teams with far larger budgets than yours plan to discard their first build. An SME cannot afford to skip that step and call the first build the product.

How to cut scope

Four questions, applied to every feature someone proposes:

Does the core job fail without it? If a user can still complete the sentence above, it is not in v1.

Can a person do it manually at low volume? Ten sign-ups a day can be approved by hand. Ten thousand cannot. Build for the volume you actually have.

Is it there because a competitor has it? Competitor parity is the most expensive reason to build anything, and the least evidenced.

Would we build it if we knew the MVP would fail? If yes, it is infrastructure and might be justified. If no, defer it.

Applied honestly, these four questions usually remove between a third and half of an initial feature list.

Build the job, fake the machinery

The most effective cost control in software is doing things manually behind the scenes.

If your product is meant to generate a tailored report, have someone generate the first fifty by hand while the front end looks finished. If it is meant to match buyers with suppliers, do the matching in a spreadsheet. Users get the outcome they came for; you get a working understanding of the rules the automation will eventually need — rules you would otherwise have guessed at, expensively.

This is not a trick and it is not dishonest, provided you are not claiming an automation that does not exist. It is how a surprising number of well-known products started, and it converts a large speculative build into a small one plus some human effort you can stop at any time.

Automate when the manual work genuinely hurts. That moment tells you both what to build and that it is worth building.

What does an MVP cost?

The honest answer is that it depends on scope, but you can anchor it.

At the median UK mobile developer contract rate of £388 a day in the six months to 1 September 2026 (IT Jobs Watch), a six-week build for a single developer is roughly £11,600. Add design, testing and project management and a realistic small-team six-week engagement sits above that. Our full breakdown of app development costs sets out the bands, and how we build a SaaS MVP in six weeks describes the shape of the work.

The number that matters is not the total. It is whether you could fund a second version after discovering the first was wrong — because you probably will. An MVP that consumes your entire budget has failed at its main job, which is to make being wrong survivable.

The deliberate omissions list

Write this list down and get everyone to agree to it before work starts. Typical contents:

• Admin panel — use the database or a manual process
• Settings and preferences — pick sensible defaults
• Onboarding flow — talk to your first users personally
• Notifications — send them by hand at first
• Second user role — build one, well
• Integrations — export a CSV
• Billing — invoice manually until the volume hurts

Each of these is genuinely useful eventually. None of them tells you whether anyone wants your product.

Decide in advance what success looks like

The most common failure in MVP projects is not technical. It is that nobody defined what would count as a result, so the launch produces ambiguous data and the answer becomes "let's add a few more features and see".

Before building, write down two numbers: the one that means continue, and the one that means stop. Sign-ups, completed jobs, repeat usage in week two, or people actually paying. Make them specific and put them somewhere you cannot quietly revise them.

An MVP without a stopping condition is not an experiment. It is the first instalment of an open-ended build, and it will be priced like one.

If you want this pressure-tested before committing, our SaaS and product work starts with exactly this scoping conversation, and the wider app development page covers what comes after.

Frequently asked questions

What actually counts as an MVP?

The smallest thing you can build that lets a real user complete one valuable job end to end, and that produces evidence about whether they want it. If it cannot be used by someone outside your company, it is a prototype. If it does five jobs, it is a product.

How much should an MVP cost?

Less than you can afford to lose. As a rough anchor, a six-week build at the September 2026 median UK mobile developer contract rate of £388 a day is around £11,600 for a single developer — real projects vary widely with scope and team shape. The important number is not the total but whether you could fund a second version after learning the first was wrong.

What should we deliberately leave out?

Admin panels, settings screens, onboarding flows, notifications, integrations, and every role beyond the first one. Most can be done manually behind the scenes at low volume, and doing them manually teaches you what to build later.

Is it cheating to do things manually behind the scenes?

No, it is the single most effective cost control available. If ten users a day need a report generated, someone generating it by hand teaches you what the automation should do and costs a fraction of building it speculatively. Automate once the manual work genuinely hurts.

How do we know whether the MVP worked?

Decide before you build. Write down the number that would make you continue — sign-ups, completed jobs, repeat use, willingness to pay — and the number that would make you stop. An MVP with no stopping condition is just the first instalment of an open-ended build.

---

Easy Insight is a UK consultancy for AI, web, apps and data — senior specialists only, no juniors.