Product planning
MVP scope: what belongs in the first release?
Before counting screens, define the task a user must complete and the operations that support it.
One user, one complete task
“An app” is not a sufficient definition for a first release. Describe who completes which task: a customer chooses an appointment, submits a request and checks its status. That sentence exposes dependencies such as calendars, approval, notifications and cancellation. The MVP boundary should enclose an end-to-end workflow, rather than a handful of attractive screens.
Invisible work belongs in the scope
Authentication, permissions, error messages, data protection and management tools are often necessary for a usable product. Payments and third-party integrations also need defined failure behavior. Deferring these foundations can leave the product unable to serve its first real user. Advanced reports, an additional user role or another platform can follow later when the core workflow does not depend on them.
Uncertainty shapes the timeline
A timeline for a simple MVP cannot be applied to a platform with migrations, many integrations or complex permissions. Discovery records the core workflow, assumptions, acceptance criteria and unresolved questions. “Payment unlocks access,” for example, needs rules for failed payments and repeated notifications. We then prepare milestones and a scope-based USD proposal, including testing and any store review requirements.
APPLY IT TO YOUR PRODUCT
Consulting & Code Review
Architecture decisions, code review and team mentoring. We also audit a codebase you inherited.