How to scope an MVP for a small app

Choose one user and one complete outcome

An MVP is a first version that helps you test an important product assumption with real use. It is not a smaller copy of every feature in your final vision. Write the outcome a user must reach, then identify the few steps required to get there.

For a hypothetical household meal planner, the outcome could be ‘turn five selected dinners into one editable shopping list’. That is a complete workflow: choose meals, combine ingredients, adjust quantities, and use the list. Social profiles, recipe recommendations, and supermarket integrations may be useful later, but they are not required to test that workflow.

Separate essentials, assumptions, and later features

List the essentials by user action rather than by technology. ‘Save the list so it survives closing the browser’ is a need. A particular database is one possible implementation. This distinction makes it easier for a builder to propose a simpler solution without changing the product’s purpose.

Also write a ‘not in this version’ list. Without an explicit boundary, small requests accumulate into a different product. When someone proposes another feature, ask whether the first user can reach the stated outcome without it. If yes, record it for later instead of quietly expanding the brief.

• Essential: the user can create, edit, save, and retrieve the core item.
• Uncertain: a dependency or behavior that needs a quick feasibility check.
• Later: a useful feature that does not determine whether the first workflow works.

Include failure states in the first version

Small does not mean that data loss, broken access control, or unreadable mobile screens are acceptable. Decide what happens with empty input, duplicate actions, invalid data, and a failed network request. Users should understand whether their work was saved and what they can do next.

Reduce the need for sensitive data where possible. If the product needs accounts, decide who can read and change each record. If it calls a paid API, define limits and a useful error state. These decisions belong in the first brief because they affect the shape of the implementation, not just its polish.

Write checks a person can actually perform

An acceptance criterion describes observable behavior. ‘Fast and easy’ is hard to test. ‘After I change the quantity and reload, the saved quantity is still shown’ gives you a concrete check. Include at least one happy path and one failure path for the main workflow.

For the meal-planning example, check that two meals using the same ingredient produce one combined list entry; a user can correct that entry; the correction survives a reload; and an empty meal selection explains what to do next. Define units carefully: two cups and 200 grams cannot be added without a conversion rule.

User: [one specific group]
Outcome: [one completed task]
Must include: [required steps]
Out of scope: [explicit exclusions]
Data: [what is stored, where, and who can access it]
Acceptance checks: [observable outcomes]
First test: [who will try it and what you will observe]

Let the first test decide the next feature

Give the first version to someone with the problem and watch them attempt the core task. Record the step where they stop, the workaround they invent, and whether the result is useful outside the demo. Ask what they would do if the app disappeared; this can clarify which part creates value.

Prioritize a change that removes an observed obstacle. Resist treating every suggestion as a requirement. If nobody needs the outcome enough to repeat the workflow, adding more screens is unlikely to answer the underlying question. Revisit the audience or the problem before expanding the build.