Product Strategy
Every founder asks it, and “it depends” is a useless answer. Here's the real 2026 range for a UK build, the five things that actually set your number, how offshore and native change it, and the three places budgets quietly leak.
Two founders can both say “I need an MVP” and mean projects that differ in cost by a factor of five. One means a single working flow that proves people will pay. The other means “version one, minus the nice-to-haves,” which is a real product with a roadmap attached.
The term was coined to mean the minimum thing you can build to learn something specific. Over time it drifted to mean “the cheap first version.” Those are not the same. A learning-focused MVP might be one screen and a payment link. A “v1 minus extras” is ten screens, sign-in, an admin panel, and a support inbox.
Before anyone can price your build, you both have to agree which one you mean. We settle it on the first call with one question: what will you know after launch that you don't know now, and what's the smallest thing that teaches you that? If the answer is “whether people will book and pay for this,” you need the booking-and-paying flow and almost nothing else. If it's “we already know there's demand, we need to actually run the business,” that's a v1, and the number goes up accordingly. Fairly.
Getting this wrong is the single most expensive mistake in a first build, which is why we spend real time on it in product discovery before anyone quotes a build number.
For a focused product (one clear job, a small dedicated team, no unusual compliance load, starting from at least a basic brand) here's where UK agency pricing sits in 2026, phase by phase:
| Phase | Range | Timeline |
|---|---|---|
| Discovery and product strategy | £4,000 to £9,000 | 1 to 3 weeks |
| Design (flows, UI, lightweight system) | £8,000 to £18,000 | 2 to 4 weeks |
| Build (web app, 1 to 2 integrations) | £18,000 to £46,000 | 6 to 11 weeks |
| Typical first release, end to end | £30,000 to £75,000 | 9 to 16 weeks |
Those numbers line up with what other UK agencies quote publicly in 2026: most put a lean, well-built MVP between £20,000 and £80,000, with funded startups clustering around the £30,000 to £60,000 mark. The wide band is not vagueness. It is the difference between a genuinely single-flow product and one with five features, an admin dashboard, and two integrations.
| Scope | Rough 2026 cost | What that buys |
|---|---|---|
| Simple | £20,000 to £45,000 | 1 to 2 core features, web only, off-the-shelf auth and payments, one clear flow |
| Standard | £45,000 to £80,000 | 3 to 5 features, a basic admin dashboard, user management, Stripe, light reporting |
| Complex | £80,000 to £150,000+ | Multi-tenant, roles and permissions, several custom integrations, or heavy compliance |
Push past the top of your band if you need native mobile rather than a responsive web app, real-time features like live collaboration or tracking, serious compliance, or more than two or three integrations. Come in under it if it is genuinely one flow, you already have a designer or a design system, and you can commit to fast feedback.
Ignore the tech-stack debates for a minute. Five things drive most of the cost difference between one MVP quote and another.
How many distinct screens and states can a user reach? Not pages, states. A booking flow with a happy path, three error states, an empty state, and a confirmation is five things to design and build, not one. A five-screen product and a fifteen-screen product are genuinely different projects, and the cost roughly tracks the count.
Every external system you touch (payments, identity checks, a CRM, email, someone's API) adds work that never shows up in a Figma file: authentication, retry logic, handling the case where the other service is down, webhooks, and testing against their sandbox. One integration is a few days. Four integrations is most of a sprint, plus a tail of bugs that only appear in production.
If you're handling health records, financial data, or anything that falls seriously under UK GDPR, that shapes the whole build: consent capture, retention rules, access controls, audit logging, a data-processing agreement. It's not a privacy page bolted on at the end. Regulated MVPs cost more because the boring parts are load-bearing.
Starting from an existing brand, a component library, and a clear visual direction is dramatically faster than starting from a blank canvas. If we have to define your colours, type, and core components before designing a single screen, that's real time. Worth spending, but it's a line item. Design typically eats 15 to 25 percent of a first-build budget.
Invisible in a quote, enormous in reality. A project with one empowered decision-maker who replies within a day moves close to twice as fast as one where every choice goes to a committee. Part of your build cost is a function of your calendar.
A common surprise: writing code is not the biggest line. On a typical £50,000 MVP the split looks roughly like this.
| Line | Share | Notes |
|---|---|---|
| Discovery and strategy | 10 to 15% | Cheapest phase, highest return |
| Design and prototyping | 15 to 25% | Flows, UI, a small component system, user testing |
| Engineering | 40 to 50% | Front end, back end, integrations, deployment |
| QA and fixes | 10 to 15% | Often hidden inside “engineering” on cheaper quotes |
| Project management | 8 to 12% | The person keeping scope and timeline honest |
| Contingency | 5 to 10% | If a quote has none, it is somewhere else, unlabelled |
When a quote comes in suspiciously low, one of these lines has usually been deleted rather than reduced. Ask which one.
The same MVP brief in 2026 comes back at very different numbers depending on who builds it:
None of these is the right answer for everyone. The mistake is comparing the offshore sticker price to the UK sticker price as if you are buying the same thing. You are not.
Building the thing is a one-off. Running it is not. Budget for the year after launch, not just the launch:
Who you hire changes the number as much as what you build. In short:
A freelancer or small contractor team is often right when the scope is clear, it's mostly one discipline, and someone on your side can direct the work. Lower cost, fast, if they're available. The risk is continuity: one person is one point of failure, with no cover and no second pair of eyes on the code.
An agency earns its premium when the work crosses disciplines (you need strategy and design and build, connected) or when you can't yet write the brief yourself. You're paying for process and for a team where no one person's calendar is the bottleneck. The risk is distance: a weak agency puts juniors on your account and a slide deck between you and the work.
Building in-house only makes sense if this product is your company's core and you'll build it for years. Hiring a founding engineer and designer is a three-to-six-month process and a permanent cost. Right eventually, rarely right for the first release.
We wrote a whole guide on this call: agency, freelancer, or in-house. The short version is that most first products are best served by a small agency or contractor team, with a plan to hire in-house once the product has proven itself.
Three patterns account for most of the waste we see in MVP budgets.
Building phase two first. The features that feel essential in a planning document are very often the first things real users ignore. Every “while we're in there, let's also...” is budget spent before you have evidence it's needed. Ship the core, watch what people actually do, then decide.
Bespoke where boring would do. A custom sign-in system. A hand-built admin panel. A design system with forty components before launch. Notifications infrastructure for an app with ninety users. Each is defensible alone; together they double your build for capability you won't use for a year. Use the off-the-shelf option until it genuinely stops working.
Slow, plural decision-making. The biggest hidden cost. When a team waits three days for feedback, or “the answer” changes because a different stakeholder saw it last, you pay for that time. Appoint one person who can say yes, and protect their time to actually look at the work.
To make the range concrete, here's a real plan for a common situation: a founder with validated demand (people have said they'll pay), no existing product, one clear core flow.
That's a real MVP: it proves whether people will complete the core action and pay, it's built to hand over, and it leaves budget for the iteration that actually matters. It is tight. It works when the scope is genuinely one flow and you make decisions fast.
A different common situation: demand is proven, you have early revenue or a signed pilot, and the product needs to do three connected things on day one, not one.
Same discipline as the £30,000 plan, more surface area, and a contingency that reflects the extra moving parts.
If that's roughly where you are, book a free consultation and we'll sketch a plan against your actual budget and constraints, even if the honest answer is “you want a contractor for this, not us.”
Abad
Abad spends most weeks with founders scoping first builds, and talking them out of about half of it.
Turn an idea into a product, brand, or campaign, with one team from strategy to launch.
start a projectEngineering
The best tech stack for a first build is a boring one: proven, well-documented, and easy to hire for. Here's what “boring” actually means in 2026, the traps that sink second years, and a sensible default to start from.
11 Sep 2026 · 10 min read
Regulated Products
You rarely need your own licence to launch a payments or e-money product. Here are the routes that let you go live in weeks instead of a year, what you still own, and the safeguarding change landing in May 2026.
8 Sep 2026 · 11 min read
Regulated Products
If an NHS organisation is going to use your product, you have to clear DTAC before the pilot, not just before procurement. Here's what that involves in 2026, the roles you'll need, and how to sequence it so it doesn't derail the build.
27 Aug 2026 · 11 min read