Why 'how much does AI cost' is the wrong question
The question hides three different cost questions inside one. There is the cost to build a first AI feature, the cost to operate that feature in production, and the cost to evolve the feature as models, data, and requirements change. They are different orders of magnitude and they are paid by different budgets in most companies.
Pricing pages from agencies usually answer the first question and downplay the other two, which is why finance teams find their costs higher than the proposal six months in. The honest answer to a leadership team is the total cost over a meaningful time horizon (12-24 months), not the headline number on a statement of work.
We do not publish pricing because every project is bespoke. What we can publish is what drives cost, so you can compare proposals on substance rather than on a single number that hides where the money actually goes.
What actually drives cost
Five drivers explain most of the variance in AI project cost. The first is scope. A feature that handles five intents costs roughly a fifth of one that handles fifty, all else equal. Most cost overruns trace to scope expansion during build, not to the original scope being underpriced.
The second is data complexity. Clean structured data with good labels is cheap. Unstructured documents in mixed formats with inconsistent labelling are expensive. Sensitive data (PII, regulated content) is expensive in a different way: it adds compliance, security, and architectural overhead.
The third is integration depth. A standalone AI feature that runs against a clean API is cheap to integrate. A feature that has to write into a legacy ERP, respect existing permissions models, and coexist with a deterministic rules engine is expensive, often more expensive than the AI itself.
The fourth is the governance bar. A feature for an internal team that can tolerate the occasional miss is cheap to govern. A feature for external customers in a regulated industry needs evaluation, monitoring, audit trails, human-review queues, and incident response, all of which cost real money to build and operate.
The fifth is iteration velocity. A team that ships once and stops is cheap. A team that intends to iterate continuously needs the platform components (eval, monitoring, deployment) that make iteration safe, and those components are mostly fixed cost regardless of how many features run on them.
Cost archetypes: discovery, build, ongoing
Discovery is usually the cheapest phase and the highest-leverage. A focused two-week discovery surfaces the scope, data, integration, and governance constraints that decide whether the build is sensible. Skipping discovery to save discovery cost almost always increases build cost by a multiple.
Build cost varies enormously based on the five drivers. A scoped first feature in the four-to-eight week range is the most common shape we see. Features that promise to be larger usually benefit from being broken into multiple sequential builds.
Ongoing cost is the one most teams underestimate. It includes model API costs, infrastructure (vector databases, monitoring, eval), and the engineering time to operate and evolve the feature. Operating cost is usually 30 to 60 percent of build cost on an annualised basis once a feature is in production. Plan for it.
Build versus buy economics
Buying an off-the-shelf AI tool that solves your problem is almost always cheaper than building, when an off-the-shelf tool exists that genuinely solves your problem. The mistake is assuming a tool solves the problem when it solves a similar but different problem.
We tell clients to bias toward buy. The cases where building wins are: when the problem is core to your competitive position, when off-the-shelf tools genuinely do not exist, or when the cost of integration with existing systems makes a generic tool more expensive than a custom build. Those cases are rarer than people assume.
A useful diagnostic: write down what an off-the-shelf tool would do, and what you would need to add or change. If the additions are minimal, buy. If the additions are substantial, you are effectively building anyway and you might as well build cleanly rather than fight a tool that does not fit.
Common cost traps
The 'we will figure out evaluation later' trap. Teams that defer evaluation save build cost and pay for it in operating cost, where the lack of evaluation makes every change risky and every regression invisible.
The 'we just need a pilot' trap. Pilots that are not built to production standards rarely transition to production. Either build to production from week 1 or build a throwaway prototype with the explicit understanding it is throwaway. Building a 'pilot' that is neither produces a feature you cannot ship and cannot scrap.
The 'we will use the cheapest model' trap. Using a weaker model often saves API costs and increases other costs (more retrieval, more prompting, more human review) by more than the savings. Optimise the system, not any one component.
The 'fixed price for an unclear scope' trap. Fixed-price engagements work when the scope is genuinely fixed. They fail when scope is loose and the partner is incentivised to minimise work to protect margin. We use fixed-price for discovery (where scope is small and clear) and milestone-based pricing for builds (where scope evolves).
How to scope a sensible first project
The right size for a first AI project is whatever fits in eight weeks of execution time, including the platform components you will need for subsequent projects. Smaller is risky because it might not justify the platform overhead; larger is risky because the scope drifts before the build lands.
A useful test: can you describe the feature, the data it uses, and what good looks like, in under five minutes. If yes, the scope is probably right. If you find yourself adding qualifiers and exceptions, the scope is too broad and needs to be narrowed before any partner builds anything.
The most successful first projects we ship have one named owner, one well-defined workflow, one source of data, and one measurable outcome. The simplicity is the feature, not a limitation.
What to ask any AI partner about cost
What is the build cost, and what is included. Surface the assumptions about scope, data, integration, and governance. Disagreements about what is in scope are how cost overruns happen.
What is the expected operating cost, broken down by API, infrastructure, and engineering time. Push past 'it depends' answers; partners who have shipped production AI know roughly what each component costs.
How are change orders priced. Scope will change; the question is whether change is priced fairly or weaponised.
What is the exit cost. If we want to take the build in-house in 12 months, what does that look like and what does it cost. Partners who duck this question are the ones who plan to make exit expensive.
What does year two look like, by component. Most projects have meaningful year-two costs that the original proposal did not mention. The right partner will tell you what those are without being asked.