How to Scope an MVP So It Actually Ships in 14 Days
Most MVPs miss their deadline because they were scoped wrong, not built slowly. A step-by-step framework for scoping a feature tight enough to ship in two weeks.
Matching serviceLaunch a new web appWhen 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 feature that ships in 14 days.
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 can't state the outcome in one sentence, the scope is too big to ship in two weeks. Keep cutting until it fits in a sentence.
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, run the scope through one final filter: could an experienced engineer build, test, and deploy this in 14 days with the auth, database, and hosting included? If the honest answer is 'maybe, if nothing goes wrong,' the scope is still too big. Cut one more thing.
A scope that fits comfortably ships early. A scope that fits 'if nothing goes wrong' ships late, because something always goes wrong.
Continue with the right path
Related guides
Have a feature in mind? Compare the launch starting points before deciding whether Founder Launch, Launch Sprint, or waiting fits the scope.
See launch pricing