What Decides AI Development Cost, and Who Decides It

Search this and you get ranges. A proof of concept costs this much, a production system costs that much, an enterprise platform costs some larger figure, and each page presents its numbers with the confidence of a price list. Put four of those pages side by side and the ranges barely overlap, which tells you something more useful than any of the individual figures does.

A range that spans an order of magnitude is not an estimate. It is a statement that the question as asked has no answer, dressed up as an answer. And the question as asked genuinely does not have one, because the thing being priced is not specified: a chatbot over your help centre and a system that reads contracts and files them are both "AI development", and nothing about the phrase distinguishes them.

What is worth having instead is the method. There are four cost lines in a build of this kind, they behave differently from each other, three quantities decide most of the total, and all three of them are yours rather than a vendor's. You can reach a defensible figure for your own project in an afternoon, and the point of doing so is not to avoid hiring anyone. It is that you cannot evaluate a quote against nothing.

There is no one number, there are two

The first mistake is asking what it costs, singular. A build has a one-off cost and a recurring cost, they are approved by different people on different cycles, and the second one is the one that decides whether the project survives its second year.

Keep them apart from the first conversation. A system quoted at a capital figure with no monthly figure beside it has not been scoped, it has been described. And the recurring number is the one that gets a project cancelled, because a capital overrun is an unpleasant conversation that happens once, whereas a monthly cost nobody budgeted for is a conversation that happens every month until somebody switches the system off.

The four lines, sorted by whether they stop

The distinction that matters is not what each line is called. It is whether it ends when the build ends.

Build labour. Design, engineering, integration, testing, the work of getting from nothing to something running. This is the only one of the four that stops, and it is the only one most quotes cover. It is also the line everyone anchors on, which is how the other three end up unbudgeted.

Model usage. Every request you send costs something, priced separately on the text going in and the text coming out. This does not stop, and it scales with use rather than with complexity, which is counterintuitive: a simple task performed constantly costs more to run than a sophisticated one performed rarely. Providers publish their current rates, and Anthropic's pricing documentation is the authoritative page for its own models rather than any summary of it. We have a longer piece on what you are actually billed for, because the structure of the bill changes much more slowly than the rates do.

Infrastructure. Anything you run yourself: storage for the documents, a database for the retrieval index, compute for the parts that are not a provider call, logging, backups. This does not stop either, and it is the most predictable of the three recurring lines, which makes it the easiest one to get a real number for before anyone quotes you.

Upkeep. Someone noticing that the answers got worse. Sources change, permissions change, a model is deprecated and the behaviour you tuned against moves. This is a staffing cost rather than a procurement one, it is the line no proposal contains, and it is the one that quietly decides whether the system is still working a year after launch.

Three of those four recur. If a quote prices one of them and mentions the others as considerations, you have been given a build price and no cost of ownership, and those are not the same document.

The three quantities only you can supply

Here is why no published range can be right for you. The total is dominated by three quantities, and a vendor cannot know any of them until you tell them.

How many times it runs. Per day, realistically, including the retries and the cases where it fails and runs again. Most people estimate this from the happy path and land low by a wide margin. The exception traffic is traffic.

How much context each run carries. This is the quantity that surprises people most, because it has nothing to do with how hard the task is. A question answered against one short document and the same question answered against a bundle of retrieved passages and a long instruction block differ enormously in cost, and they look identical in a demo.

How much of it is yours to run. A system that only calls a provider has almost no infrastructure line. A system that holds your documents, indexes them and serves retrieval has a real one. This is a design decision, usually taken early, and it moves the recurring total more than the choice of model does.

Supply those three and the arithmetic is not difficult. Refuse to supply them and no number anybody gives you means anything, which is precisely why the published ranges are as wide as they are.

Turning a feature description into a monthly figure

This is mechanical rather than clever, and it takes about as long as reading one of the pricing guides.

Take one realistic request from the thing you want built, not a short example. Write out what actually goes into it: the instruction, the retrieved context, the conversation history if there is any, and the length of the answer you expect back. Then put that through our LLM cost calculator at the volume from the first quantity above. That gives you the model usage line as a monthly figure.

If any part of the plan runs on your own infrastructure, the AWS cost calculator gives you the shape of that line in the same session. It will not be exact and it does not need to be. You are looking for whether the answer is a rounding error or a budget item, and that distinction is usually obvious at the first pass.

Then put the monthly total against the monthly value. This is the step that is routinely skipped and it is the whole point of the exercise: a build is worth paying for when the recurring cost is comfortably below the recurring benefit, and the capital figure is a secondary question answered by how long you are prepared to wait for the difference to pay it back. Done in that order, the arithmetic occasionally ends the project, and ending it at this stage costs an afternoon rather than two quarters.

What moves a build quote most, and it is not the model

If you are comparing proposals, the lines that vary most between them are rarely the ones being discussed.

Model choice moves the recurring line and barely touches the build. It is also the single easiest thing to change later, so treating it as a major decision at the start is usually misplaced effort.

The condition of your data moves everything. Data that is reachable, which means a named system, a way to query it and someone who can authorise that, is a different project from data that exists in principle across several places nobody owns. The second version is mostly a data project with a model attached, and it is priced as the first version by anybody who has not looked.

The integration surface moves the build line hard. One system to read from and one place to write to is a small piece of work. Four systems, two of which have no usable interface and one of which is owned by a team with its own roadmap, is not a larger version of that task, it is a different task with dependencies you do not control.

And the definition of working moves the whole thing. A system that has to be right most of the time, with a person reviewing the output, is dramatically cheaper than one trusted to act unsupervised. That is a single sentence in a specification and it is frequently the largest cost driver in the document.

Questions that make two quotes comparable

Ask these and the ranges collapse into something you can actually read.

• What is the monthly cost at the volume we gave you, split into model usage and infrastructure?
• Which of the four lines above does this price cover, and which are excluded?
• What assumption did you make about the state of our data, and what changes if that assumption is wrong?
• Who owns this after launch, named, and what is that person's time costed at?
• What does the system do when it cannot answer, and who sees that?
• What would make you recommend we do not build this?

The last one is worth more than the rest together. A proposal from someone who can describe the conditions under which their own service is the wrong purchase is a proposal from someone who has thought about your case rather than about their pipeline.

If you are earlier than comparing quotes, our AI readiness assessment covers the same ground a scoping conversation opens with, across data, use cases, skills and infrastructure. It is free, and a result saying nothing is ready yet is a real answer rather than a failure. That answer is considerably cheaper to arrive at now than after a statement of work is signed.