What is an MVP?
MVP stands for minimum viable product. It's the first working version of a product, built to answer one question: will people use this, and will they pay for it?
It isn't a prototype or a clickable mock-up. Real users sign in and do the core job. It also isn't the full product. Anything that doesn't help answer that question can wait.
What drives MVP cost in the UK?
Nine things decide most of the price. Check each one against what your first version really needs.
- User types: a product with customers, staff and admins needs three sets of screens and permissions, not one.
- Core features: the one job the product does, and every feature you add around it.
- Integrations: payments, email, CRMs, accounting tools and third-party APIs each need building and testing at both ends.
- Data: what you store, how it's structured, and whether it includes personal or sensitive information.
- Logins and security: sign-up, password resets, roles and audit trails all take time to get right.
- Design: a custom interface takes longer than one built from a proven set of components.
- Platforms: a web app that works on every device is one build. Separate iPhone and Android apps add more.
- Scope clarity: a vague brief costs more, because time goes on working out what to build.
- Who builds it: senior developers move faster and make fewer expensive mistakes, but cost more per hour than juniors.
Why do MVP quotes vary so much?
Because they're usually quoting for different products. One developer reads "booking app" as a single form with email confirmations. Another reads it as accounts, payments, reminders and a staff calendar.
Quotes also differ on what's included: design, testing, hosting set-up, documentation and support after launch. Compare what each quote covers, line by line, before you compare the totals.
How do you keep your MVP cost down?
These seven steps cut cost without cutting what you learn. Do them before you ask anyone for a price.
- Write the one question your MVP has to answer, in a single sentence.
- List every feature you want, then mark the ones that help answer that question. Park the rest.
- Pick one user type to serve first, unless the product can't work without two.
- Use existing tools for anything that isn't your core job: payments, email, logins and analytics.
- Build for the web first, so one version works on every device.
- Get a written scope and a fixed price against it, so changes are visible and agreed.
- Plan the first round of changes now. You'll learn things in the first weeks that change what comes next.
What does an MVP cost after launch?
The build is only part of the cost. Once real people use your product, it needs hosting, monitoring, backups, security updates and someone to fix things when they break.
Third-party tools often charge monthly, and some charge more as you grow. The biggest running cost, though, is usually the changes you'll want once you see how people use it. Budget for a second round of work, not just the first.
If you store personal data, UK GDPR applies, and you're responsible for keeping that data secure. Build that in from the start. It's cheaper than adding it later.
Should you use no-code tools for an MVP?
Sometimes. No-code tools can test a simple idea quickly, especially if the product is mostly forms and lists.
The trade-off comes later. You may hit limits on what the tool can do, pay more as users grow, or need to rebuild from scratch to scale. If the product is the business, a custom build in standard code is usually the safer long-term choice.
Fixed price or paying by the hour?
Paying by the hour suits work where nobody can say what's needed yet. The risk is that the total keeps growing.
A fixed price against a written scope suits most MVPs. You know the cost before work starts, and any change is a clear decision with its own price, not a surprise on the invoice.