Scoping an MVP Without Building the Wrong Thing

The purpose of a minimum viable product is to answer one uncertain question with real users, cheaply enough that a wrong answer is survivable. Almost every MVP that disappoints did so by trying to answer four questions at once.

Name the question first

Write down the one thing you do not know and cannot resolve by asking people. "Will clinics pay for automated reminders if setup takes under ten minutes" is a question an MVP can answer. "Will people like our app" is not — it produces polite feedback and no decision.

Then write what result would make you stop. An MVP with no failure condition is not an experiment; it is a launch with a modest budget.

One flow, complete

Pick the single path that tests the question and build it fully: real authentication, real data, real deployment, working on a phone. One complete flow tells you the truth. Six half-built screens tell you that your prototype is confusing, which you already knew.

Cut scope by removing flows, not by removing the finish from the flow you kept.

What is fair to defer

• Roles beyond the one that answers your question.
• Admin screens — a database client is acceptable for weeks.
• Self-serve onboarding, while you can onboard people by hand.
• Billing, if you can invoice manually at this volume.
• Integrations that are not part of the flow being tested.

What is never fair to defer

• Authentication and authorisation done properly.
• Data model decisions that are expensive to reverse.
• Anything touching payments or personal data.
• The quality of the one flow you are testing.

Build for a rewrite you may not need

Assume parts of the MVP will be replaced, and choose an architecture where that replacement is contained: clear boundaries, a sane schema, no clever coupling. The mistake is not writing code you later delete. It is writing code that cannot be deleted without taking the rest with it.