Discovery, clickable prototype and MVP development

What an MVP is, and what it is not

An MVP (minimum viable product) is not a cheap version of everything, and it is not a demo. It is one type of user doing one main job from start to finish, well enough to use every day. Everything else waits until real use shows it is needed.

This applies to internal software too, not only to startups. A distributor building a trade ordering portal could launch with repeat orders for its largest customer group, and leave quotes, returns and statements for later. A professional association could start with membership renewals before adding events or a directory.

Common ways an MVP goes wrong:

• Too broad: ten features at half quality instead of one at full quality.
• Too rough: so many bugs or confusing screens that users give up, and you learn nothing about the idea.
• No measure of success agreed beforehand, so nobody can say whether it worked.
• Built on throwaway foundations when it is meant to grow: security, data model and permissions still need doing properly.

What happens in a software discovery phase

The GOV.UK Service Manual, written for public services but useful for any software project, sums up the principle: before you commit to building, you need to understand the problem that needs to be solved, and you should not start building in discovery. It puts a typical public-sector discovery at around four to eight weeks; for a business project the length depends on its size, and we agree the schedule in writing.

What the work usually involves:

• Interviews and observation with the people who will use the software, not only with management.
• Mapping the current process, including the spreadsheets, emails and workarounds nobody mentions in meetings.
• Systems and data: what exists, what has an API, what has to be migrated.
• Risks: technical unknowns, personal data, dependencies on other suppliers.
• A product discovery workshop to rank what goes into the first version and write down what stays out.
• A clickable prototype of the main flow, tested with real users.

Clickable prototype, proof of concept or MVP

Three different tools, often confused. Each answers a different question:

Deciding what goes into the MVP

A few questions do most of the work. Which task, if solved, would make users stop using the spreadsheet or the phone call? Which user benefits first and most often? What would make the first version unusable if it were missing, such as permissions, a key integration or an export to the accounts package? Everything that fails these questions goes on a written list of later features, with a reason, so nothing is lost and nobody is surprised.

If the product is meant to become a business of its own, the same thinking applies at larger scale on our page about SaaS development. The design side of the prototype is covered under UX/UI design for business software.

What you get, and what happens after the MVP

Discovery ends with a scope document, a clickable prototype, a list of risks and how to handle them, and a fixed-price proposal for building the MVP. After launch, measure what was agreed: how many people use it, how often, and whether the original problem shrank. Then decide what comes next with evidence rather than opinions.

The build that follows runs with a working demo every two weeks and one fixed price for the project; the details are on how we work. Market price references for the build itself are in our guide on how much custom software costs.