Before deciding what to build, I would ask what decision the work needs to support.
Do you need to understand whether people can use an idea? Whether a technical integration is possible? Whether customers will adopt a service? Whether your business can run it reliably?
Those questions call for different investments. For planning, I use the following working distinctions.
A prototype explores an idea
A prototype is useful when the biggest uncertainty is about the concept, the interaction or the workflow.
It might be a clickable interface, a coded experience with sample data or a narrow technical experiment. The important thing is to be clear about what it does and does not demonstrate.
A clickable prototype can help you explore whether a user understands the navigation. It does not prove the underlying integrations work.
A technical proof of concept can show that two systems exchange data. It does not prove the resulting product is useful.
Neither is a problem, as long as the team does not confuse the question being tested.
An MVP tests a focused value proposition
I would use a minimum viable product to put a narrow offering into real use and learn whether it delivers value.
That means choosing a particular audience and outcome. Instead of launching a complete platform for service businesses, for example, you might focus on helping one type of business handle incoming requests.
Some supporting work might stay manual, as long as that arrangement is appropriate, transparent where it needs to be and does not undermine the service.
The objective is not the smallest amount of software possible. It is a credible way to test the important assumption.
Production describes an operating commitment
A production application is something people are expected to use under defined operating conditions. That raises questions about access, reliability, support, data handling, maintenance and recovery.
It does not necessarily mean a large product.
A small MVP used by real customers may already need production-level safeguards. A large demonstration may still be only a prototype.
That is why I avoid treating prototype, MVP and production as three neat boxes on a timeline. They describe different aspects of the work.
Ask what the next investment needs to prove
Before choosing a deliverable, answer:
- Who will use it?
- What will they do with it?
- Which assumption matters most?
- What evidence would change our next decision?
- What would happen if the system failed?
- What can we responsibly leave out?
If the uncertainty is usability, a prototype may be enough. If it is whether people will adopt it, you need a credible real-world test. If people will depend on it, operating requirements belong in the scope, even if the feature set is small.
Buy the right evidence
The mistake I want to avoid is building a production system to answer a question a prototype could settle.
The opposite mistake is treating a successful prototype as proof that the business is ready to launch.
Choose the next deliverable for the evidence it can produce.
Then make the next investment with a clearer understanding of what you know, and what is still unproven.
If you are not sure which one you need, the v1 check takes two minutes and shows where your product stands.