Name the riskiest assumption
Write one sentence: “We believe [user] will [behaviour] because [reason].” Then ask what evidence would change your mind. If the first release cannot produce that evidence, it is probably building features rather than testing the product.
Separate the test from the platform
Some work proves the product; some work keeps it maintainable. An MVP still needs a sane data model, authentication and a deployment path, but it does not need every administrative screen, integration or billing edge case. Decide explicitly which parts are a test and which are foundations.
- The one workflow that proves the value.
- The users who must complete it without help.
- The data and permissions required for that workflow.
- The metric or observation that decides whether to continue.
Write the non-goals
A scope with no non-goals expands until the original question disappears. List what is intentionally excluded: advanced roles, bulk import, multiple languages, complex billing, mobile apps or integrations. Put them in a backlog with the condition that would justify them later.
Architecture for the next release
The MVP should not be a dead end. Choose a data model and boundaries that can support the next release without a rewrite. Avoid premature microservices, but do not hide tenant, permission or billing logic inside a single screen. Document the assumptions that would force an architectural change.
Measure the decision
- Can a new user reach the core outcome without a call?
- Where do they stop, and what do they ask for?
- Which assumptions were wrong?
- What is the cost of running the release for one month?
What to defer
Defer features that add combinations without answering the core question: fine-grained admin roles, complex pricing, every integration, native apps and marketing automation. Defer them deliberately, with a trigger for revisiting. A deferred feature is a decision; an unlisted feature is scope creep.
See web app and SaaS development, what drives custom software cost or discuss your project.