THE SHORT ANSWER
A prototype explores an interaction or concept; a proof of concept tests feasibility; an MVP delivers minimal real value while testing an important assumption; alpha and beta releases expose a developing product to controlled use; a production product is operated for real users with appropriate reliability, security and support.
Name the artefact by its purpose
| Stage | Primary question | Production expectation |
|---|---|---|
| Sketch/prototype | Does the concept or journey make sense? | Disposable; not live-service code |
| Proof of concept | Can a technical uncertainty be resolved? | Narrow feasibility work |
| MVP | Can a minimal product create value and learning? | Real use with bounded scope |
| Alpha | Can the emerging approach work with close control? | Limited and expected to change |
| Beta | How does a substantially built product perform with wider use? | Growing operational readiness |
| Production | Can the service be operated responsibly for intended users? | Security, reliability, monitoring and support |
Do not mistake a convincing prototype for a live product
A prototype may contain sample data, simulated payments or links that do not enforce rules. Its value is speed and shared understanding. Copying prototype code directly into production can carry missing security, performance and maintainability work.
Evidence & context: GOV.UK Service Manual
An MVP is minimal in scope, not responsibility
An MVP can omit optional features while still protecting users, validating inputs and completing its central promise. If it handles money, identity or sensitive data, those consequences shape the minimum responsible implementation.
Evidence & context: NIST
Define what moves the product forward
- Question being tested
- Target participant and context
- Observable signal
- Known limitations
- Quality and safety boundary
- Result that triggers revision, expansion or stopping
Startup Fundamentals explains MVP as a business-learning instrument. This resource adds the software-delivery distinctions needed to plan the build.
Sources & further reading
- Making prototypes
GOV.UK Service Manual. Guidance on choosing prototype fidelity to explore and test ideas. It explicitly distinguishes prototype code from production-ready software.
- Designing strong experiments
Strategyzer. Practitioner guidance on explicit hypotheses, relevant participants and well-designed artefacts. Experiment quality and interpretation still depend on context.
- Secure Software Development Framework
NIST. Outcome-based secure-development guidance covering preparation, protection, secure production and vulnerability response. It is a framework, not a product-specific checklist.
Examples and exercises are illustrative unless attributed to a source. No independent expert review is claimed.
A correction, a counterexample or an experience worth sharing?
Join the conversation ↗