Why we charge for discovery, and why you should want us to
Free proposals are paid for somewhere. Usually it is in the estimate, in the change requests, or in the corners quietly cut to protect a margin nobody discussed.
Prospective clients occasionally find it odd. Other companies will produce a full proposal, a timeline and a fixed price at no cost. We ask to be paid for the phase that produces those things.
It is a fair question and it has a straightforward answer: a free proposal is not free. You pay for it somewhere else, usually in ways that are harder to see.
What a free proposal actually costs
When a vendor produces a detailed estimate at no charge, they have spent perhaps two days on something that might not convert. That cost is real and it goes somewhere.
It goes into the estimate. Every proposal carries the cost of the ones that did not close. You are paying for their sales overhead inside your project price.
It goes into optimism. A free estimate has to be attractive enough to win. There is commercial pressure to assume the smooth path — no integration surprises, no messy legacy data, no third-party API that turns out to be undocumented. The number that wins the deal is not the number that reflects the work.
It goes into change requests. When the assumptions turn out to be wrong, the shortfall is recovered through variations. This is where projects acquire a reputation for going over budget, and it is often nobody behaving badly — the original estimate was simply produced without enough information.
It goes into corners. Sometimes the margin is protected by reducing what is not visible: testing, documentation, error handling, accessibility. You get software that demos well and costs more to own.
What a discovery workshop produces
A paid discovery is two to five days of structured work with your team. It is not a sales exercise with a nicer name; it produces artefacts.
A written scope. What is in, what is explicitly out, and the assumptions each depends on. The exclusions are the valuable part — they are where later disagreements originate.
An architecture outline. The system's shape, the data model, integration points, security model and hosting approach. Enough for a competent engineer to disagree with it, which is the test of whether it says anything.
A risk register. The things that could go wrong, how likely, how expensive, and what would reduce them. The undocumented API, the data quality nobody has checked, the third-party dependency with a rate limit.
A costed plan. Phases, milestones, a realistic range rather than a single reassuring number, and what drives it up or down.
A clickable prototype, for projects where the interface is central. Not a mockup — something you can put in front of a user.
All of it is yours. You own the output whether you continue with us, take it to another company, or decide the project is not worth doing.
The case where discovery pays for itself immediately
We have run discovery workshops that concluded the client should not build the software.
One wanted an inventory system. Two days of mapping showed the actual problem was a receiving process that recorded stock in the wrong unit of measure. A software system would have automated the error faster. The fix was a process change and about four hours of work.
That workshop cost a fraction of what the platform would have, and saved several months of building the wrong thing. It also, incidentally, produced a client who has sent us three referrals since.
A vendor whose revenue depends on winning the build is poorly placed to reach that conclusion. One who is paid for the thinking can afford to.
How to judge whether a discovery is worth buying
Not all paid discovery is worth paying for. Ask before committing:
"What documents do we receive, and do we own them?" The answer should be a specific list, and the answer on ownership should be an unqualified yes.
"Who from your side attends?" You want the architect and the delivery lead who would run the project — not a business analyst who hands notes to an unnamed team afterwards.
"What happens if discovery concludes we shouldn't build this?" A good answer is that they will tell you, and you keep the analysis. Discomfort here means it is a sales process.
"Is the fee credited against the build?" Many companies, us included, credit some or all of it if you proceed. Reasonable, and worth asking.
What it costs
Ours run from about USD 1,500 for a focused piece of work up to USD 6,000 for a complex multi-system platform involving several stakeholder groups. Typically two to five days.
Against a project of USD 40,000 or more, that is a small percentage to spend on being confident the plan is right — and on having an estimate produced by people who looked properly rather than guessed politely.
The underlying principle
Estimating software well requires understanding the problem. Understanding the problem takes work. Work costs money.
Any process pretending otherwise is hiding the cost, not removing it. Given the choice between an accurate estimate that took real effort and a comfortable one produced in an afternoon, the accurate one is cheaper — every time we have seen it tested.