Lead magnet 02
MVP Readiness Checklist
A practical checklist for deciding whether your idea is ready to become a focused first build.
How to use it
Tick each statement that is true enough to proceed. Unticked items are not failures; they are useful questions to resolve before build time becomes expensive.
- Use this before commissioning an MVP, prototype or internal tool.
- Score honestly. A smaller, clearer version one usually beats a vague bigger build.
- Bring unresolved items into discovery so they become part of the plan.
Problem clarity
The build has a real job to do.
- The problem is specific, not just a general desire for an app or website.
- The problem is painful, frequent, valuable or strategically important.
- The current cost of doing nothing is understood.
- A successful first version can be described in plain language.
User clarity
The product is being shaped for identifiable users.
- Primary users, admin users and stakeholders are named.
- The core user journey is understood from start to finish.
- User constraints are known, such as device, time, skill level or accessibility needs.
- There is a realistic way to collect feedback from users after launch.
Feature priority
Version one has a controlled scope.
- Must-have features are separated from nice-to-have features.
- Each must-have feature supports the core outcome.
- Manual or lightweight workarounds are acceptable for low-risk launch items.
- The team can explain what will not be included in the MVP.
Data and storage needs
The information model is clear enough to start.
- The records, files, notes, users or transactions are roughly defined.
- Required data sources are available or can be created.
- Export, backup and retention needs have been considered.
- Data quality risks are understood before automation is added.
Integrations
External systems are not hidden surprises.
- Required integrations are listed, such as email, payments, CRM, analytics or AI APIs.
- Access to accounts, API keys and documentation can be arranged.
- Fallback plans exist if an integration is delayed or expensive.
- Private keys and secrets will be kept server-side and out of source control.
Security and permissions
The MVP protects users and business data.
- User roles and access levels are known.
- Sensitive data has been identified before launch.
- Forms and user inputs will be validated and treated as untrusted.
- Legal, compliance or privacy expectations have been raised early.
Launch route
There is a practical path from build to real use.
- The launch audience is defined, even if it is a small pilot group.
- Deployment, domain and hosting expectations are understood.
- Basic analytics, feedback and support routes are planned.
- There is a clear owner for post-launch decisions.
Maintenance
The product can survive after the first release.
- Someone will monitor user feedback, bugs and operational issues.
- Basic documentation and source code handover are expected.
- Hosting, email, database and third-party service costs are understood.
- There is a plan for small improvements after launch.
Budget and timeline
Expectations match the ambition of the first version.
- The budget is realistic for the desired quality and complexity.
- The timeline allows for shaping, design, build, testing and launch.
- Decision-makers can review progress without blocking every detail.
- Trade-offs between speed, scope and polish are understood.
Decision score
Add the scores above to decide the next move.
Clarify users, scope, data and launch assumptions before building.
A focused prototype or technical spike can reduce uncertainty quickly.
The idea is ready for MVP scoping, delivery planning and implementation.
Highest-risk unresolved item: ____________________________________________