
MVP Development Cost in the UK
Most MVP quotes are wrong for the same reason: they price a feature list instead of a decision. Here are the real UK ranges and what actually moves them.

Every software development company says the same things: senior engineers, agile delivery, transparent communication, on time and on budget. None of it is falsifiable, which is exactly why everyone says it.
Useful evaluation means shifting from what you are told to what you can check. This is the list we would use if we were the ones buying.
Start with the boring checks, because they are fast and they occasionally end the process on their own.
This single question sorts studios faster than any other. Every team that has shipped anything has a project that overran, lost a key person, or shipped something the client did not want.
A good answer is specific and includes what they changed as a result. An answer of "we have never had one" means either they have not shipped much, or they are willing to tell you something untrue in a sales conversation — and you have learned something useful either way.
The right answer is measured in days, not months. If the first demo is week six, you are buying a plan rather than a product, and you will not find out whether the plan was right until most of the budget is spent.
You should own everything from the first commit — repository, cloud accounts, domains, CI. If ownership transfers "on final payment", that is leverage being built into the contract. Ask specifically about accounts as well as code: owning a repository you cannot deploy is not ownership.
Scope always changes. What matters is whether there is a defined process — a change order with a price and a date — or whether it is handled by goodwill until goodwill runs out. Fixed price should mean fixed price, so ask exactly what triggers a change order. Fixed price versus time and materials is worth understanding before this conversation.
Meet them. It is common for the people in the sales call not to be the people on the project, and it is entirely reasonable to ask to speak to the engineers who would do the work. A studio that will not arrange this is telling you something.
Ask what you receive on the last day, and what happens if you take the project in-house afterwards. A team that has thought about being replaceable is usually a team worth keeping.
Cheap quotes are usually cheap because something was left out. These are the lines most often missing, and none of them are optional in reality.
| Line | Why it matters | Typical share of build |
|---|---|---|
| Discovery and scoping | A fixed price without it is a guess | 5–10% |
| QA and testing | Otherwise you are the test team | 15–20% |
| Deployment and monitoring | "It works on staging" is not shipped | 5–10% |
| Post-launch sprint | Real users always force changes | 15–20% |
A quote that is 40% below the others is rarely 40% more efficient. Compare what is included before you compare totals, and treat a missing line as a cost you will pay later rather than a saving.
And the reverse: pressure to sign quickly, unwillingness to put estimates in writing, a portfolio of screenshots with no named clients, and "we do everything" in response to any question about specialism.
Talk to three studios with the same written scope. Ten conversations produce noise and decision fatigue; one produces no comparison at all. Three is enough to see the spread in price and interpretation, which is the information you are actually buying.
If it helps to see what a specific answer to these questions looks like, how we work sets out our process, and our case studies describe what was broken, what changed and where it ended up — including the parts that were harder than expected.
Shortlist three, give each the same written scope, and evaluate what you can verify rather than what you are told. Check the public company register, ask when you will first see working software, confirm you own the code and cloud accounts from the first commit, ask what triggers a change order, and ask about a project that went badly. Compare what each quote includes before comparing totals.
When do I see working software running? Who owns the code and the cloud accounts, and from when? What triggers a change order? Who is actually writing the code, and can I meet them? What do I receive at handover? Tell me about a project that went badly and what you changed afterwards.
Almost always because something was left out. The lines most often missing are discovery and scoping, QA, deployment and monitoring, and the post-launch sprint — together roughly 40–60% of a realistic build. Ask every studio to price the same written scope so you are comparing the same work rather than different interpretations of it.
Yes. Repository, cloud accounts, domains and CI should be in your name from the first commit. Ownership that transfers on final payment is leverage written into the contract. Ask about accounts specifically as well as code — owning a repository you cannot deploy is not meaningful ownership.