What a non-technical founder should know before paying for an MVP

Send the same feature list to five studios and five numbers come back, often tens of thousands of pounds apart for the same words. The spread is not dishonesty. It is five different guesses about what you meant, five different stacks, and five different opinions about what to cut. You have to judge those guesses without being able to read the code, and comparing the prices tells you almost nothing.

Technical direction is the thing you are buying

The code is the output. What you are actually paying for is a run of decisions: what the architecture looks like, which stack it sits on, what gets cut, what gets handled manually behind the scenes for now, and what order things ship in. Someone senior has to own those decisions and answer for them later, because you cannot referee them yourself.

That person should hold boring opinions. Postgres over whatever is fashionable this quarter. A mainstream framework your next hire already knows. Hosting on a platform with published pricing. An exotic stack recommendation mostly serves the studio's curiosity, and you pay for it twice: once now, and again when you try to hire for it.

The quickest test of whether technical direction exists at all: does the studio argue with your feature list? A plan that accepts all twelve features without a fight means nobody has thought about the system, only about the invoice.

A first version tests one assumption

Feature lists balloon for a predictable reason. Every feature sounds cheap in isolation, and nobody in the room prices the connections between them. The industry numbers say the caution is warranted: requirements shift by around 25% during a typical project, and 52% of projects hit scope creep, according to IFSQ and PMI figures collected in DECODE's comparison of pricing models. Scope you commit to in week one will be partly wrong by week eight.

So scope the first version around one question, not twelve features. Usually the question is some version of: will the target user do the core action repeatedly, without you standing next to them? Everything that does not help answer that waits. The stakes are not abstract. CB Insights' post-mortem of 431 VC-backed companies that shut down from 2023 onwards found 70% ran out of capital and 43% never found product-market fit. A first build that spends the budget proving nothing feeds both numbers at once.

Know what you are actually buying

You are buying an asset, so behave like it. Four things to have in writing before any deposit leaves your account:

• The intellectual property in the code is assigned to your company as invoices are paid, not held hostage until a final milestone.
• The repository lives in your GitHub organisation from day one. The studio gets access; you own the account.
• Hosting, domain, DNS, payment and email accounts are created in your name. You hold the keys, always.
• Handover is a listed deliverable: documentation a competent outside developer could deploy from, plus full environment access.

Then budget past launch day. One detailed UK cost guide puts ongoing maintenance at 15 to 25% of the initial build cost per year, with hosting around £100 to £500 a month for a standard product. A studio that never mentions running costs is quoting you half the price.

Fixed price or day rate

Fixed price gives certainty, but only if the scope is genuinely tight. Vendors price the uncertainty either way, typically padding fixed quotes with a 15 to 30% risk buffer, per research cited by DECODE. If your requirements are still moving, a fixed contract just converts every new discovery into a change-order negotiation. The honest middle ground: fix the budget per phase (discovery, build, launch) and stay flexible inside each one.

For calibration, the same UK guide puts a simple single-platform MVP at £8,000 to £30,000 over eight to twelve weeks, and a standard business product at £30,000 to £80,000 over twelve to twenty. It also puts paid discovery at £5,000 to £12,000 across two to four weeks, and flags discovery quoted under £3,000 as a sign the scope was never really validated. Ranges vary by studio, but a quote sitting far below the credible band is not a bargain. It is a different, smaller project wearing your project's name.

Questions to ask before signing

• Who makes the architecture decisions, and what have they personally shipped?
• What would you cut from this list, and why?
• What does week two look like? You want working software early, not a month of setup.
• What happens after launch: who fixes bugs, at what rate, how quickly?
• What do you need from me each week?
• Tell me about a project that went wrong, and what changed afterwards.

The specific answers matter less than whether crisp answers exist. A studio that has thought about failure has usually survived some.

Red flags

A quote with no questions back is the loudest one. Nobody can price your product from a single email, so a confident number returned overnight is a guess with a signature line. Per-feature pricing is a close second: it means the system was never considered as a system, and the integration cost is hiding somewhere. Silence about what happens after launch means the relationship is designed to end at the invoice. And full payment up front, or IP withheld until the last penny clears, tells you who the contract was written to protect.

What a reasonable MVP does not include

Native iOS and Android apps alongside the web product. Granular roles and permissions. A custom admin panel where a database view would do. SSO, audit logs, multi-currency, multi-language, configurable reporting. Every one of these becomes a real requirement eventually. In a first build they are money spent answering questions nobody has asked yet.

Sometimes the right build is no build

Cheap-and-fast has a legitimate place, and pretending otherwise would serve studios better than founders. If the risky assumption is "will anyone pay", a landing page with a payment link tests it in a week for a few hundred pounds. If the workflow is forms, records and notifications, a no-code tool gets a testable version live in days, and throwing it away later costs nothing. Delivering the service manually behind a thin front end tests demand harder than software does.

Commission a custom build when the thing you need to learn is the product itself: when the experience is the differentiator, when no-code cannot model the workflow, or when a real integration is the entire point. Spend the first money working out which of those describes you. That decision costs a conversation. Rebuilding costs the budget.