An estimate is a prediction made with incomplete information. Treating it as a commitment is how projects end in a dispute, and the failure usually happens at the moment the estimate is written rather than months later when it is missed.
Give a range, and mean it
A single number implies a precision nobody has. A range communicates the actual state of knowledge: fourteen to eighteen weeks says something true, while sixteen weeks says something false with more confidence.
The objection is that clients want certainty. In our experience they want honesty and will accept a range, particularly when you explain what would move the estimate towards each end. What clients genuinely dislike is a confident number that turns out to be wrong.
Write the assumptions down, all of them
Every estimate rests on assumptions, and the ones that go unwritten are the ones that break it. Assumptions about API availability, data quality, how quickly feedback arrives, who signs off, whether the third-party integration is documented.
We attach the assumption list to the estimate as a peer of the number, not an appendix. When one turns out false, the conversation is "assumption four did not hold, here is the revised range" rather than "you are over budget". The first is a project conversation. The second is a commercial dispute.
Separate build cost from run cost
A number that covers only development is incomplete in a way that surprises people badly in month four. Infrastructure, third-party services, monitoring and support are ongoing, and they belong in the same document as the build figure.
This matters most in cloud work, where an architecture decision made for elegance can produce a monthly bill nobody modelled. Quoting run cost during design forces that trade-off into the open while it is still cheap to change.
Estimate the work you have understood
Estimating a backlog item that has not been analysed produces a number with no information in it. If discovery has not happened, the honest output is a discovery estimate plus a rough order of magnitude flagged as such.
Clients occasionally push for a full estimate before scope exists. Providing one is not helpfulness, it is deferring a difficult conversation to a point where it will be more expensive.
Re-estimate in writing when scope moves
Scope always moves. The failure is not the movement, it is absorbing it silently until the timeline quietly breaks. Every change request gets a written impact on the range before work starts, even when the impact is small.
The cumulative effect of small unrecorded changes is the single most common reason a project that was "on track" arrives late.
The measure that matters
We track the gap between our post-discovery estimate and final delivery, and we review the misses. Estimates that came in accurate because the team quietly worked weekends count as misses. That is how you learn anything from the number.
Our delivery methodology sets out where estimation sits in the wider process, and what happens either side of it.