The honest range, before anything else
Someone asks what it costs to add an AI feature to a product they already run. A useful answer exists and it is a range: for a single feature that reaches real users and stays up, plan on $60,000 to $180,000 of engineering, six to fourteen weeks of calendar time, and a recurring cost afterwards of roughly fifteen to twenty-five percent of the build price per year. Small, tightly bounded features come in under that. Anything touching regulated data, or replacing a workflow that a hundred people already depend on, goes above it.
That range is wide because the phrase "an AI feature" covers work that differs by a factor of five. "Summarize this ticket for the agent" and "read every contract we have signed and tell me which ones have an auto-renewal clause" are the same sentence length and not the same project. The first has one input, one output, and no consequence if it is occasionally vague. The second has forty document layouts, a legal reader who will not accept an answer without a citation, and a wrong answer that costs money.
So the useful thing is not the average. It is knowing which line items the money goes into, which of them your situation inflates, and which of them a vendor is quietly leaving out of the quote you are holding. That is what the rest of this is.
You are probably here because
- Two vendors quoted the same paragraph and the numbers are four times apart
- A quote came back at $40,000 and you cannot tell what is missing from it
- Someone internal said "we can do this in a weekend with an API" and you are not sure they are wrong
- You need a number for a budget cycle and the honest answer is that nobody has looked at the data yet
The cost-lines table below explains the four-times gap. The run-cost section explains the number nobody put in either quote.
The seven lines the money goes into
Every custom AI feature we have priced breaks into the same seven pieces. The proportions move a great deal. The pieces do not.
| Line item | Typical share | What it actually is |
|---|---|---|
| Scoping and data read | 5–10% | Looking at real records, writing the acceptance test, finding out what the feature has to be right about |
| Data access and preparation | 15–30% | Getting to the data, cleaning it, handling the formats nobody mentioned, building the retrieval index |
| The model layer | 10–20% | Prompting, retrieval, structured output, tool calls, occasionally a fine-tune |
| Evaluation | 10–20% | A labeled test set, a scoring harness, and the number that decides whether it ships |
| Application and interface | 20–30% | The screens, the states, the error handling, the place a human corrects the machine |
| Deploy, monitor, control cost | 10–15% | Getting it live, logging, rate limits, spend caps, an on-call story |
| Handover | ~5% | Documentation, a runbook, and a session where your team runs it without help |
Read that table against any quote you are holding. If a proposal has a big number for the model layer and nothing for evaluation, you are buying a demo. If it has nothing for the interface, you are buying an API endpoint and you will pay someone else to make it usable. Neither is dishonest, exactly. Both are incomplete in a way that shows up later at your expense.
The model call is the cheapest thing in the project
The part everyone pictures, the call to the model, is usually ten to twenty percent of the work and often less of the running cost. Buyers routinely arrive assuming the opposite, because that is the part with a price list on a public website. It is the part with a price list precisely because it is the commodity.
Where the hours actually go is unglamorous. Getting a service account provisioned. Discovering that thirty percent of the documents are scans of faxes. Finding out that the field called "status" means three different things depending on which year the record was created. Writing the code path for what happens when the model returns something the downstream system cannot accept. None of it makes a good slide, and all of it is the project.
What moves the estimate most, as we weight it at quote time
Editorial weighting from our own estimating practice, shown to explain the shape of a quote. Not a measured statistic.
The bottom row is the one worth sitting with. Model choice is the topic of most vendor conversations and it is the smallest cost lever in the building. Data condition beats it by a factor that is not close.
Evaluation is the line that gets cut, and the one that decides the outcome
A feature that produces text or a judgment needs a way to answer the question "is it working" that does not depend on someone's mood in a demo. That means a held-out set of real examples with correct answers attached, and a script that scores against them. Building that costs real money, typically ten to twenty percent of the project, and it is the first line a buyer under budget pressure asks to remove.
Removing it does not save the money. It moves the money to a worse place. Without a scored test set there is no way to tell whether a prompt change on Tuesday made things better or worse, so every change becomes an argument. There is no way to tell whether the feature degraded when the vendor updated the model underneath you. And there is no way to defend the feature when a stakeholder finds one bad answer and concludes the whole thing is unreliable. One bad example is not data. A scored set is.
A workable minimum is smaller than people fear. Two hundred to five hundred real examples with adjudicated correct answers, gathered by a person who knows the domain, will settle almost every argument you are going to have. Expect a subject-matter expert to spend two to five days on it. That is the cheapest insurance in the project.
The labeled examples belong to you, not the vendor
Whoever builds the test set is building a durable asset: the definition of correct for your business, in a machine-readable form. Put it in the agreement that the labeled set and the scoring harness are delivered to you and remain yours. It is what lets you switch vendors, switch models, or bring the work in house without starting the argument over. A vendor who resists this is telling you something.
The interface costs more than the model, and it should
Twenty to thirty percent of the build usually goes into the part users touch, which surprises people who think of this as an AI project. It is not padding. An AI feature has states an ordinary feature does not: it is thinking, it is unsure, it found nothing, it found something but cannot show its source, a person disagreed with it. Every one of those needs a design and a code path.
The single highest-value piece of interface in most of these features is the correction path. When the machine is wrong, can a person fix it in place, and does the correction get recorded? That one decision does three things at once. It makes the feature usable on day one at a mediocre accuracy level. It creates the labeled data that makes it better. And it converts the feature from something people distrust into something they operate. Features shipped without a correction path get abandoned quietly, and the postmortem usually blames the model.
Four things that double a quote
The output has to be defensible to an outsider. If an auditor, a regulator, a customer or a court might ask why the system said what it said, every answer needs a traceable source, and the storage, the display and the retention of that trace are real engineering. This is the most common reason a feature that looked like $80,000 is honestly $180,000.
The data cannot leave your environment. Running inside your own cloud account, a customer's tenancy, a compliance boundary, or fully disconnected changes hosting, logging, key management and who is allowed to touch the machine. Budget four to eight additional weeks the first time an organization does this, most of it waiting on approvals rather than writing code.
It writes into a system of record. Reading is cheap. Writing into a billing system, an EHR, an ERP or a case management system brings permissions, reversibility, an audit trail and a conversation with whoever owns that system. That owner's calendar is frequently the longest pole in the project.
Nobody has agreed what correct means. When two stakeholders would score the same output differently, the project has a governance problem wearing an engineering costume, and it is expensive because it consumes calendar rather than hours. This one is free to fix before the work starts and very expensive to fix in week nine.
Three things that halve it
A human is already in the loop. If the output lands in front of a person who was going to do the task anyway, the accuracy bar drops from "right" to "better than a blank page," and a large amount of engineering falls away with it.
The scope is one document type, one workflow, one team. Breadth is what costs. A feature that handles one form perfectly is worth more than one that handles nine forms adequately, and it costs a fraction.
You can hand over real data on day one. Fifty genuine records at the kickoff meeting routinely save two weeks of assumption and rework. If real data cannot leave, synthetic records with the same structure and the same mess still help enormously.
The run cost, and how to work it out yourself
The recurring number is where budgets get surprised, because the build quote is a single line and the run cost arrives monthly forever. It has four parts and you can estimate three of them on a napkin.
Model usage. Take the tokens in one typical call, both directions, multiply by the calls per month, and multiply by the published per-million price of whatever model you use. Do the arithmetic once. For most internal features the answer is startlingly small, tens or low hundreds of dollars a month, and buyers who assumed this was the main cost relax. For high-volume customer-facing features it can dominate, at which point caching and routing cheap requests to smaller models become real engineering with real savings.
Infrastructure. Hosting, a database, a vector index if retrieval is involved, logs. For a single feature at modest volume this is commonly a few hundred dollars a month. Self-hosted models on dedicated GPUs are a different category entirely and are worth it only at sustained volume or when data residency forces it.
Engineering attention. The line nobody writes down and the largest one. Model versions change under you, an upstream system alters a field, volume grows, someone finds a class of input that breaks it. Plan on fifteen to twenty-five percent of the original build cost per year to keep a feature healthy. If that seems high, the alternative is not zero, it is a feature that decays until someone declares the pilot a failure.
Human review. If a person checks output before it counts, that is a real operating cost and it belongs in the business case beside the savings. A feature that saves ninety seconds per case and adds thirty seconds of review still wins, but only if both numbers are on the page.
Send us a quote you already have and we will tell you what is missing from it.
Email the scope and the price to contact@precisionfederal.com, with the vendor name removed if you prefer. You get back a short written note naming the line items that are absent, the assumptions the number depends on, and the questions we would ask before signing. One business day. No charge and no meeting.
contact@precisionfederal.comThree sizes, with numbers attached
| Shape | Example | Engineering | Calendar |
|---|---|---|---|
| Contained | Summarize or classify one thing, shown to a person who can ignore it | $25,000–$60,000 | 3–6 weeks |
| Standard | Extract fields from documents, with citations and a correction screen | $70,000–$160,000 | 7–12 weeks |
| Consequential | Output enters a system of record, or an outsider may audit it | $180,000–$400,000 | 4–8 months |
Those figures assume senior engineers at US market rates, which for this kind of work generally run $150 to $250 an hour whether they are billed that way or carried as salary. They assume no research risk: a technique that is known to work is being applied to your specific data. And they assume a decision-maker who can answer a question within two business days, which is worth more to a schedule than almost any technical choice.
What a fair quote looks like on paper
Price is not the first thing to compare. Comparability is. Two quotes are only comparable if they answer the same questions, and most of the four-times gaps we are asked to explain turn out to be one vendor quoting a demo and the other quoting a product.
- A sentence defining done, with a number in it that someone can test without the vendor present
- An explicit statement about the data: what was examined, what was assumed, and what happens if reality differs
- A named deliverable list including the evaluation set and the scoring harness
- The recurring cost, stated separately and with the arithmetic shown
- What triggers a change order and what is the vendor's own risk to absorb
- Who owns the code, the prompts, the labels and the model artifacts at the end
- A handover plan that ends with your team running it once, unaided
Where the money gets wasted
- Paying for a proof of concept that was never going to become the product, because nothing in it was built to survive
- Skipping the evaluation set, then arguing about quality for the rest of the engagement
- Buying breadth first, so nine workflows are half-served and none is trusted
- Fine-tuning before trying retrieval and a better prompt, which is a five-figure detour most projects do not need
- Letting the vendor keep the labeled data, which converts a switching decision into a rebuild
- No spend cap on the model API, so a retry loop becomes an invoice
- Budgeting the build and nothing else, so year two arrives with no owner and no line item
What to send to get a real number
From a paragraph to a defensible price
Nothing on that list needs to be polished. A rough version of all five beats a beautiful version of two, because the estimate is only as good as the worst-understood input, and the worst-understood input is nearly always the data.
Bottom line
A custom AI feature is a software project with one unusual property: the hard part is establishing what correct means and proving you hit it, not calling the model. Budget for the data work and the evaluation, insist that the labeled set and the harness are yours, put the run cost on the page next to the build cost, and treat model choice as the small decision it is. Do that and the range at the top of this article narrows to a number you can defend to a board. Skip it and you will get a low quote, a good demo, and a second project next year to do it properly.
Frequently asked questions
Almost always because they scoped different things. The low bid usually excludes the evaluation set, the correction interface, deployment into your environment, and any handling of the messy minority of your data. Compare the deliverable lists before the prices. If one quote does not name an acceptance test with a number in it, the two documents are not describing the same product.
Yes, and often you should. A tightly bounded first block, one document type or one workflow, with a real acceptance test, commonly runs $25,000 to $60,000 and produces something usable rather than a slide deck. The condition is that it must be built to survive: the same data path, the same logging, the same tests as production work. A cheap block built to be thrown away teaches you very little.
Model usage plus infrastructure is frequently a few hundred dollars a month for an internal feature at modest volume, and you can compute it yourself from tokens per call, calls per month and the published per-million price. The larger number is engineering attention, which runs fifteen to twenty-five percent of the build cost per year. Put both in the business case at the start.
Usually not first. Better retrieval, a clearer output schema and a well-tested prompt solve most business tasks at a fraction of the cost, and they can be changed in an afternoon. Fine-tuning earns its place when you need a consistent format at very high volume, when latency or unit cost matters at scale, or when the task depends on tone or conventions no prompt captures. It also creates an asset you now have to version and re-run whenever the base model moves.
Six to fourteen weeks for a standard feature, and the schedule is usually set by things that are not engineering: data access approvals, the owner of the system you write into, and how fast someone can answer a question. Teams that shorten this do it by assigning one decision-maker with a two-day response commitment and by handing over real data at kickoff.