MVP Development: How to Scope and Build a Minimum Viable Product

MVP development means building the smallest version of a product that does its main job well enough for real users to use and, ideally, pay for. It’s a real product with fewer features, not a prototype. Good MVP development starts by writing down the one job the product does, then cutting everything that doesn’t serve it.

The term was popularised by Eric Ries in The Lean Startup. It is also one of the most misused ideas in software: “MVP” gets stretched to mean a rough demo, or quietly grows into a full product that takes a year. This guide explains how we scope first versions with clients, what they need behind the screens, and how to plan what comes after launch.

What is a minimum viable product?

A minimum viable product has three properties:

• Minimum: it does as little as possible. One core job, for one main type of user.
• Viable: it does that job well enough that real people will use it without you standing next to them. It is reliable, secure and looks trustworthy.
• Product: it is live, in real users’ hands, with real data, so you learn from behaviour rather than opinions.

The purpose is learning. An MVP answers a question such as “will restaurants pay to take bookings this way?” or “will field staff use an app instead of paper forms?” with evidence, before you invest in the full product.

MVP vs prototype vs proof of concept: what’s the difference?

Mixing these up is expensive. A prototype released as an MVP falls over under real use; an MVP built like a proof of concept has to be rebuilt before it can grow.

How do you decide what goes into an MVP?

This is where most of the value is, and where most first versions go wrong. The method we use:

1. Write the one-job statement. One sentence: who the user is, what they get done, and why it is better than what they do now. “Let independent physiotherapists take bookings and payments online without phone calls” is a job. “A healthcare platform” is not.
2. List every feature anyone has suggested. Get it all out; nothing is decided yet.
3. Cut hard. For each feature, ask: can a user complete the one job without it? If yes, it moves to later. Loyalty schemes, social sharing, dashboards, multiple languages and “admin reports we might need” nearly always wait.
4. Pick one platform where possible. A web app or one mobile platform first, unless the job genuinely needs both.
5. Do things manually behind the scenes. Many MVP features can be a person doing the work at first: approving accounts, sending a weekly report, matching orders by hand. Automate once you know it’s needed.
6. Write down release two now. The features you cut need a home, or they creep back in during the build.

A useful test: if the feature list still reads like a finished product, it isn’t an MVP yet.

What does an MVP need behind the screens?

The screens are the visible part. These are the parts people forget to plan for, and the reason many “quick” MVPs take longer than expected:

• A backend and database that store users, data and transactions reliably.
• Authentication that is secure: password resets, email verification and sensible session handling.
• A basic admin area so your team can see users, fix data and handle support without a developer. It can be plain, but it needs to exist.
• Analytics that measure the one thing the MVP is testing. Without them, you launch and learn nothing.
• Error monitoring and backups, so problems are noticed and data isn’t lost.
• The UK legal basics: a privacy notice under UK GDPR, cookie consent under PECR if you use non-essential cookies, terms of use, and the ICO data protection fee if it applies to you. If you take payments, use an established payment provider rather than handling card details yourself.
• Accessibility and mobile layout, because your first users will arrive on every kind of device.

None of this needs to be elaborate in an MVP. It does need to be there, because an MVP that leaks data or can’t be supported isn’t viable.

How long does MVP development take?

It depends on the scope you end up with after cutting, which is why the cutting matters so much. In general terms:

• Scoping (the one-job statement, the cut list, user journeys and a technical plan) usually takes one to a few weeks.
• The build runs in short stages, with something working to look at every week or two, so you can steer as you go.
• Testing and launch, including app store review if it’s a mobile app, needs its own time; don’t squeeze it out of the plan.

The biggest cause of delay isn’t development speed. It’s scope added mid-build. A fixed first release with a written list of what’s out helps more than any tool or methodology.

What happens after the MVP launches?

Launch is the start of the useful part:

1. Watch what users actually do. Compare it with the success measure you set before launch.
2. Talk to users, especially the ones who stopped using it.
3. Decide: carry on, change course or stop. All three are good outcomes if they are based on evidence.
4. Build release two from the evidence, not from the original wish list. Often the most-requested features aren’t the ones you cut.
5. Pay down the shortcuts you took on purpose. An MVP built on a sound base can grow; one built on throwaway code has to be rebuilt first.

Should you build an MVP in-house, with a freelancer or with an agency?

Whichever route you choose, insist on owning the code repository, hosting and store accounts from day one, and on documentation that would let another team pick the product up.

Planning your MVP

Before talking to anyone about building it, write one page: the one-job statement, who the first users are, the cut list, and what result after launch would make you carry on. That page will save more time than anything else in the project.

If you’d like help turning it into a plan, we scope and build first versions as bespoke software, web applications and mobile apps, including the backend and admin behind them, with the code owned by you. Tell us about your idea and we’ll suggest the smallest version worth building.