Minimum viable product development, step by step

Minimum viable product development is the process of building the smallest working version of a product, putting it in front of real users and learning from what they do. Done well, it shows you whether to scale, change direction or stop, before you spend the full budget.

The hard part of building a minimum viable product isn't the code. It's deciding what not to build. This guide shows how to build an MVP in eight steps, the same steps we follow with founders, from defining the problem to deciding what comes after launch.

What minimum viable product development means

An MVP, or minimum viable product, is the simplest version of your product that solves one real problem for one group of users. MVP development is everything needed to get it live: research, design, engineering, testing and launch.

It differs from building a full product in two ways. The scope is deliberately small, and the goal is learning rather than polish. Both decide how fast you can go. A focused MVP with one core user journey can go live in about a week. Products with several user roles, integrations or compliance needs take up to six.

Step 1: Define the problem worth solving

Start with one painful, real problem. Before you write a single requirement, answer three questions:

1. What is the one thing your target user struggles with?
2. Why does it matter to them now?
3. What single outcome would make them see the value straight away?

Keep the answer narrow. Instead of a full HR platform, build a leave request tracker. Instead of a property management suite, build a way for tenants to report repairs. Skip this step and the MVP turns into a small version of a full product, which costs more and teaches you less.

Step 2: Pick your first users

Don't build for everyone. Choose a first group of users who:

• have the problem often
• already show signs they'd pay to solve it
• are easy and cheap to reach and interview
• are open to trying something new

"HR managers at startups with 10 to 50 employees" is a first user group. "Businesses" isn't. A narrow group makes every later decision easier, from features to marketing.

Step 3: Prioritise features with MoSCoW

List every feature you can think of, then sort each one into four groups:

Only the must-haves go into the MVP. If that list runs past five or six features, look at it again. Most first versions need fewer than founders expect, and every feature you cut makes the build faster.

Step 4: Choose how to build it

There are three main routes, and the right one depends on what you need to prove.

Choose the route that tests your business, not the one that looks most impressive. Many founders start with no-code and move to custom code once the product has traction. If that's where you are, see how we take no-code and AI-built products to production.

Step 5: Design and prototype before you build

Design is where you find problems cheaply. Before any code is written, map the user flows, sketch low-detail wireframes and turn the key screens into a clickable prototype. Test it with five or six people from your first user group. At the same time, check that the riskiest technical parts are possible, and agree what "done" means for each feature.

By the end of this stage you should have a clear brief: flows, wireframes, a feasibility check and a fixed scope. For a focused MVP, this takes a day or two. Changing a wireframe takes minutes. Changing working code takes days.

Step 6: Build in agile sprints

MVP agile development means building in short cycles, each one ending with working software you can click through, not a progress report. That keeps the build honest and lets you change course early if something isn't working. On a fast build, a sprint can be a few days. On a longer one, it's usually two weeks.

An agile minimum viable product changes as you learn. Your scope is fixed, but within it, the order of the work moves to whatever matters most that week. This is what separates minimum viable product agile delivery from a fixed plan written months earlier.

How long the build takes depends on the scope:

These timelines are shorter than they were a few years ago. AI tools now write much of the routine code, and engineers review every line before it ships. The time saved goes into research, design and testing.

The biggest risk at this stage is adding features mid-build. Every new idea goes on a list for version two.

Step 7: Test with real users and launch

Launch quietly first. A soft launch to 10 to 30 people from your first user group is enough to learn from. Track three things:

• Do users complete the main action?
• Where do they drop off?
• What do they try to do that you didn't expect?

The goal of the first launch is learning, not marketing. Fix what blocks people, keep performance stable and save the wider launch for when the core works. Before you launch, make sure analytics track each step of the main journey, so you're measuring from the first user.

Step 8: Measure, then pivot or scale

After a few weeks of real use, look at the data and the feedback together. You'll usually take one of four paths:

• Refine: improve what's there until the main action is easy.
• Extend: add the one capability users keep asking for.
• Raise: use real traction to talk to early investors.
• Pivot: change direction based on what users actually did.

An MVP is the start, not the finish. The aim is to reach product-market fit as quickly as you can.

Common mistakes in minimum viable product development

• Building for everyone. A product for "small businesses" has no clear first user, so nobody feels it was made for them.
• Treating the MVP as version one of the full product. If the must-have list keeps growing, you're building a small full product, not an MVP.
• Skipping the prototype. Problems that a ten-minute test would have found get found in code instead, where they cost days.
• Launching without measurement. If you can't see where users drop off, you can't learn from the launch, and learning was the point.
• Choosing technology for the pitch deck. A stack that sounds impressive but that no one on the team knows slows everything down.

What to have ready before you start

You'll move faster, and get a firmer quote, if you can bring five things to the first conversation with a development team:

1. The problem, in one sentence.
2. Your first user group, as specific as you can make it.
3. Your must-have features, after MoSCoW.
4. A budget range, even a rough one.
5. The one number that tells you the MVP worked, such as sign-ups, bookings or paid conversions.

Our guide to writing an MVP brief a development team can work from goes into each one.

How long and how much

An MVP takes 1 to 6 weeks, depending on how complex the product is.

Cost is a separate question. In the UK, most custom MVPs cost between £6,000 and £30,000 at market rates, depending on scope, design and integrations. For a full breakdown, and our own tiers, read how much MVP development costs in the UK.

An example: building a minimum viable product with 40LOVE

40LOVE's tennis players were already using the platform in their phone browsers, but a web app couldn't give them live scores, push notifications or in-app payments. We started with user research, defined a narrow first version and built a cross-platform Flutter app for players, organisers and clubs, so iOS and Android shipped from one codebase.

Since launch, user retention has improved by 40%, more than 10 clubs have joined, and 40LOVE has raised a seed round. Read the 40LOVE case study.

Build your MVP with Exline Labs

Our MVP development services cover every step in this guide, from discovery to launch, with one in-house team. You get a fixed proposal within five working days of your discovery call.