The temptation to build everything
When the budget is fixed, choose which part of the product needs to work first. Building every planned feature before anyone uses it can consume the budget without answering whether people want the product.
A minimum viable product (MVP) is a usable first version that tests whether the core idea is worth pursuing. Its scope should follow that question.
Define the smallest useful outcome
Start with one clear question: What does the software need to do to prove the product works?
Define a task the first users can complete and the evidence you need from them. That tells you what the first version must include and which features can wait.
An example
For a rostering platform, consider the full feature list. The complete vision might include shift scheduling, availability management, leave requests, shift swaps, facial attendance capture, wage calculation, compliance rule engines, payroll integration, and reporting dashboards.
The smallest useful outcome is probably: a manager can create a shift, an employee can see it, and the system records who is working when. Everything else can be added after that core loop is proven.
Risk-first scope
Some features have familiar implementation patterns, such as login screens and simple reports. A new algorithm or an unusual integration may need testing before you can estimate the rest of the build.
Test the assumption most likely to prevent the product from working. That could be an algorithm, an integration or whether users can complete the core task. The result should inform the rest of the scope.
This reduces the risk of spending the budget on familiar features before discovering that the part the product depends on will not work.
Sprint delivery
Work delivered in short, visible cycles gives you options. After each sprint, you have working software you can show to potential users, investors, or advisors. Their feedback informs the next sprint.
If the feedback is positive, you continue. If it reveals a problem, you adjust. If the market signals are clear that the idea is not viable, you stop — having spent a fraction of the full budget rather than all of it.
How to avoid a disposable MVP
A common concern is that an MVP will be thrown away — rewrites are expensive, and "technical debt" feels like failure. It helps to distinguish two approaches:
A disposable MVP is built without thought for what comes next. The architecture is deliberately temporary, and the code is designed to be discarded. The cost of replacing it needs to be understood before choosing that approach.
A well-scoped MVP is built on a foundation that can grow. The first version is small, but the architecture anticipates the next few versions. Decisions about data and system boundaries should leave room for the next likely changes.
Ask the developer which parts can be extended and which would need replacement if the product grows. A small first version can leave room for later work without implementing it now.
What to bring to the conversation
Before you talk to a developer about an MVP:
- The task your product needs to solve. Explain who needs it and what they do today.
- The budget. State the amount you can spend testing the idea.
- Who will use it first. Identify people who can try the first version and give feedback.
- What "proven" looks like. Choose an observable outcome. For a rostering product, an example might be: "twelve restaurants used it to roster staff for four consecutive weeks."
Use those answers to agree on the first sprint and how you will assess it before committing to more work.