Scoping an MVP that ships in 90 days

We have shipped more than twenty MVPs over the past six years. The ones that made it to market in 90 days were not the ones with the smallest ideas or the biggest budgets. They were the ones where scope was decided ruthlessly in week one and defended every week after that.

This post walks through the scoping method we use on every startup engagement. It is not clever. It is a set of constraints applied early and enforced consistently.

Why 90 days is the right box

Ninety days is long enough to build something real and short enough that nobody can hide. A six-month plan lets vague requirements survive until month four, when they become expensive. A 12-week plan forces every ambiguity into the open by week two, when it is still cheap to resolve.

There is also a market reason. If your idea has any merit, someone else is circling it. Feedback from 50 real users in month four beats a polished feature set in month nine. The MVP is not the product. It is the fastest honest test of the product.

Start with the one job

Every MVP we scope starts with a single sentence: "This product helps [who] do [what] without [the painful thing they do today]." If the founding team cannot agree on that sentence in one workshop, the problem is not scope. The problem is that there are two products fighting for one budget.

Once the sentence exists, everything in the backlog gets tested against it. A lending platform we built for Prosper Capital started with 40 proposed features. The sentence was "help small businesses get a credit decision in under 48 hours." Only 11 features survived the test. The product went live in 11 weeks and processed its first loan the same month.

The cut list is the real deliverable

The most valuable artifact from scoping is not the feature list. It is the cut list: the written record of everything you decided not to build yet, and why. Without it, every cut feature comes back in week six wearing a different name.

Things that almost never belong in a 90-day MVP:

• Admin dashboards. A shared database view and a weekly export cover the first three months.
• Roles and permissions. Two roles maximum: user and admin. Granular permissions can wait for the second customer who demands them.
• Native mobile apps. A responsive web app reaches every device on day one. Build native when usage data proves you need it.
• Integrations beyond one. Pick the single integration that unblocks the core job. Queue the rest.
• Custom reporting. Nobody knows which reports matter until real data exists.

Fixed timeline, flexible scope

We run 90-day builds as six two-week sprints with one rule: the launch date does not move. When something takes longer than estimated, and something always does, scope flexes instead. Every sprint review ends with the same question: "If we had to launch tomorrow, what would we cut?" Asking it every two weeks keeps the answer from being a crisis.

1. 1Weeks 1-2: scoping workshop, one-sentence job, cut list, clickable prototype of the core flow.
2. 2Weeks 3-8: build the core job end to end first, then widen. A thin working slice beats three half-built modules.
3. 3Weeks 9-10: put it in front of 5-10 friendly users. Fix what blocks them, ignore what merely annoys them.
4. 4Weeks 11-12: hardening, monitoring, a rollback plan, and launch.

What good looks like at day 90

A good day-90 product does one job completely, has real users doing that job, and has instrumentation telling you what they do next. It will feel embarrassingly small to the founding team. That is normal. The products that failed in our portfolio were not the small ones. They were the ones still in development at month eight.

If you want to see how we structure the engagement itself, from workshop to handover, our delivery process covers it in detail.