How Much Does It Cost to Build an App in the UK?
Realistic price ranges, what drives the cost and the running costs people forget.
Read articleIn this guide
Key takeaways
- An MVP is the smallest version that solves one real problem for one group of users.
- Map one core user journey end to end before listing features.
- Use MoSCoW to separate must-haves from everything else.
- Decide how you'll measure success before you build.
What an MVP is (and isn't)
A minimum viable product (MVP) is the smallest version of your product that solves one real problem well enough for real users to use it, and to tell you whether you're on the right track.
It isn't a cheap, broken version of the full idea, and it isn't a prototype nobody can use. Knowing how to scope an MVP is mostly about deciding what to leave out, so you can launch in weeks rather than months and spend your budget on what customers actually want.
Step 1: Define the problem and the user
Write one sentence for each of these before you think about features:
- Who is the first user? Be specific: "independent dental practices with one to three sites", not "businesses".
- What problem do they have today, and how do they solve it now?
- What outcome will make them choose your product over their current workaround?
Talk to five potential users before you write a feature list. Ask how they handle the problem today and what it costs them. Their answers will cut your scope more than any workshop.
Step 2: Map one core journey
Pick the single most important thing a user needs to do, and map every step from start to finish. For a booking app, that might be:
- Find a service and an available time.
- Enter their details.
- Pay or confirm.
- Receive a confirmation and reminder.
- The business sees the booking and manages it.
Anything not needed to complete this journey is a candidate for a later version. Don't forget the admin side: someone in your team has to manage the data behind the scenes.
Step 3: Prioritise features with MoSCoW
List every feature you can think of, then sort each one into a group:
| Group | Meaning | Example |
|---|---|---|
| Must have | The core journey doesn't work without it | Booking a time slot |
| Should have | Important, but there's a workaround for now | Automatic reminders |
| Could have | Nice to have if time allows | Saved favourite services |
| Won't have (yet) | Agreed to leave out of this version | Loyalty points |
Your MVP is the "must haves", plus perhaps one or two "should haves" that make it pleasant to use. Writing down the "won't haves" matters: it stops them creeping back in halfway through the build.
Step 4: Choose the simplest way to deliver it
- Use proven tools for payments, logins, email and maps rather than building them from scratch.
- Consider a web app first if people won't use it daily. Our guide to mobile apps vs web apps explains the trade-offs.
- Do some things manually at first. If ten orders a week need a human check, that's fine for an MVP.
- Keep design consistent and simple, using a clean component system rather than bespoke screens everywhere.
Step 5: Set success measures and a timeline
Decide before you build what will tell you the MVP is working, for example:
- Number of active users after four weeks.
- Percentage of users who complete the core journey.
- Number of paying customers, or pre-orders.
- What users ask for most in feedback.
A focused MVP usually takes around 10 to 12 weeks from discovery to launch. Working in two-week cycles, with a usable build at the end of each, keeps scope honest and shows progress early. To see how scope affects price, read our guide to app development costs.
Turn your idea into a planWe'll scope your MVP and give you a fixed price and timeline.
Get my free app quote Signs you're overbuilding
- The feature list has more than one "core" journey.
- You're building admin reports nobody will look at in the first month.
- Several user types, each with their own dashboard, in version one.
- Custom-built features that an existing service already does well.
- No date by which real users will be using it.
Minimum doesn't mean careless. Security, data protection and basic reliability are never optional, even in a first version. Cut features, not quality.
MVP scoping FAQs
How many features should an MVP have?
As few as it takes to complete one core journey well. For many products that's a handful of screens on the user side plus a simple admin area.
How much does an MVP cost?
It depends on the scope and platforms. Our own app MVPs start from £8,000, with a fixed price agreed after a discovery call.
Should an MVP be a mobile app?
Not necessarily. A web app or progressive web app is often quicker and cheaper for a first version, unless frequent use or device features make an app essential.
What happens after the MVP launches?
You measure how people use it, talk to users, fix what gets in their way and prioritise the next features based on evidence rather than guesses.
The bottom line
Knowing how to scope an MVP comes down to discipline: one user, one problem, one core journey and a short list of must-haves. Agree what you won't build, measure what happens after launch and let real users shape version two.