Create an MVP in 2026: The Build Is the Cheap Part Now
What it means to create an MVP in 2026
To create an MVP is to build the smallest working product that proves someone will pay for it. In the UK in 2026 that costs roughly £15,000 to £60,000 through an agency, or close to nothing if you generate it yourself with AI. The build stopped being the expensive part. Changing it in month six is where the money goes.
So, look. I've been a fractional CTO for years and the question founders ask me has completely changed. Two years ago it was "how much to build this". Now it's "I already built it in a weekend, why is everything on fire".
Both questions have the same root. Nobody separates the cost of the first build from the cost of owning what you built.
What it costs to create an MVP in the UK right now
Published UK figures for 2026 cluster in a fairly tight band. Foundry 5 and Peachr both land on £15,000 to £60,000 for most funded early-stage builds, with a validation prototype at £5,000 to £15,000 and anything involving payments, third-party integrations or AI features pushing past £35,000. Day rates run from about £250 for a UK freelancer to £900 for a London agency, so the same scope can double in price on that one choice.
Treat those numbers as what agencies charge, not what the work costs, because every one of those sources sells MVP builds. They're still directionally right, and they match what I see when founders show me quotes.
Here's the bit those pages leave out. Budget 15% to 25% of the build cost per year for maintenance, and that assumes the thing was built to be maintained. A £40,000 MVP is a £48,000 first year. If it wasn't built to be maintained, the number is not 20%, it's another full build.
| Route | Typical UK cost | Time to something usable | What you're actually buying |
|---|---|---|---|
| AI-generated, founder-built | £0 to £500 in tool subscriptions | 2 days to 3 weeks | A demo that proves the idea to you, not a product that survives a hundred users |
| Freelancer | £8,000 to £25,000 | 6 to 10 weeks | Working software and a single point of failure who owns all the context |
| Regional UK agency | £15,000 to £45,000 | 8 to 14 weeks | A delivered scope, usually managed by someone non-technical |
| London agency | £25,000 to £80,000 | 8 to 16 weeks | The same scope plus 15% to 25% for the postcode |
| CTO-led build | Scoped per project | 6 to 12 weeks | Working software plus the four architecture decisions that decide whether year two costs £10k or £150k |
Why the first build got cheap and the second one got expensive
GitClear published The Maintainability Gap in 2026 after analysing 623 million code changes from 2023 to 2026. It's the most useful piece of research on this I've read, and the findings are consistent across every signal they measure.
Duplicated code blocks rose from 40.3 per million changed lines in 2023 to 73.0 in 2026, an 81% increase and the highest ever recorded. Refactoring collapsed in the same window: moved code fell from 21% of changed lines in 2022 to 3.8% in 2026, while copy and paste climbed from 9.4% to 15.7%. Developers are now roughly five times more likely to duplicate than to refactor. In 2022 the preference ran the other way, two to one in favour of refactoring.
Two more numbers from the same report matter more than they sound. Function connectivity, which measures how often new code calls into code that already exists, fell 35%. And "long-term update percent", the share of changes that touch code older than twelve months, fell 74%, from 1.7% to 0.46%.
Put those two together and you get the shape of a 2026 MVP codebase. New features arrive as self-contained islands. Old code is never revisited. Nothing gets consolidated. You end up with forty separate implementations of "check if this user can see this thing", and when the rule changes you have to find all forty.
That is the actual bill. It doesn't arrive at launch. It arrives when you hire your second engineer and they take three weeks to ship something that should take a day.
The 25% number nobody quotes
The marketing around AI coding tools runs on multiples. 10x. 4x. Ship a startup in a weekend. Some of that is real and I use these tools daily, so I'm not going to pretend otherwise.
But two pieces of measured research land in the same place, and it isn't 10x.
METR ran a randomised controlled trial with 16 experienced open-source developers across 246 real tasks in their own repositories. Tasks were randomly assigned to allow or forbid AI. The developers forecast a 24% speedup going in. Afterwards they estimated they'd been 20% faster. They were measurably 19% SLOWER.
GitClear's January 2026 analysis found heavy AI users out-produce non-users by 4 to 10x, which sounds like the marketing. Then they compared those same developers to their own past selves and the gain shrank to 25%. The tools attract people who were already shipping fast. They don't create them.
25% is a good number. I'd take a 25% productivity gain any day. It just isn't a reason to skip the design work, and it's nowhere near enough to make a codebase nobody understands into a viable asset.
What to actually build, and what to cut
Pendo's Feature Adoption Report found that 80% of features in the average software product are rarely or never used, and that about 12% of features generate 80% of daily usage. It's from 2019 and nothing since has contradicted it. Most of what you're planning to build will be dead weight.
Which lines up uncomfortably well with why startups die. CB Insights analysed 431 VC-backed shutdowns since 2023, published March 2026. Running out of capital tops the list at 70%, but they flag that as the symptom. Poor product-market fit is 43%. Bad timing 29%. Unsustainable unit economics 19%. Two-thirds of the product-market-fit failures were early-stage companies that never found a market at all.
Not one of those companies died because their code was ugly. They died because they built the wrong thing, and then ran out of money before they could build a different thing.
So the scoping rule I give every founder is one sentence. Pick the single journey that a paying customer must complete, and build only that.
Concretely, here's what goes in the first build and what waits:
- In: one user journey end to end, one way to sign up, one way to pay, and enough logging that you can tell what people did.
- Out: admin dashboards (use the database), settings pages (hardcode it), onboarding flows (email them), password reset (do it manually for the first fifty users), dark mode, and every single integration nobody has asked for yet.
- Never out: knowing who owns which record, and enforcing it. More on that below.
The admin dashboard is the one I argue about most. It is always four weeks of work, it is always for an audience of one, and that person can use a database client.
The four decisions that outlive your MVP
Almost everything in an MVP is disposable. Four things aren't, because changing them later means rewriting everything that touches them. These are the four I insist on getting right even when the rest is held together with tape.
1. The ownership boundary. Every record needs to know who owns it, and the check needs to live in one place. AI-generated code reliably nails authentication and reliably skips authorisation, because logging in has a universal shape and "who is allowed to see this invoice" depends on your business. Push the check into the data layer with row-level security or a single fail-closed permission gate. Not forty copies.
2. The data model. Data outlives code. You can rewrite the frontend in a fortnight. You cannot cheaply change what a "user" is once you have 5,000 of them and a payment history attached.
3. Where money and time are stored. Money as integers in minor units, never floats. Timestamps in UTC with the timezone stored separately. Get this wrong and you will be reconciling invoices by hand at 2am, which I have done, and would rather not do again.
4. Can you deploy on a Friday. Not because you should, but because if the answer is no, you don't have a repeatable path to production, and every fix from here is a gamble.
That's it. Four decisions, maybe two days of thinking. Everything else in an MVP can be rubbish and it genuinely doesn't matter.
Weekend build, agency, or CTO-led
| Question | AI weekend build | Typical agency | CTO-led (Metamindz) |
|---|---|---|---|
| Who decides the architecture | The model, implicitly | Whoever is free that sprint | A working CTO who has run this stack in production |
| Who you speak to weekly | Nobody | A non-technical account manager | The person writing and reviewing the code |
| Will they tell you to build less | No, it'll build whatever you ask | Rarely, scope is revenue | Yes, and we'll tell you when you don't need us at all |
| Authorisation handled | Usually not | Sometimes, if asked | Designed in from the first table |
| Who owns the repo and infra | You | Often them until final payment | You, from day one, no lock-in |
| What happens at 5,000 users | Rebuild | Change request | Already accounted for in the data model |
| Cost of year two | Unknown, frequently the largest number | 15% to 25% of build | 15% to 25% of build, and predictable |
If you want the fuller version of the free and near-free route, I wrote a separate piece on how to build a free MVP that covers the tooling in detail. This post is about what happens after. There's also a piece on how fractional CTOs guide MVP prototyping if you're weighing up whether you need one at this stage.
When you should just ship the vibe-coded thing
Sometimes the right answer is to generate it yourself over a weekend and put it live. I'd say yes to that if all four of these are true:
- You're testing whether anyone wants it, not serving people who already do.
- You hold no payment details, no health data and no personal data beyond an email address.
- Fewer than a few hundred users, and you're fine throwing the whole thing away.
- Nobody is depending on it to run their business.
Break any one of those and you've stopped prototyping and started operating. That's the line. Cross it deliberately, not by accident six months in because the demo kept working.
The founders who get into trouble aren't the ones who vibe-coded an MVP. They're the ones who vibe-coded an MVP, got customers, and never went back. If that's already you, a vibe-code audit is a cheaper conversation than a rebuild, and an independent technical assessment is what an investor will ask for anyway.
Frequently asked questions
How much does it cost to create an MVP in the UK in 2026?
Published UK agency figures for 2026 put most early-stage MVPs at £15,000 to £60,000, with simple validation prototypes at £5,000 to £15,000 and builds involving payments, integrations or AI features above £35,000. Day rates range from £250 for a freelancer to £900 for a London agency. Add 15% to 25% of the build cost per year for maintenance.
How long does it take to create an MVP?
An AI-generated prototype takes two days to three weeks. A freelancer build takes six to ten weeks. An agency build takes eight to sixteen weeks. A CTO-led build usually lands at six to twelve weeks because scope gets cut harder upfront. The variable is almost never engineering speed, it's how long the founder takes to decide what to leave out.
Can I create an MVP with AI tools and no developers?
Yes, and for pure idea validation that's often the right call. The limits are real though: AI-generated code reliably handles login and reliably skips authorisation, and GitClear's 2026 data shows duplication up 81% and refactoring down to 3.8% of changed lines. Fine for a throwaway test. Not fine once you hold customer data or take payments.
What should I leave out of my MVP?
Admin dashboards, settings pages, onboarding flows, self-service password reset, and every integration nobody has asked for. Pendo found 80% of software features are rarely or never used and about 12% drive 80% of usage. Build one paying-customer journey end to end. Handle the rest manually until doing it manually genuinely hurts.
Do I need a CTO to build an MVP?
Not for the whole build, no. You need someone technical for about two days to settle four decisions: the ownership boundary, the data model, how money and time are stored, and whether you have a repeatable path to production. Everything else in an MVP is disposable. A fractional CTO covering those four is far cheaper than a rebuild.
Where this leaves you
The founders asking me "why is everything on fire" all made the same trade without knowing they'd made it. They optimised the number they could see, which was the cost of the first build, and ignored the number they couldn't, which was the cost of the second.
Creating an MVP in 2026 is cheap. Owning one is not. Spend two days on the four decisions that don't change, cut everything else to a single journey, and ship it.
If you want a second opinion on what to cut before you spend anything, we do CTO-led development and we'll happily tell you that you don't need us. Book a call and bring the feature list. I'll bring the red pen.