Small enough to ship.
Complete enough to use.

A minimum viable product is a small, complete way to learn whether something is useful. “Small” is about the number of promises you make. “Complete” means someone can follow the main path and get the promised result.

A login screen, a dashboard and an empty database can take a week without proving that result. A plain page that solves one real task can teach you more. Begin with the outcome, then make the time and dependencies explicit.

Choose one complete flow

Finish this sentence: “For this kind of person, in this situation, the first version helps them do this one thing.” Name a person you can reach, a situation you can recognize and an outcome you can observe.

For a focus timer, the flow might be: choose a duration, start together, see the same finish time, and know when the session ends. It does not automatically include profiles, a calendar, a streak system or subscription billing. Each of those makes a different promise.

• Start: can a new visitor tell what to enter or choose?
• Action: does the central task actually work with a realistic input?
• Result: can the visitor understand what happened and what to do next?
• Recovery: what happens when the input is empty, the connection fails or the visitor makes a mistake?

Write that flow before making a feature list. A feature belongs in the first version when removing it breaks the flow or makes the learning exercise impossible. If it only makes a future version more attractive, put it in a separate later list.

Budget the time you can actually use

A calendar deadline is not the same as working capacity. Four weeks with ten available hours each week gives you forty hours, not twenty full working days. Include the time you can reliably protect after your other responsibilities.

The 20% reserve is a starting assumption in this tool, not a universal rule. Familiar work may need less uncertainty allowance; unknown tools and integrations may need more. The reserve is not a secret allocation for optional features. It is space for the surprises that the current estimates did not capture.

Use a low and high estimate for each feature. A range makes uncertainty visible. If you have never built the feature before, break it into smaller tasks or run a short technical investigation before treating the estimate as a commitment. The planner’s learning setting applies a transparent 1.5× allowance to feature work; that multiplier is also a heuristic, not a measured prediction.

A worked example: a focus timer

The default “useful web tool” pattern includes a start/result screen, one working interaction and local saving. It also budgets time to investigate the problem, watch a person use the tool and make the first release.

At the upper estimate, 28 hours fits within the 32-hour work budget, leaving 4 hours of unallocated work time as well as the separate reserve. These numbers are authored planning assumptions for this example. They are not a claim that every timer can be delivered in that time.

Now add sign-in at 8–14 hours and cross-device sync at 5–9 hours. The total becomes 30–51 hours. The optimistic end still fits, but the upper end does not. At eight planned working hours per week, 51 hours needs seven weeks. Calling it a four-week plan would hide a real tradeoff.

You now have choices: keep the device-only version, extend the window, or revise the estimates using evidence from a smaller technical task. “Work faster” is not an extra source of capacity.

Look for the work behind the feature

“Add cloud sync” sounds like one box. In practice, someone needs an identity; their records need a storage shape; the application must check who can read and change each record; and failures must not silently discard changes. The visible switch is only part of the work.

The planner makes a few of these relationships explicit. Selecting sync also selects sign-in. A member posting board includes sign-in and moderation. Removing a prerequisite also removes its dependents, so the arithmetic cannot claim an impossible combination.

These are intentionally limited prototype patterns, not an exhaustive architecture model. Review the dependencies for your actual product. Hosted tools sometimes remove whole categories of implementation, while a custom infrastructure choice can add many more. Record provider setup, approvals and ongoing costs separately; the feature-hour range does not pay for them or guarantee access.

Write the first-release acceptance check

Define “done” as observable behavior rather than a percentage complete. For the timer, a useful check could be:

1. A first-time user can start a valid session without instructions from the maker.
2. Reloading restores the expected session state, or clearly explains why it cannot.
3. Pause, reset and completion have unambiguous behavior.
4. The main task works on a phone and with a keyboard.
5. Invalid values and unavailable storage produce helpful recovery, not a blank screen.
6. A real person has tried their own task and you have written down what happened.

Tailor the bar to the risks of the product. A small tool that handles no sensitive data has different requirements from a payment workflow or health-related service. Narrow scope does not excuse misleading behavior or unsafe data handling.

When even the core is too large

Do not keep deleting essential work until the number turns green. Change what the first version promises. A marketplace can start as a manually matched introduction. A directory can start with ten checked entries. A community can start with one facilitated session using tools that already exist.

Alternatively, make the first milestone an experiment: a paper flow, a spreadsheet service or a short usability session. Validate the assumption before building the software. A good result from that smaller step earns a reason to invest more; a poor result saves you from building the wrong thing more efficiently.

Keep a record of estimated versus actual effort after the first project. That evidence is more useful for the second project than a more precise-looking default range. Update the plan when you learn something, and keep the older version as a JSON backup if the decision history matters.