MVP release readiness guide
What should be checked before an MVP goes live?
An MVP is ready for its intended users when the core journey works and the team can support it. Check scope, access, data, integrations, usability, recovery and ownership with evidence, not a tick beside a feature name.
1. Agree what this release must prove
Write one sentence naming the first user, the task and the confirmed result. Add the learning question that will shape the next investment. Identify who may join the release and which use cases are intentionally excluded.
Attach acceptance examples to the journey: a normal completion, a correction and an important failure. Name the business owner who can accept the result. If stakeholders disagree about what “done” means, resolve that before treating the build as ready.
This checklist is a release discussion aid, not a certification. The feature prioritisation guide helps select the scope; the MVP versus prototype guide helps decide whether a live release is appropriate yet.
2. Demonstrate data and permission boundaries
Identify the source of each important record and who may create, view, change, export or remove it. Use representative, approved test data. Do not copy sensitive production information into development tools merely to speed up a demonstration.
- Show that one user cannot read or change another customer’s records.
- Test disabled accounts and removed team members.
- Define who can use support or administrative access.
- Agree retention and deletion responsibilities with the appropriate owner.
- Test a recovery process rather than relying only on a backup setting.
OWASP ASVS provides a basis for defining application security verification requirements. Select relevant requirements with the technical reviewer; this checklist does not establish compliance or replace specialist review.
3. Check the real dependencies and failure states
Confirm access to the intended supplier accounts, environments and interfaces. Record any limits or approvals that affect the first users. A mock integration is useful during development but cannot demonstrate that the production workflow works.
Test unavailable services, repeated requests and delayed responses. Show users whether work is saved, pending or complete. Decide who reconciles a task when the destination may have accepted it but the application did not receive confirmation.
Keep an owner for any deliberate manual step. A launch plan that depends on someone checking an inbox should say who, when and what happens during absence. The integration-pattern guide explains why different kinds of work need different completion signals.
4. Test with the people and devices that matter
Ask representative users to complete the task without coaching them through every step. Check mobile layouts, keyboard operation, readable errors and confirmation messages. Test with realistic content lengths and record where people need help.
W3C’s accessibility evaluation guidance recommends evaluating accessibility throughout development and explains that tools alone cannot determine accessibility. Combine automated checks with manual review appropriate to the release.
Review AI-generated code and tests using the same acceptance criteria as other work. GitHub’s responsible-use documentation explains why generated suggestions need human review and testing. A green generated test does not independently prove the requirement was understood.
5. Keep a compact launch evidence record
| Area | Evidence | Decision owner |
|---|---|---|
| Core journey | Observed completion and accepted result. | Product or business owner. |
| Access and data | Permission tests and recovery demonstration. | Technical and data owners. |
| Dependencies | Verified production configuration and failure handling. | Integration owner. |
| Usability | User observations, accessibility review and resolved blockers. | Product and delivery team. |
| Operation | Support route, incident response and release recovery plan. | Named service owner. |
Record remaining issues with impact and an explicit decision. Do not hide a launch blocker under “known issue”. If unauthorised access is possible or critical data cannot be recovered, narrow or delay the release instead of accepting the risk by accident.
6. Release to learn, with an operating owner
Confirm repository and hosting access, supplier account ownership, deployment instructions, monitoring and who handles a failed release. Agree the data implications of rollback: restoring older code does not necessarily undo a data migration safely.
Hypothetical example: an invited-customer request tool is ready only after a customer can submit, staff can review, the result remains visible and a failed notification can be investigated. A working submit button alone is insufficient. Monitor completed requests and support involvement, not just page views.
The GOV.UK beta guidance is a useful reference for improving a working service from user evidence. Agree when your team will review findings and choose the next change. Bring this record to LCR’s MVP service; use the timeline guide to expose unresolved launch dependencies.
Sources and review date
Primary sources reviewed on 7 September 2026 and linked beside the claims they support. Decision tests are planning recommendations, not measured research. Examples are hypothetical, not client case studies. Confirm scope, price, timing and specialist-review needs with the responsible team.
Questions
Frequently asked questions
Does an MVP need security testing?
Yes. Define testing appropriate to its users, data and consequences. A small feature set does not remove access-control and recovery responsibilities.
Must every minor defect be fixed before launch?
Not necessarily. Record impact and obtain an explicit acceptance decision. Defects that prevent the core outcome or expose unacceptable risk should block or narrow the release.
What should be handed over?
Agree repository and account access, deployment and recovery instructions, support ownership, known issues and the evidence used to accept the release.
Plan the next useful step
Bring the workflow and the result you need.
Discuss the users, existing systems and first-release boundary before committing to a build.