Scoping a Build So the Estimate Survives Contact

Estimates Do Not Fail at the Quote

Almost every estimate looks reasonable on the day it is written. It fails later, usually around week three, when the thing that was described as a settings page turns out to need permissions, migrations, audit history, and a state machine that nobody mentioned. The failure is rarely arithmetic. It is that the scope was written as a list of screens rather than a list of decisions.

This is the process I use, and it has survived enough projects to be worth writing down.

---

Separate the Unknown From the Undecided

Before anything gets a number, split the request into three buckets.

• Known. You have seen this built before, the shape is clear, and the risk is in execution speed.
• Undecided. Someone in the business has to choose, and until they do, the work cannot be estimated honestly.
• Unknown. Nobody knows yet, usually because it depends on a third-party system, a data set, or a migration.

The mistake is pricing all three the same way. Undecided items get a number as if they were known, then quietly grow. Unknown items get a number that is really a guess wearing a suit.

---

Timebox the Unknowns Instead of Guessing

Unknown work should not appear in the estimate as a line item. It should appear as a discovery block with a fixed cost and a defined exit: a spike, a prototype, a data audit.

For example, instead of estimating "integrate with the client's existing CRM" at 20 hours, spend six hours answering three questions: what does the API actually expose, what happens when it rate-limits, and who owns the mapping between their fields and ours. Then the 20 hours becomes an informed number, or it becomes a much larger number that everyone can see before the contract is signed.

---

Write Cut Lines, Not Deadlines

A deadline tells you when you have run out of time. A cut line tells you what to drop when you do. They are different instruments and you need both.

For every scope, define a first version that is coherent on its own. Then define what is explicitly not in it. When the schedule moves, you remove from the second list, not from the middle of the first.

• Launch: browse, search, detail page, contact form.
• Not launch: saved searches, comparison view, recommendation carousel, editorial dashboard.

The point is that dropping the carousel is a decision someone made in advance, not an argument in week six.

---

Make the Definition of Done Boring

Most scope disputes are disagreements about done, not about effort. A screen that "works" for a developer, a designer, and a compliance officer means three different things.

So define done in checkable terms: it renders on the supported browsers, it survives the seeded data volume, it fails with a message instead of an empty state, it is keyboard accessible, it has a test for the one behaviour that would be embarrassing to break. That list is unglamorous and it prevents most of the arguments.

---

Price the Change Order Up Front

Scope will change. The only real variable is whether changing it is a conversation or a crisis. Agree in advance on what a change costs, roughly, and how it affects the date. Even a rough rule, such as small changes absorb into the week and anything over a day re-plans the milestone, removes the negotiation from the moment when everyone is most stressed.

---

The Short Version

Estimate decisions, not screens. Pay to remove unknowns before you commit to a number. Decide what you will cut while you are still calm. Define done in terms you can check. Then the estimate has a chance of surviving contact with the actual build, which is all an estimate ever promised to do.