This is Part 2 of a three-part series on building an MVP in the UK. Part 1 covers what an MVP costs and how long it takes. Part 3 walks through a real MVP from first conversation to build.
What is an MVP? #
I often struggle to remember the true meaning of acronyms, so for the avoidance of doubt: MVP means “Minimum Viable Product”.
Viable is the key word here. An MVP is not:
- A clickable prototype
- A proof of concept
- An inexpensive version of the complete product
- A poorly finished application
- The first phase of a large predetermined specification
An MVP is the smallest possible thing your users could get some value from. A prototype e-commerce site would let you select products and add them to a basket, but to be an MVP, users need to actually be able to buy something.
I say “could get some value from” because MVPs are just as likely to demonstrate something doesn’t work as they are that it does. This is where founders often falter or flourish.
If you’re wondering why we differentiate between “Production-ready” and “Complex” MVPs in Part 1, it’s really a mark of how novel the system is. Two projects we undertook recently illustrate this well:
- The first was an educational platform for a group of schools in the UAE. They had an existing platform that worked but didn’t quite fit their needs, and could clearly demonstrate what parts of their existing toolset worked and what needed improving. A straightforward proposition with few dragons waiting to catch us out.
- The other was for a startup that converts chemical waste into inert, usable materials. They wanted AI agents to help design unique systems tailored to each process. That was complex.
What drives complexity in an MVP #
Users #
A starting point when thinking about potential complexity is simply the number of everyday users and the varied things those users must do.
An e-commerce site has one everyday user and one workflow - customers search for products, add to basket, checkout and pay.
Our Ed Tech app had multiple users:
- Tutors create questions
- Tutors create tests
- Tutors start and stop instances of those tests
- Students complete the tests
- Tutors mark the completed tests
- Students read the feedback from those tests
- Tutors see the performance of students across their tests
These workflows are governed by permissions - tutors and students can only interact with their own questions and assessments, so they aren’t just a user type, they’re users who can only interact with certain things.
People often overlook the complexity surrounding the administration of a site - also known as the “back office”. An e-commerce website needs mechanisms for people to upload new products, check the status of orders, or organise collections of similar products such as “sofas” or “menswear”.
Mobile #
We’re still surprised at the number of founders who also want a native iOS or Android app on day one. That isn’t an MVP, it’s three - each with its own team of developers.
Modern responsive web applications will give you 90% of the functionality of a native mobile app. Unless your startup idea is genuinely mobile-only, going native will certainly cost you time and money you don’t have.
Integrations #
Most systems have to integrate with something - in our experience that’s typically a payment gateway so people can buy things, and an email provider so the system can send and receive emails from and to users.
These days we’re also increasingly integrating with agents and LLMs, which bring their own complexity.
Product design #
Don’t get too hung up on design for an MVP if you can help it. If your idea isn’t that novel, you should be able to borrow heavily from existing systems. If it is novel, your first customers will be “early adopters” who really want the functionality you’re offering and don’t care too much how it looks.
Data and AI #
If you’re in Europe or the UK you need to consider GDPR. Despite all the scare stories from people selling their services, GDPR isn’t that complex once you understand that all it’s doing is balancing your need to keep personal data with the benefit that data gives your customers.
It’s not just about sending the data, either. For example, our expense system shares expense data with an LLM, some of which can contain names and addresses - we have to be careful to strip out any personal information before sending anything to an external third party such as Claude or ChatGPT.
Security and regulation #
These days decent security is available out of the box if you know where to look. If your startup has elevated security needs, it probably means investing in a good development team for your MVP more than hiring specific security functions or roles.
Fintechs often have additional requirements, especially if they’re governed by the FCA, who may require some minimum liquidity of cash in the bank to protect your customers.
DIY or agency - where does the money go? #
It’s not really about who can write the code — most of what follows is the same list of work whichever route you take. It’s about how many people you’re paying to hold each item on that list.
A full agency engagement typically staffs each of these as a distinct role, often a distinct person:
- Technical architecture
- Front-end development
- Back-end development
- Infrastructure and deployment
- Testing and quality assurance
- Product definition and scope
- UX/UI design
- Security and privacy
- Documentation and handover
- Project management
- Product management
- Launch support
None of that is padding — it’s all genuinely necessary work. But an agency usually bills each of these as a separate specialist, plus an account or project management layer that sits above them to coordinate the handoffs. That coordination is real cost, and it exists whether or not your MVP actually needs that much specialisation.
A lean team (like us) collapses most of that list into the one, two or three senior generalists that set the numbers in Part 1 — the same work, done by people who’ve done all of these roles before and can move between them without a handoff. You’re still paying senior rates. You’re just paying far fewer of them, with no coordination layer sitting in between.
Next… #
In Part 3 we put all of this into practice on a real project - a “TripAdvisor for dog owners” - and show exactly how a long founder wishlist gets distilled down to a buildable MVP.
If you’ve got a list of features and aren’t sure what’s actually MVP, that’s exactly what our free “does it have legs?” conversation is for. Get in touch and we’ll help you find the smallest version worth building.
