The short version
Count the hours the current process consumes in a month, multiply by twelve, and that is what the problem is worth solving. Buy a small scoped discovery before committing to a build. And be more suspicious of a confident fixed quote given without questions than of one that takes a week and arrives with caveats.
Why nobody quotes accurately up front
Because the same sentence — “automate our invoice processing” — describes two projects that differ by an order of magnitude. One business has clean data in a system with a documented API and a five percent exception rate. The other has PDFs in a shared mailbox, a warehouse system with a nightly CSV export, and a third of cases needing judgement.
A practitioner who quotes a firm price for either without looking is either padding heavily to cover the risk, or about to discover the problem mid-project and come back for more. Neither is what you want.
What actually drives the price
- Integration difficulty. Almost always the largest line. One system with no usable API can cost more than everything else combined.
- Exception rate. The clean cases are cheap. The cost is in the awkward ones, and how many rules have to be extracted from people's heads to handle them.
- Evaluation burden. Proving it works to an agreed threshold means building a test set and measuring against it. Skipping it is cheaper and is how projects fail.
- Governance requirements. A regulated business needs approval points, audit trails and sign-off. That work is real and it is not optional.
Notice that none of these is “the model”. The intelligence is largely a solved, commodity input. What you are paying for is everything around it.
What about the running cost?
Ask about it separately, because it is routinely left out of proposals and it does not stop. Three components: the token spend, which varies with volume and is usually the smallest; the human review time, which is a real ongoing cost and should be designed down deliberately; and maintenance, because models change, systems change, and something has to be someone’s job.
A proposal that quotes only the build cost is quoting the deposit, not the price.
How do I size the budget myself?
Do this before you speak to anyone, because it takes an hour and it changes every subsequent conversation:
- Count the people-hours the process consumes in a typical month.
- Multiply by your loaded hourly cost, then by twelve.
- Add anything the errors cost you — rework, late payment penalties, credit notes, lost customers.
That annual figure is what solving the problem is worth. A project priced well above it should be declined however impressive it sounds, and a project priced at a small fraction of it deserves a serious look. It also tells you whether to bother: a process costing eleven hours a month does not justify a build, and the honest answer there is a ready-made workflow or nothing.
Why pay for discovery separately?
Because it converts an unpriceable question into a priced one, for a small fraction of the build cost. Someone samples your real data, measures the clean-match rate, categorises the exceptions and tests whether the awkward system can be reached. The deliverable is a written recommendation with a scope and a price.
Two outcomes are both good. Either you get a proposal you can compare against other proposals on substance rather than day rate — or you get told not to build it, which is the cheapest possible version of that answer and worth every penny of the discovery fee.
What a fair proposal looks like
It separates discovery from build. It names an accuracy threshold and how it will be measured. It states the running cost as well as the build cost. It says who owns the prompts and code afterwards. And it names at least one thing that could go wrong.
A proposal with no risks listed is a sales document. Every real project has three or four, and a practitioner who has delivered before will tell you what they are without being asked.
Why are the quotes so different from each other?
Because they are pricing different projects. One practitioner has assumed the awkward system can be reached through an existing connector; another has assumed it needs a custom integration and has priced three weeks for it. One has included an evaluation harness and a test set; another has not. One has priced maintenance; another expects you to ask.
That spread is useful rather than confusing, but only if you read the proposals for assumptions rather than totals. Ask each of them the same question — what did you assume about the integration, and what happens to the price if that assumption is wrong — and the numbers become comparable.
Should we do a proof of concept first?
Usually, but define it as a question rather than a demonstration. A proof of concept that shows the technology can produce a plausible output has proved something nobody doubted. A useful one answers a specific risk: can we reach the warehouse system, what is the real exception rate on a full month, does accuracy hold on the messy client rather than the tidy one.
Set the question, the budget and the decision it informs before it starts. Proofs of concept that drift into indefinite pilots are the most common way budget disappears without a deployment at the end of it.
What are the hidden costs?
Four, in rough order of how often they are missed:
- Your own people's time. Someone internal has to explain the process, find the data, answer questions and test the output. This is real and it is never in the quote.
- Change management. The team has to trust it, which takes a parallel run and some persuasion.
- The integration you were told was simple. Budget contingency specifically here, because this is where overruns come from.
- Ongoing review time, which persists forever and should shrink deliberately rather than by accident.
How do we avoid paying twice?
Own the assets. The prompts, the configuration, the evaluation set and any integration code should be yours at the end, in your repository, documented well enough that a different practitioner could pick them up. Agree that at contract stage, in writing.
Without it, the second phase can only be quoted by the person who built the first, and they know it. The evaluation set matters most and is most often forgotten — it is the thing that proves the system works, and rebuilding one from scratch is a meaningful cost on its own.