Scope an MVP That Ships in Weeks, Not Quarters

Most MVPs that take two quarters were scoped as six-week projects. Nothing went catastrophically wrong. The team added a settings page, then roles, then an invite flow, then password reset, then an audit log because an early customer asked about compliance. Each addition was two days. Forty of them is four months.

The failure is not discipline. It is that most scope documents are written as a list of features, and a list of features has no natural stopping point. Every feature suggests a neighbor. A login screen implies a signup screen implies email verification implies a transactional email provider implies a template system. You cannot argue your way out of that chain once you are inside it. You have to scope in a shape that does not generate the chain in the first place.

We have shipped 77 platforms and we operate three of our own products. The ones that got to a real user fastest were not the ones with the smallest feature lists. They were the ones scoped around a single transaction that had to complete end to end, with everything else deferred until that transaction worked for a real person who was not on the team.

Scope one transaction, not a feature list

Write down the single sequence of events that has to happen for your product to have created value once. Not a persona, not a journey map. One sequence, with a start and a finish, that ends in something a user would notice if you took it away.

For EzyEvite, that transaction is: a host describes an event, gets an animated invitation they like, sends a link, and a guest RSVPs without creating an account. Everything in the EzyEvite product that came later — the gift registry, the shared photo album, seven languages — hangs off that spine. None of it was in version one, and none of it could have been designed sensibly before the spine existed.

The transaction gives you a test that a feature list cannot. For any proposed piece of work, ask: if this does not exist, does the transaction still complete? If yes, it is not in the MVP. That is a mechanical rule, and mechanical rules survive contact with a founder who has just come back from a customer call excited about a new idea.

The five things you cannot cut

There is a small set of work that people cut to save time and then pay for at triple cost three months later. From what we have had to retrofit on other people's codebases, this is the list.

1. Tenancy boundary. Even if you have one customer, decide now whether data is isolated by row, by schema, or by database. Retrofitting isolation into a single-tenant codebase is a rewrite of every query you have written. We operate 700+ tenant databases and the ones that hurt were the ones that started without a boundary.
2. Auth with real identity. Not a full user management suite. One provider, one session model, one place that answers "who is this request from." Roles can wait; identity cannot.
3. Money handling, if you charge money. If revenue is part of the MVP hypothesis, the payment path is part of the transaction. If it is not, do not build billing at all.
4. Deploy pipeline on day one. A commit-to-production path that runs without a human reading a runbook. This costs a day at the start and saves a week per month afterward.
5. Observability on the one transaction. Structured logs and an error tracker scoped to the spine. You do not need dashboards. You need to know when the thing that matters fails.

Notice what is not on the list: admin panels, settings pages, notification preferences, onboarding wizards, password reset flows you wrote yourself, and anything described as "we'll need it eventually."

The four-question cut, applied to every request

When a new feature request arrives mid-build — and it will, weekly — run it through this in order and stop at the first no.

• Does the transaction fail without it? If no, it is post-MVP. Write it down and move on.
• Can a human do it manually for the first 20 customers? If yes, do that. Manual onboarding, manual refunds, manual data imports. All of these are a spreadsheet and thirty minutes until they are not.
• Does an off-the-shelf service do 80% of it for under $200 a month? If yes, buy it. We have written about the five questions that settle build versus buy, and the answer at MVP stage is almost always buy.
• Does it change the data model? If yes, it needs a real decision now even if the feature ships later, because schema changes are the expensive kind of change.

That fourth question is the one people skip. A feature you will not build for six months can still constrain your schema today, and a fifteen-minute conversation now beats a migration across every tenant later.

Write the scope as acceptance criteria, not nouns

"Inventory management" is not scope. It is a category, and categories expand to fill available time. Scope is a testable statement about behavior.

Here is the difference, in the format we actually use in a build plan:

# Not scope
- Inventory management
- Reporting
- Multi-location support

# Scope
- A staff user can adjust on-hand quantity for one SKU at one
  location, and the new quantity is visible on the POS within 5s.
- An owner can export the current on-hand list for one location
  as CSV. No filters, no scheduling, no email delivery.
- Out of scope for v1: transfers between locations, purchase
  orders, cycle counts, cost tracking, reorder points.

The out-of-scope block matters as much as the in-scope block. It is the thing you point at in week four when someone asks why transfers are not working. Without it written down, every deferred decision gets relitigated, and relitigating decisions is where weeks actually go.

When we scoped the first version of the takeoff engine in BuildAEC, the in-scope statement was that a vision model reads a plan sheet and produces line items with per-line confidence scores. Estimating templates, assembly libraries and AIA progress billing were all written down as out of scope, with dates. They shipped later, on purpose, after the takeoff output was good enough that estimating on top of it made sense.

What actually eats the quarter

In our experience the schedule rarely dies on the feature everyone was worried about. It dies on four things nobody put in the plan.

Integrations you do not control

Marketplace APIs, payment processors, accounting systems, hardware. These have sandbox environments that behave differently from production, approval processes measured in weeks, and rate limits you discover at load. When we built marketplace sync for Retailer OS, the connector logic was the easy part. Reconciling four platforms' notions of what a variant is took longer than writing any of them.

If your MVP depends on a third party, start that integration in week one, not week five, even if the rest of the product is not ready to use it.

Data that arrives dirty

Every product that imports customer data underestimates the import. Real catalogs have duplicate SKUs, prices as strings with currency symbols, and encoding that breaks on the first accented character. Budget for the import being a feature, or decide explicitly that the first customers get onboarded by hand.

Environments and secrets

Staging that does not match production, credentials in three places, and one person who knows how the deploy works. This is why the pipeline goes in on day one.

Design revisions with no stopping rule

Pick a component library. Accept that the MVP will look competent rather than distinctive. Visual identity is worth real money later, once you know which screens people actually spend time on.

Where this advice does not apply

Tight scoping assumes you can defer things safely. Some products cannot.

If you are handling protected health information, card data, or anything with a regulator attached, the compliance boundary is part of the first transaction. You cannot bolt an audit trail onto a system that was not logging. The same is true for offline behavior: we built offline-first point of sale because a retailer whose internet drops cannot stop selling, and offline sync is an architectural decision, not a feature you add in month four.

It is also true for anything where the hard technical risk is the product. If the entire bet is that a model can extract quantities from a construction drawing accurately enough to be useful, then the MVP is that extraction working, and there is no version of it that ships in three weeks because a wrapper around a UI is not the thing being tested.

An MVP is not the smallest product you can build; it is the smallest thing that can prove you are wrong.

A six-week shape that works

For a typical SaaS or consumer product with no unusual technical risk, this is the sequence we run.

1. Week 0, three days. Write the transaction. Write acceptance criteria. Write the out-of-scope list with dates. Decide the tenancy boundary. Pick auth, payments, hosting, and the component library. No code.
2. Week 1. Deploy pipeline, auth, schema, and a page that says hello in production. Start any third-party integration approval that has a queue.
3. Weeks 2–4. Build the transaction, one acceptance criterion at a time, deploying every day.
4. Week 5. Real data. Import, edge cases, error states, the things that only appear when a person who did not build it tries to use it.
5. Week 6. Instrumentation on the transaction, a short manual runbook for the things you deliberately left manual, and one real user.

Six weeks is a shape, not a promise. Integrations, regulated data, hardware or a genuine model-accuracy bet push it out, and we will say so in the estimate rather than discover it in week five. Our approach page covers how we price and phase that work, and the breakdown of what a custom SaaS platform costs sets the numbers against scope.

If you have a transaction written down and an out-of-scope list you are willing to defend, you are already in better shape than most projects at kickoff. Bring both to a conversation about the build and the estimate will be worth something.