MVP Development: How to Scope a First Version That Proves Something (UK Guide)

Quick answer

An MVP (minimum viable product) is not a cheap version of your product — it’s the smallest experiment that proves people want it. The scoping rule that saves five figures: pick one user journey that delivers the core value, build only what that journey needs, and fake or manual-ise everything else. UK costs in 2026: validation without code £0–£500; no-code MVPs £2,000–£10,000; custom-coded MVPs £5,000–£15,000. Most failed MVPs die from scope, not technology — they launch late, over budget, testing nothing in particular.

The one-journey rule

Write the single sentence: “[User] can [core action] and gets [core value].” A booking marketplace: “A dog owner can book a vetted walker for tomorrow.” That sentence is the MVP. Everything else — profiles with photos, reviews, favourites, referral schemes, admin dashboards, the walker’s payment analytics — is version two, contingent on version one proving anyone books at all. The discipline test for every feature: “does the core journey fail without this?” Auth? Often replaceable with magic links. Payments? Stripe checkout, not a billing system. Admin? A spreadsheet behind the curtain. The Wizard-of-Oz pattern — humans manually doing what will later be automated — is legitimate MVP engineering, not cheating: it tests demand before paying for automation, exactly the automate-nothing-you-haven’t-done-manually principle applied to product.

Validation before code (the £0–£500 stage most skip)

1. The landing-page test: a one-page site describing the product with a “join the waitlist” or preorder button, plus £100–£300 of targeted ads. Signup rate is demand data no focus group matches — and the page costs less than one day of development (landing page costs).
2. The concierge test: deliver the service entirely manually to five customers (spreadsheets, WhatsApp, invoices). You learn the real workflow — and what the software must actually do — before specifying it.
3. Ten conversations: not “would you use this?” (everyone lies kindly) but “how do you handle this today, and what does it cost you?” Present pain beats hypothetical enthusiasm.

If the idea survives all three, the build brief writes itself — and if it doesn’t, you’ve saved the entire budget.

Build routes and UK costs

Full production costs and what changes after the MVP are in custom web app costs; the web-vs-native question — for MVPs, almost always web first — is covered in web app vs mobile app vs website. On supplier choice: MVPs are the natural territory of good freelancers and small studios (the trade-offs) — and a supplier who pushes back on your scope is showing you the MVP instinct you’re paying for, the same signal discussed in custom vs off-the-shelf.

The mistakes that sink first versions

• Scope creep pre-launch: “while we’re at it” is how 6-week MVPs become 6-month products that test nothing. Park every addition in a version-two list — writing it down is what lets you not build it.
• Polish before proof: pixel-perfecting a product nobody has validated. MVP design should be clean and trustworthy (people won’t pay through something that looks broken) but not bespoke-beautiful — that budget belongs after signal.
• No success metric: define before launch what “validated” means (X signups, Y paid conversions, Z retention at week 4). Without the number, every result is arguable and the project drifts.
• Throwaway thinking — or its opposite: building so hackily nothing survives validation, or so “properly” you’ve built the scale-ready platform for users who don’t exist. The middle: a real but small codebase (or no-code base) you’re willing to either extend or discard without grief.
• Ignoring the boring layer: UK GDPR applies from user one — a privacy notice, sensible data handling and a lawful basis aren’t optional at MVP stage, just proportionate.

Scoping the one journey, choosing the route and defining the success number is a half-day conversation — it’s how every project at our custom software service starts, and it’s the half-day that decides whether the following months build evidence or expense.

The running costs nobody budgets for

Build cost gets quoted; running cost gets discovered. A live MVP with a few hundred users has an ongoing bill that is small in absolute terms and fatal if it was never planned for, because it arrives every month whether or not the experiment is working.

Payment processing sits on top and is easy to model: UK card payments through a mainstream processor typically cost around 1.5% plus 20p, with international cards materially higher. On a £15 transaction that is roughly 3% gone; on a £3 transaction it is nearly 12%, which is why micro-priced MVPs so often fail on unit economics rather than on demand. If your idea depends on small, frequent payments, model the processing fee before you model anything else — it can invalidate the business model while the product is still a sketch.

A worked validation budget: £6,000, twelve weeks

Numbers make the sequencing argument better than principles do. Here is one plausible allocation for a small UK business testing a booking product, and it deliberately spends nothing on code for the first month.

1. Weeks 1–2 — conversations and a page (£400). Ten interviews, plus a single well-built page that states the offer and captures interest. This is one of the few places where paying properly beats DIY, because a page that looks improvised depresses signup rate and corrupts the very data you are buying — it is a cheap, contained piece of work, and a fixed-fee one-page website keeps it that way.
2. Weeks 3–4 — paid traffic (£400). Enough spend to get a few hundred targeted visitors and a signup rate you can believe. Below roughly £250 of spend the numbers are noise.
3. Weeks 5–6 — the concierge run (£200 of your time and tools). Serve five real customers manually. This is where the specification gets written, because you now know what the workflow really is rather than what you assumed.
4. Weeks 7–11 — the build (£4,500). One journey, real payments, no admin panel beyond a spreadsheet, no dashboard, no settings screen.
5. Week 12 — launch and instrument (£500). Analytics, error alerts, and a written definition of what result means continue, pivot or stop.

Notice what is missing: no logo refinement beyond something clean, no second user type, no mobile app. Also notice the reserve — spending the entire budget on build leaves nothing to act on what you learn, and the whole point of an MVP is having money left when the evidence arrives. Whatever the route, the document that determines whether that £4,500 buys twelve weeks or six is the specification, and the structure that produces comparable quotes from different suppliers is set out in how to brief a software project.

Contract terms that protect a first version

MVPs are frequently built by whoever was available and cheap, on nothing more than an email agreement. Three clauses prevent the expensive version of that story:

• IP assignment in writing. In the UK, a contractor generally owns the copyright in what they create unless the contract assigns it to you. Employees are different; freelancers and agencies are not. Without assignment, you may be paying for a licence to your own product.
• Repository and account ownership from day one. The code repository, the hosting account, the domain and the payment account should all be in your business’s name, with the developer added as a collaborator. Reversing this after a falling-out is the single most common way small companies lose their software.
• A defined handover. What running the thing requires — environment variables, deployment steps, third-party accounts — written down at the end, not reconstructed later. Half a day of the developer’s time; it decides whether anyone else can ever pick the project up.

The cliff after validation

The most under-discussed part of MVP work is what happens when it succeeds. A validated MVP is not a product; it is a proven hypothesis wrapped in code that was deliberately unfinished. Budget for the second phase before you celebrate the first:

• Everything you faked has to become real. The spreadsheet admin, the manual onboarding, the invoices you sent by hand — each was correct at 20 users and impossible at 500.
• The edge cases arrive. Refunds, cancellations, disputes, duplicate accounts, people entering data you never imagined. This is typically 30–50% of the remaining build effort and almost none of the demo.
• Support becomes a job. Real users email at 9pm. Someone must answer, and that someone is you until it is not.
• Expect the phase-two build to cost more than the MVP, commonly one and a half to three times, and to take longer because it cannot break the users you now have.

This is also the point at which the native app question comes back, usually pushed by a customer who says “is there an app?” The answer is nearly always to keep the web product and revisit later, because app store distribution brings a 15–30% platform commission on in-app purchases, review cycles that slow releases, and two more codebases to maintain — the full cost picture is in mobile app development costs, and it is a decision to make with revenue data rather than enthusiasm.

When a “proper” MVP is the wrong tool

Three cases where the standard advice misleads. Internal tools have no demand risk — you already know the users and the workflow — so the validation stage is redundant; the risk is specification, not appetite, and the money is better spent on discovery than on landing-page tests. Regulated or safety-critical work cannot ship a deliberately incomplete first version; here the “minimum” is set by the regulator, not by you, and the honest answer is a smaller scope rather than a rougher build. Very standard product patterns — a directory, a booking flow, a simple marketplace — may not need custom code at all for the first year, and assembling them on existing platforms can compress a twelve-week build into three weeks, at the price of ceilings you should understand before choosing, which is precisely the trade-off examined in no-code versus custom development. In all three, the underlying discipline holds: spend the smallest amount that produces a decision, then decide.

Sources & Further Reading

• UK Data Protection Basics — GOV.UK
• Stripe UK Pricing — Stripe
• No-Code Platform Pricing — Bubble