How to Scope an MVP With a Realistic Delivery Plan

When an MVP misses its deadline, the cause is almost never slow engineering. It's a scope that was never shippable in the first place. A vague scope expands to fill - and overflow - whatever time you give it.

Scoping is the highest-leverage thing you can do before a single line of code is written. Here's the framework we use to turn a fuzzy idea into a useful first release with a schedule that includes dependencies and contingency.

Start From the Outcome, Not the Feature List

Don't list features. Write down the single outcome a user should be able to reach. "A user can sign up, connect their calendar, and share a booking link" is a scope. "A scheduling app" is a wish.

If you cannot state the outcome clearly, keep narrowing the scope until the user, problem, and acceptance checks are easy to review.

Write Acceptance Criteria Before You Build

Acceptance criteria are the contract: a concrete, testable list of what 'done' means. They prevent the two killers of fixed-time projects - scope creep and the endless 'just one more thing.'

• Each criterion is a single, checkable statement: 'A logged-in user can delete their own post.'
• If a criterion needs the word 'and', split it into two.
• Anything not on the list is explicitly out of scope - and that's a feature, not a bug.

Separate the Core Flow From the Nice-to-Haves

Every feature has a spine - the one path that delivers the value - and a lot of ribs hanging off it. Build the spine end to end first. Settings, edge cases, and polish are ribs; they wait until the spine is live.

• Core flow: the single path from entry to value, working end to end.
• Defer: admin tooling, bulk actions, granular permissions, exotic edge cases.
• Hardcode: anything that can be a sensible default instead of a setting.

The 14-Day Fit Test

Before committing, list the client inputs, access, vendor dependencies, acceptance checks, and contingency needed to estimate the work honestly. If the schedule only works when nothing changes, the scope is not ready for a fixed commitment.

A useful first release has a clear outcome and a schedule that acknowledges what the client and third parties must provide.