What AI development actually costs

Because three things drive the price and none of them is settled in a first conversation: how many systems have to be connected, what state your data is in, and how much it matters when the answer is wrong.

The third one surprises most people. An application that drafts something a colleague reviews anyway is a fraction of the work of one that has to justify a tax answer with an audit trail. Same technology. Completely different project.

Anyone quoting a number without knowing those three is guessing. And guessing in their own favour.

One clean data source is straightforward. Running inside Outlook, pulling records from your CRM, reading documents out of your archive, and writing results back to a fourth system is not.

Every integration brings its own questions. Is there an API? Who is allowed to see what? What happens when that system is down for an hour? The work is estimable, but it is never zero — and it is almost always the part that overruns.

So map early which systems genuinely have to be involved. Not which ones could conceivably be involved. That is the fastest way to double an estimate.

Messy is normal. Documents in fifty layouts, scanned PDFs, fields everyone fills in differently — we plan for that. Dealing with it is part of the work.

What does block a project is different. Data we are not allowed to touch, or data nobody owns. The first is a legal question, the second an organisational one. Technology solves neither, and both cost weeks when they surface halfway through.

So your data does not need to be clean to start. It needs to be reachable, and somebody needs to be able to explain how it is put together.

This factor explains most of the budget, and it is the one that most often comes up only once building has started.

If a wrong answer means somebody redoes a task, you can build lightly. If it reaches a customer, costs money, or creates liability, a series of things arrive with it: source citation on every answer, a test set from your edge cases, approval before anything irreversible, and logging that lets you reconstruct what happened and why.

None of that is luxury. In regulated work it is the condition for being allowed to run at all.

Every request costs money in model usage. That figure does not stay flat — it grows with your usage.

Work it out in advance at realistic volumes. What does this cost per month at a hundred users, and at ten thousand? An application that works technically but loses money per user is still a problem. You just find out once things go well, and by then you are committed.

Caching, a smaller model where one will do, and how much context you send per request: those three move the number substantially. They are architecture decisions, not settings you switch on later.

Break it up. One scoped process, its own budget, its own decision point at the end.

After that first working version you will know roughly what a second process costs — measured against your reality rather than a generic benchmark. And if the first version disappoints, you have lost one process instead of an annual budget.

• One process at a timeWith its own budget and a point where you can stop.
• Model the usage cost firstCost per request times realistic volumes. Before you start, not after.
• Price the failure modeThat answer sets roughly half the budget, so ask it in the first conversation.
• Ask about the road to productionPermissions, error handling, logging, measurement. This is where estimates come apart.