Scope lock: the discipline that makes fast MVPs possible

MVP scope is the one variable a team fully controls, and it is the one most often left loose. A minimum viable product that ships in six weeks is not the result of heroic speed; it is the result of deciding by day five exactly which user segment, which workflow and which single AI capability are in, writing that down, and sending every other good idea to a backlog with a price against it. Scope lock is the name for that decision and the discipline of holding it. Without it, no delivery method, fixed price or AI acceleration will save the date.

This article explains what to lock, when, how to run the backlog so the sponsor does not feel shut out, and what scope creep in an MVP actually looks like from the inside, because it rarely announces itself.

Why MVP scoping decides the date

Software delivery has three variables: scope, time and cost. Fixed-price, fixed-date programs fix two of them, so scope has to be the one that flexes, and it can only flex downward. A team that accepts additions without removing anything has silently converted a fixed-date project into an open-ended one, whatever the contract says. The awkward truth is that every addition is individually reasonable. Scope does not creep because anyone is careless; it creeps because good ideas arrive weekly and nobody has the authority, or the mechanism, to say "not in this version."

Scope lock gives both. It sets a date after which additions go to the backlog by default, and it names the person who can override that default by removing something of equal size.

What to lock: one segment, one workflow, one capability

One segment, because designing for two kinds of user doubles the workflows and halves the clarity. One workflow, because a product that does one thing completely is worth more to its first users than one that does four things partly. One AI capability, because each capability needs its own evaluation suite, its own threshold and its own shadow-mode period, and those do not compress. If the business case needs more, that is the argument for v1.1, not for a larger v1.

Why day five

The first week of an MVP is for learning what the first users actually do, confirming the data and the integrations exist, and cutting the scope to what those facts support. By the end of day five the team knows enough to lock, and after it the cost of change rises sharply: the data model is being built, the AI capability is being evaluated and the integrations are being wired. A lock on day one is made without evidence; a lock on day fifteen is too late to protect the date. Day five is the compromise that works, and the discovery sprint that often precedes an MVP means much of the evidence already exists on day one.

Running the priced backlog

The backlog is what makes scope lock tolerable for a sponsor. Every request that arrives after the lock is written down with a rough size, a rough price and a note on why it matters. Once a week the sponsor and the lead engineer review it together. The sponsor has three choices for each item: leave it in v1.1, swap it into v1 by removing something of similar size, or fund it now as a paid extension with a date impact stated. Nothing is refused; everything is priced. The backlog leaves the program as a costed plan for the next phase rather than a list of grievances.

Two rules keep this honest. The swap must be size-for-size, assessed by the engineer, not the sponsor. And the review is weekly, not on demand, so the team has five uninterrupted days between decisions.

What scope creep in an MVP looks like

• "While you are in there": a small addition to a feature already being built, repeated weekly
• The second user type that "just needs a read-only view"
• The integration that turns out to have two versions, and both are needed
• The AI capability that grows from answering questions to taking actions without a new eval
• Polish requested before the workflow works end to end
• A demo to an important audience that pulls the team onto a feature nobody planned
• Requirements that arrive as screenshots of a competitor

None of these is unreasonable. Each is a backlog item. The failure mode is treating them as clarifications rather than additions, which is why the lock is written down: a clarification changes how something in the document is built, an addition changes the document.

What the lock does for the AI capability

AI features have a cost that conventional features do not: each one needs a labelled sample, an evaluation threshold, a run of benchmarks, a period in shadow mode and a permission policy. Those steps take calendar time regardless of how fast the code is written, which is why one capability fits in six weeks and two rarely do. Locking to one capability also concentrates the evaluation effort, so the thing that ships has been measured properly rather than two things measured thinly. If a second capability is genuinely essential, the honest answer is a second phase, and the backlog is where it waits.

A worked example

A field-service B2B SaaS company began a six-week MVP for an in-app copilot with a candidate list of seven capabilities across three user types. The first four days of interviews and log review showed that technicians closing a job generated most of the support tickets and most of the wasted time, and that one capability, answering "how do I complete this job" from the manuals and the job record, covered the bulk of it. Scope was locked on day five to technicians, the job-completion workflow and that one capability, with an evaluation suite and a threshold. The other six capabilities, the manager dashboard and the customer-facing assistant went to a priced backlog. Over the following five weeks the sponsor swapped one item in (a hand-off to a human dispatcher) and removed one (a settings page), and funded nothing extra. The MVP shipped on the date with real technicians using it; the backlog became the v1.1 plan. The product is described in the in-app copilot case study.

Team and timeline

Scope lock is built into Launch 6, our six-week AI-accelerated MVP program: days one to five for discovery and lock, weeks two to five for the build with weekly backlog reviews, week six for shadow mode, hardening and launch. The program is fixed price at $26,500–45,500 or from ₹17,60,000, and the team is a lead engineer, one or two product or AI engineers and an architect. From your side, the essential role is a sponsor with authority to say no, available for one hour a week. When the product is a copilot inside an existing SaaS, the build sits within our SaaS copilot service. All figures are on the pricing page, and the wider picture of what six weeks buys is in What a six-week AI MVP actually contains.

Before you start: a checklist

• Name the one user segment and the one job they need done
• Draw the one workflow from trigger to outcome on a single page
• Choose the one AI capability and write its threshold before building
• List the integrations the workflow cannot run without, and stop there
• Name the sponsor who can say no and book the weekly backlog review now
• Agree that additions after day five go to the backlog by default
• Agree that swaps are size-for-size as sized by the engineer
• Decide now what v1.1 means: a second fixed-price phase, funded on the evidence of v1

Glossary

• Scope lock: the written decision, by day five, of the segment, workflow and capability in v1
• Priced backlog: everything else, each item with a rough size and cost, reviewed weekly
• Swap: replacing a locked item with a backlog item of similar size
• v1.1: the next fixed-price phase, planned from the backlog
• Clarification vs addition: a clarification changes how a locked item is built; an addition changes the lock
• Shadow mode: the final week, in which the AI capability runs on live inputs under review before launch

Related reading

Fixed-price AI development: how it works and when it fits explains why the lock is what makes a fixed price possible, and Startup AI MVP: what investors expect to see covers the case where the audience for v1 is a funding round. Eric Ries's The Lean Startup remains the primary source on why minimum means minimum.

Lock one segment, one workflow and one capability by day five, price everything else, and the date stops being a hope and becomes a plan.