17 January 2026 · 4 min read
Write the out-list first
An in-scope list without an explicit out-of-scope list invites additions. Naming what is deliberately excluded makes each addition a visible decision with a cost.
Review the out-list at every milestone. Items move in, but by agreement.
Define done per feature
'User can upload a file' hides a dozen decisions: size limits, formats, virus scanning, failure handling. Specify them or accept the estimate is a guess.
Acceptance criteria written before the estimate makes the estimate meaningful.
Ship something narrow and real
A complete flow for one user type beats partial flows for three. Narrow scope that actually works produces usable feedback; broad scope half-built produces none.
Pick the single most important user journey and finish it.
Where to go from here
If you are weighing MVP scoping for an upcoming project, the useful next step is usually a short scoping conversation rather than a longer article. Bring your constraints — budget, timeline, existing systems, and the team you already have — and the decision usually resolves itself in an hour.
We run these as a fixed-scope discovery session with a written recommendation at the end, including the cases where our advice is that you do not need us.
Working on something like this?
Send us the brief. We will tell you what we would build, what we would cut, and roughly what it costs.
Talk to us