A digital product idea usually arrives as a long list. Customers would book online. Staff would see the diary. Reports would update themselves. Payments, logins, a mobile app and a dozen exceptions all feel essential before anyone has used the thing. An MVP, a minimum viable product, is how a UK business cuts that list down to the smallest version that still answers a real question. The point is to learn, with less spent, before a full build is funded.
What an MVP is, and what it is not
An MVP is the smallest version a real user can complete the core job with. For a booking idea, that might be one service, one way to request a time, and a view for the person who has to fulfil it. For an internal tool, it might be one repeated task taken out of a spreadsheet and put on a screen the team will actually open.
It is not a clickable picture that only the project team can see. A prototype can be useful earlier, to check that people understand the steps. It does not tell you whether they will use the product on a Tuesday when they are busy. An MVP is also not a half-finished copy of the full system, with every menu present and most of them empty. Empty menus teach you nothing, and they make the product feel abandoned.
Off-the-shelf software is allowed to win. If a tool you can buy already lets you test the demand, building is the more expensive way to ask the same question. Bespoke software development earns its place when those tools no longer fit the way you work, when manual steps are eating the week, or when systems need to talk to each other and they do not.
What belongs in the first version
Include the path from the user's first step to the outcome you care about. Name one primary user. If you cannot say who that is, the feature list is standing in for the decision.
- The one job the product exists to complete.
- Enough of the journey that a stranger, or a member of staff, can finish it without a guided demo.
- Clear labels, a way to get help, and personal data handled in line with UK GDPR.
- A simple way to see whether people used it: completed tasks, not a dashboard of vanity numbers.
- The integration you cannot test without, and no others. A CRM, a payment step or a booking engine belongs in version one only if the question depends on it.
Leave out extra roles, report packs, a native app for iOS and Android, and visual polish that does not change the question. Design still matters. A confusing first screen produces a false "no". UI and UX design before the build is how you check the journey while changing it is still cheap. Designing the experience first avoids expensive changes once code is the thing you are editing.
Stages that keep the risk small
The stages are a sequence of decisions, not a pile of features.
Name the risk
Write the question the MVP has to answer. "Will existing customers request this service without phoning?" is a question. "Build a platform" is not. If the answer is already yes, you may not need an MVP. You may need a proper build, scoped against a process you already trust.
Map the journey
List the steps for that one user, including the unhappy ones: a time that is taken, a field they do not understand, a request that is out of area. This is the spec. Anything that does not appear in the journey waits.
Design, then build the thin version
Wireframes and a clear interface come before code, so the team is building a plan someone has already walked through. The build then covers that path only. Admin screens exist so a non-technical colleague can operate the day, not so every future report has a menu item.
Put it in front of real users
Staff who will use it, or a small number of real customers, are the test. A room of people being polite is not. Watch whether they finish the job without help. Note where they stop. That evidence is the result of the MVP, more than a list of feature requests gathered in the same meeting.
Continue, change, or stop
Three outcomes are all acceptable. Continue, and fund the next slice. Change the journey, because people wanted a neighbouring job. Stop, because the demand was not there, and be glad the full product was not built first. Stopping is a successful use of an MVP. It is the risk you paid to retire.
How to validate before you spend more
Validation is a record of behaviour. Count completed tasks. Talk to the people who stopped halfway, and to the people who finished and did not come back. A handful of real uses will tell you more than a longer feature list written in advance.
Keep the learning attached to the original question. If customers finish the request but staff cannot fulfil it without a spreadsheet, the next slice is the fulfilment view, not a mobile app. If nobody starts the request, more features will not fix the offer. Change the offer, or stop.
Integrations should follow the same rule. Connecting a CRM, a payment gateway, email or a booking engine is routine when the product needs it. Doing all of them in the first release, "so it is ready", hides which connection actually mattered. Add the one the test depends on. Add the next when the test says so.
After the first release
An MVP that people use becomes a product that has to be looked after. Bugs, small changes and a named person to call are part of keeping the learning going. Maintenance and support after deployment covers monitoring, fixes, feature updates and technical help, so the first version does not freeze the week it goes live.
Web Works Rise is a UK-led team. The office is in Birmingham, and a development hub in Tunisia adds delivery capacity for the UK work. The work starts from the business problem, then a version small enough to test. If you have a product idea, or a process that has outgrown its spreadsheet, contact the team with the question you need answered. That question is the scope.