What a Custom AI Feature Actually Costs

Ask three studios to price the same AI feature and you will get three numbers that do not resemble each other. This is usually read as a pricing problem. It is almost always a scoping problem. The three teams have each imagined a different product, and the spread between their quotes is the spread between those imaginations.

That is frustrating if you are trying to budget. It is useful if you are trying to learn something. The variance tells you exactly where the uncertainty lives, and the uncertainty is where your money goes.

Why does the same feature get three different prices?

"Add an AI assistant to our dashboard" is not a specification. It is a category. Underneath it sit a dozen decisions that nobody has made yet, and each one carries a cost.

Does the assistant answer from a fixed set of documents, or from live application data? Does it need to respect per-user permissions? Can it take actions, or only suggest them? What happens when it is wrong, and who finds out? Is there an existing search index, or does one need to be built? How current does the data have to be, daily, hourly, instant?

A studio that assumes the cheapest answer to each of those questions produces one number. A studio that assumes the most rigorous answer produces another, four times larger. Neither has quoted incorrectly. They have quoted different products.

The first thing worth understanding about AI pricing, then, is that the quote is a summary of assumptions. If you cannot see the assumptions, you cannot compare the quotes.

What actually moves the number?

In practice, most of the cost variance in AI development work comes down to five things.

• /Data readiness. Whether your source of truth is clean, current, permissioned, and structured, or whether someone has to make it so first.
• /Retrieval complexity. A fixed document set is cheap. Live data across four systems with row-level permissions is not.
• /Action surface. Reading is cheap. Writing is expensive, because writing requires review paths, audit trails, and rollback.
• /Accuracy threshold. The distance between useful and trustworthy is not linear, and the last few points of reliability often cost more than the first eighty.
• /Integration depth. A feature that lives beside your product is a fraction of the cost of one that lives inside it.

Of those, data readiness is the one that most often blows a budget, and the one clients are most surprised by. It is also the one discovered last, usually after engineering time has already been spent. Gartner has predicted that 60% of AI projects lacking AI-ready data will be abandoned through 2026, which is less a statement about AI than a statement about how much unglamorous work sits underneath it.

This is why we treat data assessment as a strategy engagement rather than a line item inside a build. Finding out what condition your data is in costs a small amount of money. Finding out halfway through a build costs a great deal more.

What does the quote leave out?

Traditional software has a build cost and a hosting cost, and the hosting cost is boring and predictable. Intelligent features do not work that way. They have a build cost, and then they have a per-use cost that scales with how successful they are.

During a pilot this is invisible. A handful of users, a few hundred queries a week, a bill small enough that nobody looks at it. Then the feature works, adoption climbs, and the run cost climbs with it, sometimes faster than linearly, because successful features get used in ways nobody modelled. Industry reporting through 2026 has started describing this as tokenmaxxing, and the pattern rhymes closely with early cloud adoption: consumption-based pricing that looks trivial at pilot scale and becomes a board-level line item at production scale.

The practical consequence is that a quote which covers only the build is answering half the question. Before you approve anything, you want a modelled run cost at ten times pilot volume, and you want to know which architectural choices are driving it. Often the answer is that a cheaper model, a tighter retrieval step, or an aggressive cache changes the economics entirely, and those are design decisions best made before the build rather than after the first surprising invoice.

A quote that covers only the build is answering half the question. The other half arrives monthly, and it grows when the feature succeeds.

Why are cheap pilots so expensive?

There is a well-circulated figure that 95% of enterprise AI pilots produce no measurable profit impact. It comes from an MIT report that was preliminary, not peer-reviewed, and has drawn real methodological criticism, so it is worth treating as directional rather than precise. The more defensible numbers point the same way with less drama. Gartner's 2024 forecast that at least 30% of generative AI projects would be abandoned after proof of concept had, by January 2026, been revised upward to at least 50%. A 2026 study from Beam.ai found that 42% of AI projects showed zero return, and that 61% had been approved on projected ROI that was never measured after launch.

Read those together and a pattern emerges that has very little to do with model quality. Projects are not failing because the technology underperformed. They are failing because nobody defined what success would look like in terms the person holding the budget recognises, and so the project could not survive its first serious review.

That last statistic, approved on a projection and never measured after launch, is the expensive one. It describes work that was priced as a build and never scoped as a decision. We have written separately about where AI actually creates product value, and the short version applies here directly: if you cannot name the decision the feature makes faster, you are buying a demo.

A cheap pilot that answers no question costs you its full price. An expensive pilot that retires a real risk is a bargain by comparison.

How should you read a proposal before signing it?

You do not need to be technical to interrogate an AI quote usefully. You need to find the assumptions.

• /Which specific decision or workflow does this feature change, and for whom?
• /What condition is our data in, and who verified that before this number was written?
• /What is the modelled run cost at ten times pilot usage?
• /What happens when the output is wrong, and what does the correction path cost to build?
• /What would we measure eight weeks after launch to know this worked?
• /What is explicitly out of scope in this number?

The last question is the most revealing. A proposal with no exclusions has not been thought about. A proposal with a clear, specific, slightly uncomfortable list of exclusions has been written by someone who has done this before.

If the answers to those six questions are vague, the number attached to them is also vague, regardless of how precise it looks on the page.

What we would tell you before you spend anything

Scope the smallest version that produces evidence. Not the smallest version that demos well, the smallest version that generates data about whether the full thing is worth building. Those are different, and the difference is usually the entire project.

The sequencing we use is deliberate: understand the decision, assess the data, model the run cost, build the narrow version, measure it against a manual baseline, then decide. Each phase closes with a decision rather than a document, which is how our five-phase method is structured across every engagement, AI or otherwise. It is the same discipline we apply to scoping a first release, because the underlying problem is identical: you are not buying features, you are buying the retirement of specific risks, in order.

You can see how that plays out in practice in Project Orbit, an AI-powered operating system for agency teams. The brief mentioned AI, but the first phase defined the objects the business actually runs on before any retrieval or generation was introduced, because no model can reason over information that was never joined.

The honest answer to what a custom AI feature costs is that it costs whatever the unresolved decisions cost. Resolve them early and the number gets smaller and far more reliable. Resolve them late and you pay for them twice.