How we scope fixed-price work so the estimate survives contact

Fixed-price contracts have a bad reputation in software, and often deserve it. The usual failure is structural: a number is committed before the requirements are understood, the requirements then change, and the rest of the project is an argument about whether each change was in scope.

We still do fixed-price work, because clients often need budget certainty. We just scope it differently.

Discovery is a paid, time boxed phase

We do not estimate a build we have not investigated. The first phase is a short discovery, usually one to three weeks, with its own fixed price. It produces a technical approach, a prioritised scope, the main risks, and a range.

The estimate is a range with its drivers named

A single number pretends to a precision nobody has. We give a range, and we say what moves you across it: the integration that turns out to be undocumented, the data migration that is messier than it looked, the design that needs another round. The client can see which risks they are carrying and decide which to buy down.

Scope is a ranked list, not a checklist

We rank every item by value. The contract commits to the top of the list, the part we are confident fits the budget. The rest is a named backlog. If discovery was accurate we get through most of it. If something was harder than expected, the thing that drops is the lowest value item, agreed in advance, not the thing we happened to run out of time for.

A change budget is in the contract from the start

Requirements will change. Pretending otherwise is how you end up in dispute. We put a change allowance in the contract, a percentage of the total, that covers reprioritisation without a new statement of work. When it runs low, that is a real conversation about scope, held early, not a surprise at the end.

We bill milestones against working software

Each milestone is tied to something demonstrable running in a real environment, not to a document or a percentage. It keeps the project honest and it means the client is never paying ahead of value delivered.

What the client gets

• A budget they can commit to, with the risks visible
• A scope ordered so the most valuable work is guaranteed
• Room for change without a contract renegotiation
• Payments tied to software they can see and use