Startup MVP Build Guide UK: Costs, Timeline & What "DONE" Looks Like

WHAT AN MVP ACTUALLY IS (AND ISN'T)

The term has been stretched beyond recognition. An MVP is not a beta, not a v1 with fewer features, and definitely not "the app but cheaper". The original meaning — the minimum you must build to start learning from real users — is the only one that matters, because it sets the scoping rule: if a feature doesn't help you learn or earn, it isn't in the MVP.

That gives you two legitimate MVP shapes. The learning MVP tests the riskiest assumption: will anyone use this? It can be embarrassingly thin — a landing page with a waitlist, a concierge service run manually behind a simple front end, a clickable prototype. The earning MVP is for when the assumption is tested and you need something real users pay for: the smallest complete product that delivers the core value and takes money.

Most founders build the earning MVP while only needing the learning one. That's how £40k gets spent discovering what a £500 landing page would have revealed. Be honest about which question you're answering: "will anyone want this?" or "can we deliver this well?" Scope accordingly.

WHAT TO CUT: THE RUTHLESS PASS

Take your feature list and run every item through three filters. A feature survives only if it passes all three:

1. Does the core value break without it? A booking app without booking is pointless; a booking app without push notifications is fine. If users can get the core value some other way (email instead of in-app messaging, manual instead of automated), cut it.
2. Does it test a risky assumption? Features that confirm what you already know are expensive reassurance. Features that answer "will users actually do X?" earn their place.
3. Would you delay launch a month for it? If not, it's phase 2. This question kills more scope creep than any framework.

The usual casualties, cut without mercy:

• Native mobile apps — start with responsive web unless your value proposition physically requires native (camera AR, offline-first field work, app-store distribution as the channel). One codebase, all devices, half the cost. Go native when traction demands it, not before.
• Admin dashboards — you don't need a beautiful admin panel for 50 users; you need database access and a willingness to run queries. Build the admin when manual ops actually hurt.
• Social features — profiles, feeds, messaging, gamification. These are products in themselves; they double your scope and your timeline. Launch single-player value first.
• Multi-role permissions, multi-language, multi-currency — all legitimate, all later. One role, one language, one currency until someone pays you to add the second.
• AI anything — unless AI is the product, "add AI" is scope creep wearing a trendy coat. A human doing it manually behind the scenes (the concierge MVP) teaches you what to automate later.
• Pixel-perfect design — clean and usable beats beautiful at MVP stage. Nobody ever said "great app, shame about the border radius". Save the design polish for the version people pay for.

What survives the cut is usually: signup/login, the one core workflow, payments if you charge, and basic analytics so you can learn. That's an MVP. Everything else is a roadmap.

INDICATIVE UK COST BANDS

Costs below are indicative UK ranges for agency-built work in 2026 — order-of-magnitude guides, not quotes. Your number moves with scope, integrations, design ambition and who builds it. (Freelancer and in-house maths live in our three-way comparison.)

What moves you up or down the band: integrations (each third-party API adds cost and risk), custom design vs clean-and-simple, compliance needs (healthcare, finance), and how much is genuinely custom vs assembled from proven components. An honest quote explains which of these apply to you.

Two cost traps to name plainly. First, the rebuild tax: the cheapest quote often buys code that works in the demo and collapses under real users — then you pay again to rebuild. Second, the "just one more feature" drip: each addition feels small; together they quietly double the budget. The must-have list in your brief is a contract with yourself — defend it. (How to write that brief: the agency brief checklist.)

REALISTIC TIMELINE

Founder optimism compresses every estimate. Here's what actually happens, for a typical web app MVP with an agency:

• Weeks 1–3: scoping and proposal. Discovery calls, technical planning, fixed quote. Agencies that skip this and start coding on day two are not fast — they're guessing.
• Weeks 3–5: UX/UI design. Wireframes to clickable designs you approve. Your feedback speed here directly sets the pace — the most common delay in every project is the client review cycle, not the coding.
• Weeks 5–12: build. Frontend, backend, integrations, in weekly demonstrable chunks. You should see working software every week, not a big reveal at the end.
• Weeks 12–14: testing and hardening. Bug fixing, performance, security basics, content loading. The unglamorous fortnight that separates products from demos.
• Weeks 14–16: launch. Deployment, app store review if applicable (add 1–2 weeks for iOS), monitoring, handover.

So: roughly 3–4 months from first call to launched web app MVP, assuming you review promptly and scope stays disciplined. Mobile apps run similar or slightly longer. Anyone promising a serious product in three weeks is selling a template — which is fine if a template is what you need, but call it that.

The timeline killer isn't engineering, it's indecision: vague requirements discovered mid-build, stakeholders appearing in week 9, "can we just add…". Every one of those restarts the clock on the affected work. The brief you write before the project is a timeline protection device.

WHAT "DONE" LOOKS LIKE

"Done" needs defining before the build starts, or it never arrives. A finished MVP means all of these:

• Launched and usable by real users — deployed, monitored, with real data flowing. A staging link is not done.
• The core workflow works end to end — signup to value to payment (if you charge), on the devices your users actually use.
• Tested — not "the developer clicked through it": structured testing across devices and browsers, with the embarrassing bugs fixed.
• Documented and handed over — you own the repo, the hosting accounts and the credentials; there's a setup guide and a deployment runbook. If the agency vanished tomorrow, another developer could pick it up.
• IP assigned — in writing, on final payment. Non-negotiable.
• Analytics in place — you can answer "is anyone using it and what do they do?" from day one. An MVP you can't measure is an expensive opinion.
• A short warranty — typically 30 days of bug fixes post-launch. Bugs found in real use get fixed; new features are phase 2.

Get "done" defined in the contract, referencing the brief. Then done is a fact, not a negotiation.

AFTER LAUNCH: ITERATION IS THE PRODUCT

Launch day is the starting line. The MVP's job was to produce learning; now use it. The honest post-launch sequence:

1. Watch, don't build (weeks 1–4). Resist the urge to add features. Watch the analytics, talk to users, find where they stall. The data will contradict your assumptions — that's the point.
2. Fix the leaks before adding rooms. If most users abandon signup, a new feature helps nobody. Conversion and onboarding fixes beat new-feature work at this stage, by a distance.
3. One bet at a time. Pick the single riskiest remaining assumption, build the smallest thing that tests it, measure, repeat. This is the MVP loop continuing — most startups stop iterating the moment they launch, which wastes the entire exercise.
4. Budget for it. Plan on spending 15–25% of the build cost per quarter on iteration in year one — indicative, but founders who budget zero for post-launch are planning to launch and pray. Support, hosting, small improvements and the occasional bigger bet are the real cost of a live product.

This is also when the build-vs-team question returns: keep the agency on a retainer for velocity, start hiring in-house as the roadmap firms up, or both. Our agency timing framework and the three-way comparison cover the sequencing. If the product needs ongoing custom development, see application development; if it's fundamentally a site that must rank and convert, website development.

STARTUP MVP — FAQs