Scope lock
Also: scope freeze
What is Scope lock?
Scope lock is the point in a fixed-price, fixed-date project where the deliverables are written down and agreed, after which changes go through an explicit swap or a separate phase rather than silently expanding the build.
What Scope lock means
Scope lock is a written agreement, usually at the end of discovery or in the first days of a build, listing exactly what will be delivered: the user stories, the integrations, the languages, the acceptance criteria and the evaluation pass marks. It also lists what is out. From that point the team builds to the list, and new requests are handled in one of two ways: swap something of equal size out, or park it for the next phase.
The lock is what makes a fixed date honest. Without it, every good idea raised mid-build adds days, and the date slips while the price stays the same, which ends with either a late delivery or a quietly thinner one. With it, the conversation about a new request becomes "what do you want to trade for it?" rather than "can you squeeze it in?"
Scope lock is not a refusal to change. It is a rule about how change happens. It also does not lock design details that only become clear during the build, such as the exact prompt or the retrieval chunking strategy; those are the team's to decide within the agreed outcomes. It locks outcomes, not implementation.
Who it really matters to
- Founder / CEO: it is why a six-week date can be a real date rather than a hope.
- Product manager: it gives you a clear mechanism for prioritising new ideas without derailing the current build.
- CTO / Head of Engineering: it protects the team from context switching and lets them finish the hard parts properly.
- CFO: it is the discipline that makes a fixed price a genuine cap rather than an opening number.
Why it exists
Scope creep is the most common reason fast projects become slow ones, and it rarely arrives as one big change; it arrives as twenty small reasonable requests. Scope lock exists so each of those is a visible trade rather than an invisible cost. The failure it prevents is the MVP that is three weeks late and still not finished because the definition of finished kept moving. The trade-off is that some good ideas wait for the next phase, and the client has to make trade-off decisions quickly when a swap is proposed. In practice the parked ideas are better prioritised after real users have been seen.
Where it is applied
- A six-week SaaS copilot build where a mid-project request for a second language is parked to phase two rather than absorbed.
- A lending-workflow automation where a new document type raised in week three is swapped for a lower-priority report.
- A hospital voice-agent MVP where the locked scope is booking and rescheduling only, with all other intents handed off.
- A retail personalisation project with locked event definitions so the pipeline can be built without daily schema changes.
- A university ERP modernisation with a locked module list per phase, so go-live dates hold.
Is Scope lock a skill?
Technique / practiceA delivery technique used across every Eazyware fixed-price program, from Sprint Zero through Launch 6 and ReCore. It is written into the statement of work with a named change mechanism, so both sides know how new requests are handled.
Eazyware service that covers it: AI-Accelerated MVP. Starting prices are on the pricing page.
Frequently asked questions
Does scope lock mean we cannot change anything once the build starts?
No. It means changes are explicit: swap something of similar size out, or add it to the next phase. What it stops is silent accumulation of small requests that push the date without anyone deciding to.
When should scope be locked?
At the end of discovery, once the use case, integrations and acceptance criteria are understood well enough to size. Locking earlier bakes in guesses; locking later means the first weeks of build are spent on a moving target.