July 2026 · 4 min read
How to plan an MVP without overbuilding it
A practical framework for deciding what ships now, what waits, and what probably shouldn't exist at all.
ZitDevs engineering
Most MVPs fail on scope, not on code
An MVP that takes nine months is not an MVP. It is a first release with an optimistic name, and by the time it ships the assumptions it was built on are a year old.
Overbuilding rarely comes from one large decision. It comes from thirty small ones that each seemed cheap: a settings screen, a second user role, an export, an admin panel to manage the export. Individually none of them is worth arguing about. Together they are the difference between six weeks and six months.
The framework below exists to make those thirty decisions once, in writing, before anyone estimates them.
Start from the decision, not the feature list
An MVP is an instrument for answering a question. Write the question down first, in one sentence, and make it falsifiable: not "will people like this", but "will operations staff enter shipments here instead of in the spreadsheet".
Once the question is explicit, every proposed feature can be tested against it. If a feature cannot change the answer, it is not part of the MVP, however cheap it looks.
- What decision does this release let us make?
- Who has to behave differently for the answer to be real?
- What number tells us the answer, and where is it measured?
- How long are we willing to wait for it?
The test
If two people on the team write down the MVP question separately and produce different sentences, the scope is not agreed yet. Fix that before estimating.
Sort everything into now, next, or never
Two buckets is not enough. Teams that only have "in" and "out" spend the project relitigating the out-pile, because nobody wrote down why something was excluded.
A third bucket, never, is what keeps the list stable. It is not a rejection of the idea; it is a record that the idea was considered and consciously declined for this release, with the reason attached.
Now
- Answers the MVP question directly
- Blocks the primary flow if missing
- Cannot be faked by a person or a spreadsheet
Next
- Needed for the second cohort of users
- Real value, but not evidence
- Deferred with a written trigger, not a date
Never
- Configurability with no second configuration
- Roles nobody has asked for yet
- Reporting that a CSV export already covers
Do by hand what you would otherwise build
Almost every internal tool in an MVP can be replaced for a while by a person doing the task manually. Onboarding, invoicing, refunds, approvals, moderation: all of these can run on a shared inbox and a checklist long before they run on a screen.
The rule we use: if the task happens fewer than five times a week and takes under ten minutes, it does not get an interface in the first release. Note the volume you are assuming, so you know when the assumption breaks.
This is the highest-leverage cut available and the one teams resist most, because manual work feels unprofessional. It is not. Building a workflow you have never performed manually is what produces the wrong workflow.
A caveat
Manual processes must be visible and owned. An undocumented manual step is not a decision, it is a liability you will inherit in month four.
Define done before you define the sprint
Write the launch criteria at the same time as the scope: which flow works end to end, on which devices, with what data, and what is explicitly allowed to be ugly. Anything not on that list is not a launch blocker, and saying so in advance is what stops the last two weeks from expanding into six.
Then agree what happens after. An MVP that ships without a scheduled review meeting produces no decision, and the whole exercise was a normal software project with extra pressure.
- One primary flow works end to end without staff intervention
- Real data, entered by real users, not seed data
- Errors are logged somewhere a human reads
- A review date on the calendar, with the metric named