What an AI feature actually costs to build

Nobody asking this question wants a range. They want a number they can defend to somebody else, and every answer they get back is "it depends" followed by a discovery call.

So here is the structure of the number, what actually moves it, and the two places where estimates are usually wrong by an order of magnitude.

The number has three parts, and only one of them is inference

Most people asking about AI feature cost are thinking about the API bill. In almost every project we have seen, that is the smallest of the three.

The bill you are worried about is the one you will barely notice. The cost that hurts is the engineering you will do twice.

What building actually costs

A useful frame: an AI feature is a normal software feature plus one hard part. The normal part prices like normal software. The hard part is where estimates break.

A thin feature — 2 to 4 weeks. Summarisation, classification, drafting, a chat interface over documents you already have indexed. One model call, no accuracy guarantee beyond "a person reads it before it matters". This is genuinely quick, and if a vendor quotes you three months for this, ask what they think the hard part is.

A pipeline that has to be right — 8 to 16 weeks. Extraction into a system of record, anything a customer sees unreviewed, anything financial, medical or legal. The extra time is not the model. It is the eval harness, the confidence scoring, the review queue, the provenance trail, and the fifty document variants you had not seen when you scoped it.

An agentic system that acts — 12 to 24 weeks. Everything above plus approval gates, idempotency, retry semantics, and cost ceilings. The agent logic is often two weeks of that. The rest is making it safe to leave running.

At typical contract rates that puts a thin feature somewhere around $8k–$20k, a real pipeline around $25k–$60k, and an agentic system north of $50k. If your number needs to be far below that, the answer is usually to shrink the scope rather than shop the price.

The two estimates that are always wrong

Data cleanliness

Every estimate assumes documents that look like the ten you sent as samples. The ten you sent are the clean ones — you chose them, and you chose ones that demonstrate the problem clearly.

Production is photographs at an angle, a second currency, a handwritten total, a layout the vendor changed last month, and a PDF that is actually a scan of a printout of a spreadsheet. Every one of those is a day, and there are more of them than anyone expects.

The fix is cheap: before scoping, pull two hundred random real documents — not selected, random — and look at them. That afternoon is the single highest -return thing you can do to an estimate.

The definition of done

"It works" means one thing to the person building it and another to the person who has to answer for it. Pin the accuracy target and who reviews the failures before the build, because "good enough" is where fixed-price projects go to die.

Concretely: what percentage of records may need human correction before the feature is not worth having? If the answer is "none", you are describing a review queue, not an automation, and it should be priced as one.

What inference actually costs

Real numbers, for a document extraction pipeline at 100,000 documents a month, averaging three pages each:

• Naive — every page, full document context, largest model, no caching. This is what a prototype does. Assume this is your ceiling.
• Cached — hash each page, skip pages you have already read. On real document sets with repeated boilerplate, headers, and re-submissions, this typically removes 50–70% of calls on its own.
• Escalated — route every page to a small model first, and only re-run the ones that come back below your confidence threshold on the large one. Typically another 60–80% off what remains.

The compounded effect is usually an order of magnitude, and the escalated version is more accurate than the naive one, because building it forces you to have a confidence threshold at all.

If your inference bill is genuinely your dominant cost, you almost certainly have no caching and are sending whole documents where a page would do. That is a two-week fix, not a model choice.

When the honest answer is not to build it

Three cases where we have told people to stop:

1. The volume does not justify it. If a person spends four hours a week on this, the annual cost of the problem is a few thousand dollars. Do not spend $40k automating it. This is more common than you would think, because the task feels enormous to the person doing it.

2. A vendor already solves your exact case. Standard invoices, standard receipts, common languages — there are good APIs for that, and building your own to save the subscription is a bad trade until you are well into six figures of annual spend.

3. You cannot define correct. If the team cannot agree what a right answer looks like, no amount of engineering fixes it. You do not have an AI project; you have an unresolved product decision wearing one as a costume.

How to get a number you can defend

• Pull 200 random real inputs and look at them.
• Write down the accuracy target and who handles the failures.
• Decide whether a human reviews output before it matters. This single answer moves the cost more than any other.
• Get the estimate broken into build / maintain / inference, and be suspicious of any quote that does not separate them.

If you want that done properly on something you have already shipped, that is what the audit is — fixed scope, fixed price, and the output is a written number rather than a proposal.