Most agency websites answer this question with “it depends” and a contact form. That’s technically true, but it isn’t useful if you’re trying to work out whether you need £15k or £150k before you have a conversation with anyone.
Here is a real range, the factors that actually move it, and enough detail to sanity-check a quote from anyone, including us.
The honest range
Across the MVPs we’ve scoped, first releases fall into three rough tiers:
| Tier | Price | Typical shape |
|---|---|---|
| Narrow, single-workflow MVP | £15k-£25k | One user role, one core journey, minimal integrations — a focused tool that does one job well, with just enough account and data handling to be trustworthy |
| Standard MVP | £25k-£40k | Multiple user roles or a journey with real branching, a handful of integrations (payments, one or two third-party APIs), and a proper admin or operational view |
| Compliance or integration-heavy MVP | £40k-£60k+ | Regulated data, identity verification, multiple system integrations, or workflows that can’t tolerate manual workarounds from day one |
These map to the £15k-£45k range we quote on our MVP development service, with the upper tier moving beyond it once compliance or integration count is high enough. Every serious agency’s numbers will land somewhere in this shape, because the underlying cost drivers are the same regardless of who’s building it.
What actually moves the price
Five factors decide which tier a given MVP falls into. In order of impact:
Scope. Every additional connected workflow, user role, or data domain extends build time. The single biggest cost lever is how disciplined the first release stays — not the technology choices underneath it.
Risk. Regulated data, financial transactions, health information, or safety-critical logic all require more validation, testing, and review before launch. A booking app and a payments app with an identical feature list are not the same price.
Integrations. Each third-party system — a CRM, a payment processor, an identity provider, a legacy internal tool — adds discovery time to understand its constraints, authentication work, and testing that has to happen against a system you don’t control.
Team shape. Senior-only delivery costs more per hour but needs less oversight, produces fewer rework cycles, and is less likely to leave you with a fragile foundation. Cheaper hourly rates don’t reliably mean a cheaper total, once rework is priced in.
Timing. A compressed timeline usually means a larger team working in parallel rather than the same team working faster, and coordination overhead grows with team size.
None of these are unique to how we work — they’re the actual mechanics behind any credible MVP quote. If a quote doesn’t move when you change one of these five inputs, that’s worth asking about.
What’s usually included in the range
A quote in the ranges above should typically cover:
- Scoping — reducing the idea to the smallest release that can produce a real answer to your key business question, not just a smaller feature list.
- Product design — the core journeys, interface system, and the states in between the happy path (empty states, errors, edge cases).
- Production engineering — authentication, data handling, integrations, tests, and a deployment process, built to be maintained rather than thrown away after launch.
- Launch preparation — analytics, basic monitoring, and enough operational visibility to know whether the release is actually working once real users touch it.
If a low quote is missing one of these four, it usually isn’t cheaper — it’s the same cost, deferred to after launch when it’s more expensive to add.
What can make it cost less
The scoping phase is where most of the controllable cost lives. A first release with one clear audience and a disciplined boundary is usually deliverable in four to eight weeks; a release trying to serve three future audiences at once rarely is, regardless of budget.
The cheapest MVP is the one where someone with delivery experience helped you decide what to leave out before engineering started, not after a sprint was already spent building it.
Questions worth asking before you accept a quote
Whether you talk to us or someone else, these questions expose whether a number is grounded or guessed:
- What specifically in our scope pushes this toward the top or bottom of your range?
- What happens to the price if we cut the second user role, or add one more integration?
- Who owns the code, design files, and infrastructure access after launch?
- What’s excluded from this number that we’re likely to need in the first three months?
- Can I see a past project with a comparable integration count or compliance profile?
A vague answer to any of these is a bigger risk signal than the number itself.
A worked example
One founder came to us with a roadmap that mixed customer onboarding, internal collaboration, reporting, and administration into a single “MVP.” Building all of it would have delayed the actual test — whether buyers wanted the core workflow at all — by months.
We separated launch-critical functionality from assumptions that could be tested manually, and delivered a production-ready core with analytics and a clear iteration path instead of a disconnected feature prototype. That’s the scoping work described above, applied — read the full case study for how the scope decisions were made.
If you have a rough idea of your scope, book a strategy call and we’ll give you a real range for your specific case, not a generic one, in the first conversation.