How to build an MVP in the UK: scope, cost and process.

Start with the question, not the feature list

Founders often arrive with a long list of screens and features because that feels like progress. The stronger starting point is the uncertainty the first release needs to reduce.

Examples include:

• Will a specific customer group complete this workflow?
• Will businesses pay for this outcome at a viable price?
• Can this technically difficult step be made reliable enough?
• Does moving the current manual service online improve capacity or margin?
• Which part of the proposition creates repeat use?

The product should be designed around answering that question. Anything that does not help deliver the core value safely, operate the service or measure the result is a candidate for later.

Prototype, proof of concept and MVP are different

Stage	Purpose	Typical audience
Prototype	Explore an experience or communicate how the product could work.	Founders, stakeholders and research participants.
Proof of concept	Test whether a difficult technical assumption is feasible.	Product and technical teams.
MVP	Deliver the core outcome to real users and collect market evidence.	Early customers or a controlled live cohort.

Confusing these stages wastes money. A polished prototype does not prove the system can operate. A technical proof does not prove anybody wants the product. An MVP must be usable enough to test the real proposition.

How to define the minimum scope

Write the core journey in one sentence

Use this structure: “A [specific user] can [complete valuable outcome] by [essential interaction].” If the sentence needs several “ands”, the first release may be trying to validate too much.

Separate product value from operating needs

The user's core journey is only part of the build. A live product may also need authentication, basic administration, support tooling, analytics, backups, error handling, consent and security controls. These do not make the proposition exciting, but they make the release operable.

Use a hard prioritisation test

For every proposed feature, ask:

1. Does the user need it to reach the core outcome?
2. Does the business need it to deliver the service safely?
3. Do we need it to measure the main assumption?

If the answer is no to all three, move it out of the MVP.

What an MVP should not cut

Minimum does not mean careless. Cutting the following can invalidate the test or create avoidable harm:

• Security and privacy. A smaller product still needs appropriate access controls, data handling and backups.
• The complete core journey. Users cannot validate an outcome they cannot finish.
• Basic reliability. If the product regularly fails, feedback measures implementation quality rather than demand.
• Measurement. Without analytics, interviews or operational data, the release produces opinion rather than evidence.
• A support route. Early users need a way to report confusion and problems.

How much does MVP development cost in the UK?

A focused bespoke MVP commonly starts in the low five figures. A more involved web platform or mobile product can move into the mid five figures and beyond. A single generic number is misleading because two products with the same number of screens can have very different engineering requirements.

The main cost drivers are:

• number of user types and permission levels;
• web application, native mobile apps or both;
• payments, subscriptions and marketplace logic;
• third-party systems and unreliable external APIs;
• data migration, search or reporting;
• regulated, sensitive or safety-critical information;
• complex AI, realtime, offline or media features;
• the amount of uncertainty still left in the brief.

For a wider view of UK custom software pricing, read how much bespoke software development costs.

A practical MVP development process

1. Problem discovery. Define the audience, current alternative, value proposition, risk and evidence the first release must produce.
2. Scope and prototype. Map the core journey, test the interface and remove features before they become code.
3. Technical proof where needed. Test uncertain integrations, AI behaviour, performance or device capability early.
4. Incremental build. Deliver working slices of the journey so decisions are based on the product, not progress reports.
5. Release preparation. Add operational controls, analytics, support, deployment and any app-store material.
6. Controlled launch. Start with the audience most likely to give relevant feedback and support them closely.
7. Evidence review. Compare behaviour with the original assumptions and choose what to improve, remove or test next.

The UK's agile delivery guidance describes an MVP as the minimum functionality required to launch safely, learn from users and improve over time. “Safely” and “learn” are both essential.

How long should it take?

A focused web or mobile MVP can often be delivered in roughly 8 to 16 weeks after the initial discovery and scoping work. Simpler products may move faster. Multiple apps, complex integrations, regulated data, hardware dependencies or unresolved product questions extend the timeline.

Speed comes from reducing scope and uncertainty—not from pretending important work does not exist. A clear eight-week build is better than a promised four-week build that becomes twelve.

Common MVP mistakes

Building for every future customer

The first version needs one coherent audience. Trying to support consumers, enterprise buyers, administrators and partners at once multiplies workflows and makes the evidence difficult to interpret.

Using “MVP” to excuse poor quality

Users will tolerate a narrow product. They will not reliably validate one that loses data, breaks frequently or looks unsafe.

Automating the unknown too early

Manual work behind the scenes can be sensible while volume is low and the process is still changing. Automate the stable, expensive parts after learning where they are.

Choosing technology before the product shape

The right stack follows from the users, platforms, integrations, team and growth assumptions. Starting with a fashionable framework or AI feature can bend the product around the tool.

Failing to define the decision after launch

Agree in advance what evidence would justify investment, iteration or stopping. Otherwise every result can be rationalised as a reason to keep building.

How Polyphasic Developers approaches MVPs

We build bespoke MVPs for founders and SMEs across web and mobile. Our job is not to maximise the first specification. It is to help find the product small enough to ship, complete enough to be credible and sound enough to grow if it earns the opportunity.

That may involve AI-assisted prototyping and development, but the advantage comes from better decisions and faster learning. Read how we work as an AI-first software development company.

Frequently asked questions

Can an MVP use no-code tools?

Yes, if the product and data fit the platform and the limitations will not distort the test. Bespoke development is more suitable when the core value depends on unusual workflows, integrations, performance, ownership or a differentiated experience.

Should we build a web app or mobile app first?

Choose based on the core context of use. Web is often faster to distribute and update; native mobile is stronger when the product depends on device capabilities, frequent personal use, offline operation or app-store discovery. Our web app vs mobile app guide explains the trade-offs.

Do we need a complete specification?

No. You need a clear problem, audience and commercial context. Discovery turns that into a scoped product and identifies the assumptions that should be tested before or during the build.