Every estimate is a probability distribution presented as a number. The problem is not that estimates are wrong — it is that the shape of the uncertainty gets thrown away in the process.
Estimate assumptions, not tasks
"Build the integration: 40 hours" carries no information about risk. "Build the integration: 40 hours, assuming their API supports webhooks and sandbox access exists" tells the client exactly which unknown could double the number.
When you list assumptions explicitly, the conversation shifts from haggling over hours to resolving unknowns — which is the work that actually reduces cost.
Ranges with reasons beat single numbers
A range communicates uncertainty honestly, but only if the endpoints are explained. What has to be true for the low end? What drives the high end? Without that, a range is just a bigger number.
- Low end: every assumption holds, no scope discovery.
- High end: the two or three specific risks you have identified materialise.
- Anything outside the range: a new conversation, not a silent overrun.
Re-estimate in public
Estimates decay. The useful discipline is re-forecasting every couple of weeks against what you now know, and telling the client the same week the number moves — not at the deadline.
We wrote this because we had to solve it. See what we built or tell us what you're working on.