How to scope an MVP without overbuilding
An MVP is not a compressed version of the final product. It is the smallest credible product or service that can produce evidence for an important decision.
Name the decision the MVP must inform
Choose one uncertainty: will a specific user complete the workflow, pay for the outcome, trust the result, or replace the current alternative? Features that do not affect that decision require a separate reason to exist.
Constrain the first user and workflow
Define one primary user, trigger, input, core action, output, and completion condition. Keep edge cases, roles, integrations, automation, and reporting outside the first scope unless the test cannot be credible without them.
Write exclusions and acceptance criteria
State what the build will not do and how both parties will observe that the agreed workflow works. This prevents a visual demo, an internal prototype, and a production-ready service from being treated as the same deliverable.
Plan the evidence after release
Decide who will use the MVP, how feedback or behavior will be captured, what result supports iteration, and what result supports stopping. Shipping without an evidence plan only proves that software can be shipped.