How to Price an AI Automation Project
An AI project has three costs and only one of them behaves like the software work you have quoted before. There is your build time, which ends when the build ends. There is the API cost, which starts when the thing goes live and never stops. And there is the human review time in the first months, while somebody checks the output often enough to trust it. Most quotes price the first, forget the third, and guess at the second.
Size the running cost before you build anything
You do not need a working system to know what it will cost to run. Take one typical request and estimate two numbers: roughly how much text goes in, counting your instructions and any documents you attach, and roughly how much comes back. Price that pair on a mid-tier model, then multiply by the requests you expect in a month. That is the whole calculation. Output is where the money goes, because providers charge several times more for it than for input, so a job that writes long replies costs far more than one that reads long documents and answers briefly.
Quote the ceiling, not the estimate
Your estimate will be wrong in the client's favour or yours, and you only care about one of those. Price the same workload on a flagship model as well as a mid-tier one. The gap is usually large: the same support bot can run $6.00 a month on the cheapest model we price and $1,080 on the most expensive. Quote against the high figure and you have room to be wrong. Quote against the low one and every surprise comes out of your margin.
The third cost is the one that sinks quotes
At small business scale the API bill is frequently the smallest of the three. What dominates is the build, the integration with the systems the client already runs, and the human time spent checking output in the first months. That third line is the one most quotes omit entirely, and it is the one that decides whether the thing survives contact with real customers.
Price it explicitly and taper it. Something like daily review for the first fortnight, weekly for the next month, then spot checks. Put it in the quote as its own line with an end date attached, because a client who sees it planned reads it as diligence, while a client who discovers it in month two reads it as a system that does not work.
Where the estimate goes wrong, and by how much
Three assumptions carry almost all of the error, and they are worth stress-testing individually rather than adding one blanket margin at the end.
Volume. Clients underestimate their own document counts routinely, and usually by a lot. Ask for last month's actual figure rather than a typical month, because the actual figure is a number they can look up and a typical month is a guess.
Context growth. Whatever you send today, the shipped version sends more. Retrieval gets widened to fix a quality complaint, examples get added, a policy document gets attached. Input per request rarely shrinks after launch.
The format the work arrives in. This is the one that produces order-of-magnitude misses rather than percentage ones. If the documents turn out to be scans or photographs rather than text, they are priced as images, and a page can cost several times what the same page costs as extracted text. Establish this before quoting, not after. A PDF can be either, and the test takes five seconds: open one and try to select a sentence. If nothing highlights, it is a picture of a page.
Put the recurring cost on its own line
Separate the build fee from the running cost in the document the client signs, because they behave differently and the client needs to understand that before they sign rather than after their first busy month. A fixed build fee plus a monthly API cost passed through at a capped amount is easy to explain and hard to lose money on. Fold the two together into one fixed number and you have quietly sold an unlimited resource for a fixed price. The structures that hold, and how to set the cap, are worked through in the guide on quoting fixed-price AI work.
Do not price in savings you have not made yet
It is tempting to quote thin on the assumption that models get cheaper. They do, in aggregate: our index has the cache-heavy agent workload down 48.4 percent since July 2024. But of the 26 monthly links in that series, only 11 carry a price change on a model present in both periods, which means the fall comes overwhelmingly from new models arriving cheaper rather than from cuts to the one you are running.
A saving that arrives as a new model name is invisible on your client's bill until somebody migrates and re-tests, and that somebody is you. Quote the price of the model you are shipping on, treat any future migration as a piece of work to be scoped when it happens, and let the savings be a pleasant conversation later rather than a commitment now.