How Much Does AI Product Development Cost in 2026

Budget meetings about AI spend most of their time on the line that matters least. Run the arithmetic on a mid-sized internal assistant and the model bill lands near $900 a month, which is what one senior engineer costs every two days.

Nobody argues about the engineer. Everybody argues about the tokens.

That inversion is the most useful thing to know before approving an AI budget, and it is almost never what the estimate in front of you is built around. Most quotes are organized as one engineering number with a note about API costs appended at the bottom. The engineering number is real. The note is not the problem either. The problem is the six other lines sitting between them, unnamed, which together cost more than the model ever will.

This is a costing guide, not a survey. Below is what an AI product costs to build in 2026, what it costs to run, and which specific lines your estimate is probably missing. Every range is either sourced or labelled as an estimate range, and every one comes with the mechanism that moves it. If you are the person who has to defend the number in a board meeting, the mechanism matters more than the range.

What an AI product costs in 2026, at a glance

Three ambition tiers cover most of what companies actually commission. The figures below are build cost in USD, held separate from monthly operating cost, because those are two different budgets and mixing them is the first way an estimate goes wrong.

These are estimate ranges, synthesized from published 2026 vendor pricing guides and consistent with the bands those guides report, which run from roughly $10,000 for a thin API wrapper to $500,000 and above for enterprise platforms. Treat them as the starting bracket, not the answer. The rest of this guide is about which end of each range you land on and why.

Look at the run column. It is not a rounding error. A production system at the middle of its band spends about $100,000 a year to operate. That is comparable to the entire build cost of a pilot. Whether it appears in your business case is a choice someone made, and it is usually made by omission.

Build cost and run cost are two different budgets

The second way an estimate goes wrong is inherited from conventional software budgeting, which teaches an instinct that misleads here. In traditional SaaS delivery the build dominates, maintenance settles into a predictable slice of it, and the ongoing cost curve flattens. AI products do not behave that way. Their operating cost scales with usage rather than with scope, and usage is the variable that grows when the product succeeds.

The practical consequence is that a successful AI product gets more expensive, and it does so on a schedule nobody planned. A pilot serving forty people costs almost nothing to run. The same system opened to four hundred people costs ten times as much in inference alone, before anyone adds a feature. Traditional software rarely punishes adoption this way. It is a strange thing to have to say out loud to a finance team.

There is a second asymmetry. Build cost is bounded and estimable, because scope is a thing you can write down. Run cost is open-ended, because it depends on how people use the product, how often models change underneath it, and how much human review the outputs require. Estimating the first well is a project management skill. Estimating the second well requires having operated something similar before.

Teams who have shipped these systems keep making the argument that agentic AI costs more to run than to build . That is what the second-year invoice looks like when the first year was budgeted as if it were a website.

So the discipline this guide argues for is simple: build a two-column budget from the start. Every line item below gets a build figure and a run figure, and neither column is allowed to be empty.

Why the model API bill is the smallest line

Here is the arithmetic behind the opening claim, with every assumption stated so you can substitute your own.

Take an internal assistant serving 200 employees. Assume each person makes 15 requests on a working day. That is heavy usage for an internal tool, so the resulting bill is a ceiling rather than an average. That is 3,000 requests a day, roughly 66,000 a month. Assume each request carries 4,000 input tokens (a retrieved context window of a few documents plus the conversation so far) and produces 600 output tokens. That works out to about 264 million input tokens and 40 million output tokens a month.

At a blended mid-2026 rate for a mid-tier frontier model, call it $2 per million input tokens and $10 per million output tokens, that is roughly $528 in input and $400 in output. Call the monthly model bill $930.

Now set that against one senior engineer. At a fully loaded cost in the range of $14,000 to $22,000 a month in the US market, or roughly $5,000 to $9,000 through an offshore partner (Full Scale, 2026), the model bill is between four and seven percent of a single engineer-month. Two days of one person's time.

Three things make that number grow. Work out which of them applies to you:

• Retrieval depth. Every additional document pulled into context is input tokens on every request. Going from three retrieved chunks to twelve roughly triples the input side of the bill.
• Agentic loops. A single-turn assistant makes one model call per request. An agent that plans, calls tools, checks its own work, and retries makes five to fifteen. The bill scales with the loop count, not the user count.
• Output length and reasoning modes. Output tokens are typically priced several times higher than input tokens, and extended reasoning modes can multiply effective output volume substantially.

Even with all three working against you, the model line rarely becomes the largest item in a well-run product. An agentic system with deep retrieval at the same user volume might reach $8,000 to $12,000 a month. That is real money, and it is still less than the fully loaded cost of the one engineer who maintains it.

The broader economics support the shape of this. Analyses of AI compute costs have consistently found that per-unit inference prices have fallen sharply while total organizational AI spend has risen, because usage grew faster than unit prices fell (IBM, 2026). The bill goes up. The reason is volume and everything wrapped around the model, not the model's price tag.

The seven line items, with ranges and drivers

This is the core of the budget, and the part your current estimate most likely compresses into one number. Seven lines, each with a build figure, a run figure, and the mechanism that decides where in the range you land.

All figures are estimate ranges for a production-tier system. The shares overlap because they are typical bands, not a partition that sums to exactly 100%.

Engineering

The largest build line, and the only one most estimates get roughly right. Expect $50,000 to $300,000 for a production system, covering discovery, architecture, application code, data pipelines, integration work, and deployment.

What puts you at the low end: one clean data source, one integration, a workflow that already has a written specification, and a team that has built something similar. What puts you at the high end: multiple legacy systems with undocumented APIs, data that has to be cleaned and labelled before it is usable, and a scope that gets defined while the build is already running. Data preparation is the line vendor proposals leave out most often, and on data-heavy projects it consumes more effort than the model work does.

Model and inference

Covered in detail above. Budget $500 to $2,500 a month for a pilot, $3,000 to $12,000 for a production system with moderate agentic behaviour. Build cost here is effectively nil beyond a few hundred dollars of experimentation.

What puts you at the low end: single-turn interactions, tight retrieval, a small model for routine classification and a frontier model only where it is needed. What puts you at the high end: long agent loops, large context windows on every request, and one expensive model handling every task regardless of difficulty.

Infrastructure

Compute, storage, vector search, networking, and the non-production environments nobody counts. Expect $8,000 to $40,000 to build out and $800 to $9,000 a month to run at production scale.

What puts you at the low end: managed services, a single region, and an uptime target you can meet without redundancy. What puts you at the high end: a self-hosted model requiring dedicated GPUs, multi-region deployment for data residency, or a 99.9% availability commitment that forces hot standby. Self-hosting is where this line doubles, and it is usually chosen for data-control reasons rather than cost reasons, despite being sold as a saving.

Observability

The line almost no competitor guide budgets. Tracing, structured logging, cost attribution per feature or per customer, latency monitoring, and output-quality monitoring. Expect $6,000 to $25,000 to build and $400 to $3,500 a month in tooling.

What puts you at the low end: low request volume, short log retention, and a willingness to use your existing application monitoring stack with AI-specific traces bolted on. What puts you at the high end: high volume, long retention for audit purposes, and per-customer cost attribution, which is hard to retrofit and becomes mandatory the moment you want to price the product.

Skipping this line does not save the money. It defers it into incident response time, and into the weeks you will spend unable to answer why quality dropped.

Evaluation

The other line competitors leave out, and the one most likely to be under-budgeted by a factor of three. This covers building an eval harness, curating a test dataset, running regressions before each release, and the human review time that grades outputs the automated evals cannot.

Expect $12,000 to $60,000 to build and $1,500 to $8,000 a month to operate. Teams who have shipped these systems put evaluation at 15% to 25% of build cost, which is consistent with the range above.

What puts you at the low end: a narrow task with objectively checkable outputs, and a slow release cadence. What puts you at the high end: subjective or open-ended outputs requiring human graders, a weekly release cadence, and regulatory pressure to demonstrate that quality is monitored.

Security and compliance

Threat modelling, prompt-injection and jailbreak testing, access control design, data-handling review, audit logging, and any certification work procurement demands. Expect $10,000 to $80,000 to build and $500 to $4,000 a month ongoing.

What puts you at the low end: internal-only deployment, no regulated data, no external customers asking for a security questionnaire. What puts you at the high end: healthcare or financial data, an enterprise customer whose procurement process requires a completed audit, or a system that takes consequential actions rather than only producing text. The gap between those two situations is the largest proportional spread of any line in this table.

Maintenance

Model deprecation and migration, prompt and retrieval drift, dependency upgrades, and the steady stream of small corrections that keep quality from decaying. Budget 15% to 25% of build cost annually, rising toward 25% to 35% with regulated data or several model dependencies (Riseup Labs, 2026), which lands between $3,000 and $15,000 a month for a production system.

What puts you at the low end: one model dependency, a stable upstream provider, and a system whose inputs do not change much. What puts you at the high end: several model dependencies across providers, each with its own deprecation schedule, plus source documents that change frequently enough to require retrieval tuning. Model deprecation is the specifically AI-shaped part of this line. Providers retire model versions on their own timeline, and each retirement forces a re-validation cycle you did not schedule.

Pilot, production, platform: what each tier buys

Tiers are the framing every competing cost guide leads with. It is useful for exactly one thing, which is being explicit about what a given budget does not include. That is where budgets break.

Pilot ($25,000 - $70,000 build, 6 - 10 weeks). One workflow, one user group, manual fallbacks everywhere. Includes: working software, real data, enough evaluation to know whether the thing helps. Deliberately excludes: production SLA, comprehensive eval coverage, security review, per-customer cost attribution, and any promise about maintenance. A pilot is an experiment that produces a decision, and pricing it like a product is how it becomes a product nobody will fund properly.

Production ($80,000 - $250,000 build, 3 - 6 months). Business-critical or customer-facing. Includes everything in the seven-line table at real levels. This is the first tier where evaluation, observability, and security stop being optional, and where the run column becomes a permanent operating expense rather than a project cost.

Platform ($250,000 - $600,000+ build, 6 - 12 months). Shared infrastructure serving multiple use cases, with governance, access control, and cost attribution across teams. Only worth it once you have three or more use cases in production. Below that, the shared layer costs more than the use cases it serves.

The most expensive mistake in this section is scoping a pilot with no production path. A pilot built on prototype-grade code, with no eval harness and no observability, does not become a production system. It gets rebuilt. Companies routinely pay the build cost twice this way, and the second build is more expensive than the first would have been, because it now has to carry the organizational expectation the pilot created.

A worked year-one budget

Ranges are only useful once someone builds a total out of them. Here is one, so you can watch the arithmetic rather than take it on trust.

The product: an internal document-processing assistant for a mid-market company. It ingests contracts and policy documents, answers questions with citations, and drafts summaries. 200 users. Roughly 66,000 requests a month. Two source systems, one of them a legacy document store. No regulated data, but the company's largest customer requires a completed security questionnaire.

Year one, assuming the product goes live at month four and runs for nine months: $216,500 in build plus roughly $174,000 in run, for about $390,000.

Year two, with no new features at all: roughly $232,000. The run column is now the entire budget, and it is larger than most people's mental model of what this product costs.

Assumptions worth challenging, because they are where your number will differ from this one:

• Engineering is priced at a blended $85 per hour, roughly 1,600 hours. A US-only senior team would push this line past $250,000. An offshore team at $40 per hour would bring it under $70,000, with a corresponding change in coordination overhead.
• The model line assumes single-turn retrieval, not agentic loops. Making this system agentic would move that line from $1,200 to somewhere between $6,000 and $10,000 a month.
• Evaluation is budgeted at about 13% of build, which is at the low end of the recommended band. It is low because the outputs are checkable against source documents. A system producing open-ended advice would need close to double.
• Security is budgeted for one questionnaire, not a certification. A SOC 2 process would add $40,000 to $80,000 and several months.

The biggest lever in this table sits outside it: whether the specification was settled before engineering started. That gets its own section further down.

If you want a second opinion on which of these lines applies to your situation before you commit a budget, book a free 30-min readiness call . It is a 30-minute AI Readiness Snapshot, and the useful outcome is usually finding out which two lines you have underestimated.

What actually drives the number up or down

Every line above has its own driver. Six more cut across several lines at once, which is why the same feature list can produce quotes that differ by a factor of five.

Whether the specification exists before the build starts. The single largest cross-cutting driver. A settled specification means engineering estimates hold, evaluation criteria are known in advance rather than invented after launch, and scope disputes get resolved on paper. An unsettled specification means rework, and rework is billed at the same rate as work.

Data readiness. Clean, accessible, well-structured source data is the difference between a two-week ingestion pipeline and a three-month data project. This drives engineering, infrastructure, and evaluation simultaneously, because bad data also makes quality harder to measure.

Integration surface. Each system the product touches adds engineering, testing, monitoring, and a permanent maintenance obligation. Two integrations is a normal project. Seven is a different project wearing the same name, and it usually arrives labelled as a nice-to-have.

Latency and uptime targets. A 2-second response target and a 99.9% availability commitment together can double the infrastructure line and add meaningfully to engineering. Ask whether the business needs them. In my experience they get specified by habit, copied off whatever the last vendor contract said.

Human review volume. Any output requiring human sign-off creates an ongoing labour cost that belongs in the run column. A system reviewing 500 documents a month with a human checking each one is buying a part-time role, permanently.

Regulatory exposure. Regulated data changes the security line, the infrastructure line (residency, encryption, isolation), and the evaluation line (demonstrable quality monitoring). It is the driver most likely to be discovered late, because it typically arrives through a customer's procurement process rather than through your own planning.

Of those six, you control the first three. The last three are usually constraints handed to you. Knowing which is which tells you where negotiation is possible.

Where AI budgets actually break

Knowing the drivers is not the same as knowing where the money actually leaks. These are the specific mechanisms, each with the cost it creates.

Nobody owns the run budget. The build has a project sponsor and a defined end. The run cost has neither, so it lands in a cloud bill that gets reviewed quarterly by someone who did not approve the project. The cost is discovered as a variance rather than planned as a line, which turns a normal operating expense into a credibility problem.

Evaluation is built after launch. Teams ship, then discover they cannot tell whether a change made things better. Retrofitting an eval harness onto a live system costs roughly twice what building it alongside would have, and the interval before it exists is spent shipping changes blind.

The pilot has no production path. Covered above, and worth repeating because it is the most expensive single mistake in this list. Prototype-grade code, no evals, no observability, then a decision to productionize. The build gets paid for twice.

Model deprecation arrives unbudgeted. A provider retires the model version the product was tuned against. The migration requires re-validation across the whole eval suite, prompt adjustments, and a regression cycle. Two to six engineer-weeks, unplanned, and it happens on the provider's schedule rather than yours.

Observability is added after the first incident. Quality degrades, nobody can say why, and the investigation consumes more engineering time than the tooling would have cost. The exchange rate on this one is terrible. The incident also spends trust, which is harder to rebuild than a budget line.

Scope grows through the interface. Each new integration or user group looks small in isolation. In aggregate they move a production system toward platform-tier operating cost without anyone approving a platform-tier budget.

How spec-driven delivery takes about 40% out of the build

One lever moves more of the total than any other, and it has nothing to do with cheaper models or cheaper teams. Settle the specification before implementation begins .

The mechanism is dull, which is probably why it gets skipped. When behaviour, edge cases, data contracts, and acceptance criteria are written down and agreed before code exists, three expensive things stop happening. Rework collapses, because the build does not discover requirements halfway through. Estimates hold, because there is a fixed target to estimate against. Evaluation criteria exist on day one, because acceptance criteria and eval criteria are largely the same document.

In our delivery work, this approach has cut build cost by roughly 40% against comparable projects run conventionally. That figure is our own measured experience across our engagements, not an industry benchmark, and the honest caveat is that it depends on the specification being genuinely settled rather than nominally documented. A specification that changes weekly is a status report wearing a specification's name.

The compounding effect matters more than the headline number. Rework wastes engineering hours, then it wastes the evaluation work built against the old behaviour, then it wastes the review cycles that signed off on both. This is the mechanism by which technical debt accrues faster on AI projects than on conventional ones, and the reason a disciplined specification pays back into several budget lines at once rather than only into engineering.

In practice that means resisting the pressure to start building during discovery. The two weeks spent settling the specification are the cheapest two weeks in the project, and they are the ones most often cut.

How to pressure-test a vendor quote

All of which reduces to a test you can run on the quote already sitting in your inbox. You do not need to be technical to evaluate it. You need to check whether it is structured like a real budget.

Questions worth asking the vendor:

• What does this cost to run in month twelve at three times the launch volume?
• Which line would you cut first if the budget dropped by 20%, and what breaks?
• What have you assumed about our data quality, and what happens to the estimate if you are wrong?
• Which model does this assume, and what is the plan when that version is deprecated?
• How will we know, three months after launch, whether quality has degraded?

Questions worth asking internally:

• Who owns the operating budget after launch, by name?
• What decision does this product change, and what is that decision worth?
• Do we need the latency and uptime targets we have specified, or did we inherit them?

The last row of the table is the one I would check first. A fixed price quoted against an unspecified scope is not a discipline, it is a bet, and the vendor has priced their side of it. A cheap quote usually omits the hard parts, and the hard parts are the seven lines above.

What to do with this

Two columns, seven lines. That is the whole method. An AI product has two budgets rather than one, the run budget usually outlives and eventually outgrows the build, and the model API bill is reliably among the smallest of the seven.

So the next action is concrete: take the estimate currently on your desk and rebuild it as seven lines with two columns each. Any cell you cannot fill in is a line nobody has thought about yet, and the empty cells are a more honest picture of your risk than the total at the bottom.

If you want help doing that against your specific situation, book a free 30-min readiness call . The AI Readiness Snapshot takes 30 minutes and produces a marked-up version of your own estimate, with the lines that are missing and the ones that are wrong by more than a factor of two.