Prototype, MVP or production software? A decision guide
When a digital product idea is still uncertain, you do not need to build the complete application immediately. Start by deciding which uncertainty the next step should reduce.
Prototype: make a user journey understandable
A prototype shows what a workflow could look or feel like. It can test navigation, wording, sequence and early feedback. A clickable prototype can simulate interactions without having a reliable backend or production data.
A prototype can answer: Do users understand the journey? Is a step missing? Does the solution seem plausible for the task? It does not prove that architecture, security, scale or economics are ready.
MVP: test the core assumption in use
A minimum viable product is more than a clickable model. It is a limited, usable product version for testing one central assumption under defined conditions. That requires at least a defined user group, a bounded feature set, appropriate data, and someone responsible for support and defects.
Even an MVP needs access controls, backups and error handling appropriate to its use. Once users rely on it or it processes personal data, the requirements go beyond a demonstration.
Production software: operate reliably
Production software does not need every feature anyone might request. It needs to support the agreed workflow reliably and be operable. Depending on the use, that includes authentication and permissions, logging, monitoring, backups, recovery, documentation, maintenance and a clear owner.
The right controls depend on the data, users, impact of failure and connected systems. A prototype that works in a workshop is not automatically ready for daily operations.
Which stage fits now?
- Users and workflow are still unclear → start with problem conversations and a prototype.
- The interaction is clear but the usage assumption is open → run a bounded test with success criteria.
- The workflow is validated and users will depend on it → plan production operation, data, security and maintenance.
- Existing software already covers the core → integrate or configure before building something new.
Before moving to the next stage
Record what observation justifies the next investment and which question is still open. Define the central user journey, exceptions, required data and system access. Decide who will operate the solution after launch, handle issues and own changes.
If an assumption is not confirmed, a small discarded prototype can teach more than a larger, unvalidated system.
What a prototype sprint should deliver
A well-scoped sprint should produce one concrete user journey, a testable prototype, one feedback round and a written recommendation for the next step. Production integrations and backend work need separate scope once they become part of the goal.
Mauna Labs offers a five-working-day Prototype Sprint with agreed scope, one feedback round and a next-step recommendation. It is a focused prototype, not a promise that a product will be production-ready in five days.