Almost every software project that overruns did so against an estimate produced before anyone understood the requirement properly. The estimate was not wrong because the team was slow. It was wrong because it was produced at the point of maximum ignorance and then treated as a commitment.
The problem with a single number
When a client asks "how long will this take" at the first meeting, any answer is a guess. The honest response is a range wide enough to be almost useless commercially — which is why most vendors give a confident number instead, and why so many projects then run over.
A single number also hides the thing that actually matters: which parts of the work are understood and which are not. Two projects estimated at four months can carry entirely different risk profiles.
Estimate the shape, not the total
We break work into three categories. Understood work is something we have built repeatedly — authentication, CRUD screens, standard integrations. Estimates here are reliable within about twenty per cent. Partially understood work has a clear goal and unclear implementation. Unknown work is where a requirement depends on something nobody has examined yet, typically a third-party system nobody has documented.
Sizing each bucket separately gives a far more useful conversation than a single total. It shows where the risk sits and what would reduce it.
Buy information before committing
The most effective thing a client can do is fund a short discovery phase before agreeing a fixed price. Two or three weeks spent mapping the process, examining the systems that need integration and producing a prototype converts most unknown work into understood work.
The estimate that follows is genuinely more accurate, and the cost of discovery is almost always less than the contingency a vendor would otherwise build into a fixed price.
Re-estimate as you learn
An estimate produced in week one should not still be governing decisions in month four. We re-forecast at the end of each increment based on what has actually been delivered, because measured velocity on this project is a much better predictor than any upfront assumption.
This makes overruns visible early, when there are still options — cut scope, add capacity, or move the date — rather than at the point where the only remaining option is disappointment.
What to ask a vendor
If a supplier gives you a precise number for a complex project in a first meeting, ask which parts they consider understood and which they do not. The quality of that answer tells you considerably more about how the project will go than the number itself.