"How long will it take?" is a legitimate question. The answer "four months" is almost always a polite lie.
The problem with a single number
A single-value estimate communicates a certainty nobody has at the start of a project. When reality overtakes it, the client feels misled and the team feels misunderstood. Both are right.
What we do instead
We estimate with a range and a confidence level, and both narrow as we learn more.
- At the end of discovery: a ±20% range, with the assumptions written out explicitly.
- After the first two sprints: a ±10% range, calibrated on the team's real velocity.
- Every sprint: budget spent, budget remaining and the projection to completion.
Assumptions matter more than the number
Every estimate we give comes with the list of assumptions it rests on: "we assume vendor X's API is documented", "we assume data migration covers only the last three years". When an assumption fails, we redo the estimate and explain why.
In practice, that list is the most useful document in the project. It turns the conversation about a budget overrun from a conflict into a business decision.
What the client gains
Real predictability rather than false comfort. A client who knows at the end of month two that the project will overrun by 15% can decide to cut scope. A client who finds out in month six can decide nothing at all.