Most MVPs fail at scope, not code. The feature list grows until the budget runs out before anything reaches a user. Here is how we cut an idea down to something that ships.
Write down the one thing you need to learn
An MVP is an experiment, so it needs a question. Will schools pay for this? Will freelancers switch from spreadsheets? Will anyone come back after the first week? Write the question in one sentence. If you have three, pick the one that would kill the business if the answer is no.
Every scope decision after this is measured against that sentence.
List every feature, then sort by what it teaches you
Dump every feature you have imagined into a single list. Then give each one a simple label: does it help answer your question, is it required for the product to work at all, or is it nice to have?
Sign-up, payments and the core action usually land in the first two groups. Settings pages, team accounts, dark mode and admin dashboards usually land in the third. Be honest here. The third group is where budgets go to die.
Replace features with manual work
Many features exist to save time at scale, and you do not have scale yet. Onboarding can be a call. Reporting can be a spreadsheet you send every Friday. Matching can be done by you, by hand, from an admin view.
Manual work also teaches you what to automate later, because you will know exactly which steps hurt.
Decide what done means before you start
Agree on a launch definition in writing: which features, which platforms, which user can do what. Without it, every demo produces new requests and the launch date drifts. Changes are still welcome, but each one should replace something, not stack on top.
Keep the foundations, skip the polish
Cutting scope is not the same as cutting corners. Keep a sensible data model, real authentication, backups and basic security. These are expensive to retrofit. Skip custom animations, edge-case settings and pixel-perfect design on pages few users will see.
Plan the first two weeks after launch
Launch is when you start learning, so budget for it. Set up analytics before release, decide which numbers answer your question, and keep some development time free for fixes and quick changes. A first version with no room to react is a missed experiment.
A quick scope check
- Our question fits in one sentence.
- Every feature in version one either answers it or is required to function.
- We have replaced at least one feature with manual work.
- Our launch definition is written down and agreed.
- Analytics and time for fixes are in the plan.
None of this is complicated, but it is easy to skip when you are excited about an idea. If you want a second opinion on your scope, send it to us and we will tell you honestly what we would cut.