Most estimates are wrong because they are produced from a brief rather than from the work. A two-day discovery is the cheapest way we know to replace assumption with evidence before anyone commits a budget.
Day one: what and why
Start with the business outcome, not the feature list. "We want a mobile app" is a solution; "our field technicians file paperwork nine days late" is a problem, and it admits several solutions with very different price tags.
Then map the current process end to end with the people who actually do it. This is where the surprises live — the spreadsheet nobody mentioned, the approval step that exists because of one incident in 2019.
Day two: how, and how much
Sketch the two or three shapes the solution could take and price them separately. Clients make much better decisions when the choice is "integrate with the existing ERP for X" versus "replace the stock module for 4X" than when handed a single number.
Identify the riskiest technical assumption and spike it that afternoon. One afternoon of prototyping against the real API answers a question that could otherwise wreck the estimate.
Deliverables
A scoped backlog, an estimate with an explicit confidence range, a list of assumptions that would change it, and a recommendation — including "do not build this" where that is the honest answer.
Who has to be in the room
Two people, and a workshop missing either of them produces a scope worth very little.
The first is whoever can make the decision. Not someone who will take it back to a committee — the person who can say "we are not doing that part" and have it stick. Without them you spend two days producing options that then get re-litigated by people who were not there.
The second is whoever actually does the work today. Managers describe the process as it is documented; the person doing it describes it as it happens, including the workaround they invented, the field they leave blank because it never worked, and the second spreadsheet they keep because the system loses things. That is where the real scope is.
What a confidence range means
An estimate expressed as a single number is a claim nobody can honestly make, and everyone in the room knows it. So ours come as a range with the reason for its width attached.
A narrow range means the work is well understood and the dependencies are ours. A wide one usually points at one specific unknown — an undocumented third-party integration, a data migration from a system nobody can currently query, a decision the client has not made yet. Naming that unknown matters more than the number, because it tells you what to resolve to make the estimate tighter.
The most common outcome
It is not "no". It is a smaller first phase than the client arrived expecting.
Discovery repeatedly finds that a third of the requested features exist because someone assumed they were necessary, that the genuinely valuable part is one workflow rather than a platform, and that shipping that one workflow in six weeks teaches you more about what to build next than six months of specification would. Phasing is not a way of deferring the work — it is how you avoid paying for the wrong version of it.
Why it is paid
A free scoping exercise has one permitted outcome: a proposal. Charging a fixed fee buys the client an honest recommendation and buys us the freedom to give one. The output is theirs to take elsewhere.