The typical estimate starts from the price per unit of text processed, multiplies it by the expected volume, and arrives at a reassuring figure. That is usually where the estimate's accuracy ends too.
What makes it into the estimate
- The cost of model calls, or of the infrastructure to run one.
- Development time for the integration.
What is almost always missing
Data preparation. Collecting, cleaning, deduplicating, fixing formats, resolving contradictions. For many projects this is the largest and least predictable part.
Labelling. If you need correct examples for evaluation or training, someone has to produce them. Good labelling takes time from people who know the domain — precisely the busiest people.
Evaluation. Building a representative test set, defining metrics, running evaluations on every change. Without it you do not know whether a change improved or broke something.
Iteration. The first version is almost never good enough. The budget has to cover several improvement cycles, not just the first delivery.
Operation. Monitoring, incident handling, periodic re-evaluation, updates when the supplier changes or retires a model. A system in production has a permanent cost.
Organisational change. Training people, adapting procedures, handling resistance. A technically good system inside an unchanged process produces very little.
Costs that grow unexpectedly
Long contexts. Sending a whole document with every request multiplies the volume processed. A system that looks cheap at ten requests a day looks different at ten thousand.
Retries. Validating output and retrying on failure can double the real volume against the estimate.
Development itself. Testing, debugging and evaluation consume resources too, sometimes more than production in the first months.
Worth asking before approval
- What is the total cost for the first year, including operation, not just development?
- What happens to the cost if volume doubles?
- What does a month of operation cost after delivery, and who pays for it?
- What is the exit cost if the system does not work?
- What simpler alternative was evaluated, and why was it rejected?
The last question is the most useful. Sometimes the right answer is a rule written by a person, a better form, or a database query — at a tenth of the cost and with no risk of hallucination.