Building an app MVP. A focused product, not a cheap one.
The term MVP has been corrupted into shorthand for “small budget” or “half-finished app”. A real MVP is the smallest product that tests a genuine hypothesis with real users. Get that distinction right and you save yourself the cost of building the wrong thing.
An MVP is a strategic tool. Not a rough draft of the real thing.
An MVP is not a rough prototype. It is not a feature-light version of a bigger idea. And it is not a way to spend less money on development while calling it something clever. It is the minimum product required to test whether your core assumption is correct.
Built well, an MVP answers the single question that determines whether the full product is worth building. Built poorly, it costs nearly as much as a proper build and tells you nothing useful. Founders who treat the MVP as a discount version of the real product often end up spending the money twice, once on the version that proved nothing and again on the version they should have built in the first place.
This guide covers what a genuine MVP involves, how to scope one correctly, what it costs, and the mistakes that turn a useful experiment into an expensive one. It is written for founders who have been told to “build an MVP” without a clear idea of what that means, and for founders who are trying to scope one and struggling to know what to keep in and what to leave out.
Learning how to build an MVP well starts with the same discipline that goes into any serious product. What changes is the scope, not the standard.
What is an MVP?
The original definition, from the person who coined the term, is precise. An MVP is the smallest version of a product that allows a team to collect the maximum amount of validated learning about customers with the least effort. The important words in that sentence are “validated learning”. Not “cheapest build”. Not “fewest features”. Validated learning.
That definition matters because it tells you what the MVP is defined by. It is defined by what it needs to prove. Not by what it leaves out. Two founders working on similar ideas can arrive at completely different MVPs because they are testing different assumptions. The scope of the MVP is a consequence of the hypothesis, not a starting point on its own.
A prototype is not an MVP. A prototype tests a design assumption. It answers questions like “does this flow make sense?” or “can a user complete this task without help?”. An MVP tests a business assumption. It answers questions like “will people use this?” or “will people pay for this?”. They are different tools for different jobs, and confusing them costs founders time and money.
An MVP is also not a v1. A v1 is a product. It is designed to be used, retained, and grown. An MVP is an experiment. It is designed to be launched, measured, and learned from. Treating your MVP as if it were a v1 tends to inflate the scope until it is neither one thing nor the other, an experiment too heavy to run cheaply and a product too rough to keep users.
What your MVP needs to prove.
This is the section most founders skip, and it is the section that determines whether the money spent on the MVP was well spent or wasted. Before scoping an MVP, define the hypothesis it is testing. Write it down as a single sentence. What is the core assumption that, if wrong, means the full product should not be built? That question is the one the MVP exists to answer. Every feature, flow, and interaction should either test that assumption or support the test. Everything else is out of scope.
Identifying the core hypothesis takes real thought. Founders tend to arrive with a product idea and a list of features. The hypothesis is usually hiding underneath. It sits at the layer of “people in this situation will change their behaviour to use this tool” or “users will pay this much to solve this problem” or “this audience will trust this kind of product with this kind of data”. Work backwards from the features to find the assumption they depend on. That assumption is what the MVP tests.
Validated learning looks different from vanity metrics. A thousand sign-ups from a launch push tells you something about your marketing, not your product. A hundred users who actively return and complete the core task tells you something about your hypothesis. The metric you choose to measure has to map back to the assumption you are testing, or the results are decorative.
Testing the wrong hypothesis with a well-built MVP is a common and expensive failure. A team builds a polished MVP, launches it, gets weak engagement, and concludes the idea does not work. Often the idea was fine. The MVP tested whether people would download the product, not whether they would use it in the way the business model required. “Will people use this?” and “will people pay for this?” are entirely different hypotheses, and they need different MVPs to test them properly.
How to scope an MVP.
Practical guidance on what goes in and what stays out, and why the design work is not optional.
Start with the user’s core job. What is the single thing your product must enable? Not the five things it could enable, not the range of related things it might do one day. The one thing that, if it works, proves the assumption. Everything in the MVP either serves that job or supports the test around it.
Apply the ruthless prioritisation test to every proposed feature. If removing this feature does not compromise the hypothesis test, remove it. Not “reduce” it, not “simplify” it. Remove it. The temptation is to keep small features because they feel harmless. In aggregate they push the build out, dilute the user’s attention, and make the results harder to interpret.
The most important point on this page follows. An MVP built on poor UX does not test the product. It tests the UX. If your onboarding is confusing, users will drop out for reasons that have nothing to do with your idea. If your core interaction is awkward, engagement will be low regardless of how good the underlying concept is. The results will look like the idea failed. The idea did not fail. The design did.
This is why saving money by cutting the design work is the wrong economy. A focused MVP still needs a validated brief, considered UX, and a design that stays out of the user’s way. The scope is narrower than a full product. The standard of thinking behind it is not. Scope creep tends to happen quietly, one feature at a time, each one justified individually. Prevent it by writing the hypothesis down at the start and referring back to it whenever a new feature is proposed.
WAA’s strategy phase defines MVP scope before any design or development begins.
We work out exactly what the MVP needs to prove, then scope only what is required to prove it.
How much does an MVP cost?
Realistic ranges for the UK market, and the cost driver most founders underestimate.
| Budget band | What you actually get | What to expect |
|---|---|---|
| Under £15,000 | Off-the-shelf template, no-code assembly, or a very rough prototype built in isolation. | Usually too rough to generate valid results. The design will get in the way of the test. |
| £30,000 to £50,000 | Focused strategy, considered UX and UI, single-platform build for a tightly scoped hypothesis, basic testing, launch. | The realistic floor for an MVP that can produce a valid answer. |
| £50,000 to £80,000 | More involved hypothesis, richer interactions, integrations where the hypothesis genuinely requires them, thorough testing. | Where most well-scoped MVPs actually land. |
| Above £80,000 | Multi-platform, complex data or hardware, regulated environments. | Usually a sign the scope has drifted beyond what an MVP should be testing. |
The biggest driver of MVP cost that founders underestimate is the strategy and design work required before development begins. Development is the visible cost. The thinking that makes the development worthwhile is the one that gets cut when the budget feels tight, and it is the one that determines whether the money spent on development produces a valid test or a very expensive false negative.
A focused MVP still needs a validated product brief, considered UX, and a design that does not undermine the test. You can build a narrower scope. You cannot skip the work that makes the narrower scope worth building.
Should you choose a Native app or web app for your MVP?
The right answer depends on what your hypothesis actually needs to test. Not on which technology is fashionable.
Best when the native experience is the point.
Higher cost. Better user experience. Required when native features such as camera, location, or push notifications are core to the hypothesis you are testing. If the value depends on the phone being a phone, build native.
Best when the hypothesis is about the value, not the format.
Lower cost. Faster to build. Sufficient when the hypothesis is about the value proposition itself rather than the native experience. A well-built PWA covers a surprising amount of ground for MVP-stage validation.
Best when speed of learning matters most.
Fastest and cheapest. Appropriate when the speed of learning matters more than the quality of experience. The caveat is real. Poor UX invalidates the results, so no-code only works when the tools can support a genuinely usable product.
The choice sits with the hypothesis. If the assumption you need to test depends on the native experience, save the money elsewhere and build native. If the assumption is about whether the value proposition works at all, a web app or a well-executed no-code build will get you the answer for less. The wrong build approach can invalidate the test as easily as poor UX can.
Common MVP mistakes.
The failure modes we see most often. Each one is preventable, and each one turns a useful experiment into an expensive one.
Want to scope your MVP properly before committing to a build?
A short conversation is usually enough to work out the hypothesis and what the MVP needs to include to test it.
The MVP questions founders ask us most.
Do I need an MVP or can I go straight to a full build?
It depends on how much validated evidence you already have that the core assumption is correct. If real users are already paying for a manual version of what you want to automate, and you understand exactly what they value about it, you have a stronger case for skipping the MVP and building the v1. If the core assumption is unproven, a full build is a large bet against yourself. The MVP exists to reduce that risk before the money is committed.
How long does an MVP take to build?
Typically three to six months from the start of strategy work through to a launched product ready to gather results. The range depends on the scope of the hypothesis and the build approach. A tightly scoped web app can move faster. A native build with a more involved interaction takes longer. Anything under three months usually means the strategy and design work has been cut, which is where the value of the MVP is decided.
What happens after the MVP?
You analyse the results against the hypothesis you wrote down at the start. There are three honest outcomes. Validate and build further into the full product. Pivot the assumption, adjust the scope, and retest. Or stop, because the evidence says the idea does not work as it stands. You can read more about the full arc in Creating an App, and the strategy work that sits behind the MVP itself in App Planning & Strategy.
Should I get the full app designed before building the MVP?
No. Designing the full app before the MVP has run assumes you already know what the results will say, which defeats the point of running the test. The MVP should be designed properly, with the same standard of thinking behind its UX and UI as a full product, applied to a narrower scope. Once the hypothesis is validated, you design the wider product with the evidence in hand. That is a very different exercise from designing it on assumptions.
Three ways to start.
Whether you know exactly what you want to build or you are still shaping the hypothesis, there is a way in that suits where you are.
Send us the project details.
If you already have a brief, a hypothesis, or a scope in mind, tell us what you are trying to prove and what stage you are at. We will come back with a considered response.
Send project details →Book a call.
Thirty minutes with a WAA strategist to talk through the idea, the hypothesis, and what a properly scoped MVP might look like for it.
Book a call →See what an MVP costs.
Detailed pricing for the strategy, design, and build phases that make up a well-scoped MVP, so you can plan the investment before you commit.
See pricing →