How to Build an MVP: Steps, Timeline & UK Costs (2026)

To build an MVP, you find the one assumption that would sink your idea and build the smallest real product that tests it. Then you release it to a small group and measure what they do, against a result you set before launch.

In the UK, our published prices are from £5,000 for 2–4 weeks of validation and design, and from £15,000 for an MVP build that goes live in around three months. Both are fixed before work starts. This guide covers the six steps, how long they take, what they cost, who should build it, some real examples and the mistakes we steer founders away from. The definitions are in our guide to proof of concept vs prototype vs MVP.

Key takeaways

• Start with the assumption that would sink the idea, then build only what tests it. Every other feature waits.
• Six steps get you there: name the riskiest assumption, cut the features, design the core flows, build, launch to a small group and measure against a result set in advance.
• Our published prices are from £5,000 to validate and design (2–4 weeks) and from £15,000 to build, live in around three months. Maintenance after launch is from £400 a month.
• A no-code or AI-built first version is a fair test. When real users, payments or personal data arrive, have it audited for production.
• Decide what counts as success before you launch, or every result will look like a win.

How do I build an MVP? Six steps

The six steps are to name your riskiest assumption, cut the feature list, design the core flows, build, launch to a small group and measure. Each one removes a way of wasting money on the next.

1. Name the problem and your riskiest assumption

Write down who has the problem, how they cope today and the one belief that must be true for your idea to work. It might be that people will pay, that they will switch from what they use now, or that the technology can do the job. The GOV.UK Service Manual gives similar advice for its alpha phase, where teams build prototypes, test different ideas and identify and test their riskiest assumptions.

Talk to people who have the problem before you build anything, and ask how they cope today rather than whether they like your idea. Sometimes the test is cheaper than a product. A landing page with a sign-up form, a spreadsheet you run by hand or a service you deliver manually can answer the demand question in days.

In his 2009 guide to the MVP, Eric Ries describes a feature his team spent two weeks building that nobody wanted. He writes: “At a minimum, a simple AdWords smoke test would have revealed how utterly bad the concept was.”

2. Cut the feature list to what tests it

List every feature you can imagine, then keep only what the first user needs to complete the one job your assumption depends on. Everything else goes on a later list. Anything you can do by hand behind the scenes, such as approving sign-ups or raising invoices, stays manual for now.

A small product still needs to work. Ries also wrote: “MVP, despite the name, is not about creating minimal products.” We read that as a reminder that people can only give you a fair answer if the product works well enough to use.

Our validate and design stage ends with an honest call on what to build, cut or defer. You also get a build-ready spec and a fixed quote for the full build.

3. Design the core flows

Design the screens and the path a user takes, including the empty states and the error messages. Put a clickable prototype in front of real users before any code is written, because changes are quicker and cheaper on a prototype than in built software.

A prototype can also be the first version when the question is whether people and investors want the product. For Fix My House, a home-improvement marketplace, we delivered a high-fidelity interactive Figma prototype in weeks, so the idea could be validated with users and investors before funding development.

If you are unsure what to build first, a discovery sprint takes 1–2 weeks and starts from £4,000.

4. Build the smallest real product

Build in stages, so there is something usable at the end of each one, and keep the first release to as few platforms as your test allows. A single codebase serving both iOS and Android is usually the right economics for an MVP.

Simple PT is the example we point to. The client had a tight budget, so we built a deliberately lean MVP in stages, and the booking-and-payments app was live on both app stores two months from kick-off.

Make sure you own what you pay for. With us, all code and IP are yours once the work is delivered and paid for. You pay by milestone as each stage is delivered, never a large sum up front.

5. Launch to a small group first

Release to a limited group before you open the doors. The GOV.UK beta guidance starts with a private beta, “inviting a limited number of people to use your service”. That lets you collect feedback and fix problems while the audience is small.

Choose people who have the problem, tell them it is an early version and make it easy for them to reach you. A small group who use it every week teach you more than a large one that signs up and vanishes.

6. Measure what people do, then decide

Before launch, write down the result that counts as a yes. For example, you might set how many of your first group complete the core task and how many come back the following week. The numbers are yours to choose, and they have to be set in advance. The same beta guidance tells teams to gather data against the success metrics they set earlier.

Measure behaviour rather than compliments or raw sign-up totals. Ries notes that learning from a first version takes real effort, in talking to customers and reading the metrics. The outcome is one of three decisions: build on it, change direction or stop. The aim is a decision you can defend with what you saw.

How long does it take to build an MVP?

Our MVP build goes live in around three months, with design, development, testing and launch included. If you want the idea tested first, validation and design takes 2–4 weeks, and a discovery sprint takes 1–2 weeks. The table shows what you end with after each stage.

Stage	You end with	Time with us
Discovery sprint	A validated, costed product plan	1–2 weeks
Validate & design	A tested idea, designed flows, a fixed quote	2–4 weeks
MVP build	A live product with real users	Around three months

A lean, staged build can be quicker. Simple PT was live on both stores two months from kick-off, and the Fix My House prototype took weeks. Timelines slip for ordinary reasons, such as features added mid-build, slow feedback and third-party systems that behave differently from their documentation.

For comparison, the GOV.UK Service Manual says alphas tend to last between 6 and 8 weeks. Those are public services, so treat that as context rather than a target.

How much does it cost to build an MVP in the UK?

With us, an MVP costs from £5,000 to validate and design the idea and from £15,000 to build and launch it. Scope and price are fixed and agreed before work starts, and you pay by milestone as each stage is delivered. The table sets those next to the do-it-yourself route. Third-party prices are as listed at the time of writing (October 2026).

Route	Price	What it buys
DIY on Bubble	Free plan; web Starter $32 a month, billed annually	A first test you run yourself
Validate & design with us	From £5,000	Idea tested, flows designed, fixed quote
MVP build with us	From £15,000	A live product in around three months
After launch with us	From £400 a month	Maintenance and support

The word “from” matters. The price rises with the number of features, user types, integrations and platforms, and with how much the backend has to do. Our guide to how much an app costs in the UK explains each driver, and software development cost in the UK covers web applications and internal systems. On an MVP build you can cancel within the first 21 days and get your money back in full.

Some costs sit outside the build. Apple lists its Developer Program at 99 USD per membership year, or in local currency where available, and Google Play charges a US$25 one-time registration fee. Hosting and services such as payments, email or maps usually bill by usage.

If your MVP holds personal data, the ICO says organisations (including sole traders) that use personal information need to pay a data protection fee, unless they are exempt. Check the ICO’s guidance for the amount that applies to you.

Who should build your MVP?

The right builder depends on how technical you are and how well defined the test is. There are four routes.

• Yourself, with no-code or AI tools. This suits a test you can click through or a workflow you can run by hand. If a landing page or a manual service can answer your question, run that first. It costs less than any build, including ours.
• A freelancer. This suits a well-defined job where you or an adviser can specify and review the work. You carry the gaps, such as design, testing and hosting.
• An agency. A team covers design, build, testing and launch. Ask whether the price is fixed and who owns the code at the end.
• An in-house hire. This fits when the product is the company. Your first hire needs to be a technical lead, or to have one beside them.

Our guide to hiring an app developer compares the freelancer, agency and in-house routes side by side.

When your no-code or AI-built MVP needs to go to production

Many founders now build a first version themselves with tools such as Bubble, Lovable, Bolt, Cursor or Replit. That is a sensible way to test an idea, and it is often all the first version needs.

The signs that it is time for more are practical. Real users are depending on it, it holds personal data, it takes payments, or it gets harder to change with every feature you add.

Our vibe code rescue starts with a one-week rescue audit at £3,000. It reviews security, authentication and the data model, and assesses architecture and test coverage on your real codebase. It ends with a go, save or rebuild verdict, and there is no obligation to continue.

After the audit, the rescue build starts from £8,000. It hardens what is worth keeping, rebuilds the risky parts, adds authentication, automated tests and monitoring, and ships to production. Sometimes a clean rebuild is faster and cheaper, and the audit says so.

Minimum viable product examples and what they teach

Well-known examples show how small a first version can be. These come from press reports and the companies’ own timelines, and each teaches something different.

• Dropbox. According to TechCrunch’s 2011 founder story, Dropbox released a video on Digg during its private beta launch and “had 75,000 people signup for the wait-list” within 24 hours. TechCrunch adds that Dropbox screened who could try early versions through a closed beta rather than risk a buggy product on all of them. The sign-up count was a result it could act on, and access could be rationed.
• Zappos. Founder Nick Swinmurn told Fortune in 2012 about the deal he made with a shoe store in Sunnyvale, California. He told the store: “I’ll take some pictures, put your shoes online, and if people buy them, I’ll buy them from you at full price.” A few orders followed. The first version was a simple storefront with a manual process behind it.
• Airbnb. The company’s own timeline says two of its founders, Brian and Joe, hosted the first guests in October 2007. Airbed & Breakfast launched during SXSW in March 2008 and received “just two bookings”. Its website launched in time for the Democratic National Convention in August 2008 and got 80 bookings. The first signals were small, and real use is what made them useful.
• Our own work. Simple PT shows a lean, staged build reaching both app stores, and Fix My House shows a prototype used to test an idea before funding. The first answers whether people will use it, and the second answers whether people and investors want it.

Common MVP mistakes

These are the mistakes we would steer you away from, and most come from skipping a step above.

• Testing nothing in particular. Without a named riskiest assumption, the launch produces opinions rather than evidence.
• Building for everyone. A long feature list slows the moment you start learning, and it makes the result harder to read.
• Launching without a success threshold. If you decide afterwards what counts as good, almost any result passes.
• Counting compliments. Praise and sign-ups cost users nothing. Whether they complete the core task and return is a better signal.
• Calling a clickable prototype an MVP. A prototype tests understanding and appeal. An MVP is live and used by real people.
• Forgetting life after launch. Fixes, updates and hosting continue. Maintenance and support start from £400 a month with us.

Your next step

Write your riskiest assumption in one sentence, and the result that would convince you it holds. If you can do both, you are ready for the validate and design stage of our MVP development, from £5,000 over 2–4 weeks. It ends with a fixed quote for the full build, from £15,000.

If you cannot yet say which assumption matters most, start with a discovery sprint instead. You can also send us the idea, and we will say honestly whether it needs building at all. If you have already built something with an AI tool and it is straining, the rescue audit is the place to begin.