Building an AI feature into an existing product typically costs $3,000–8,000 and takes three to six weeks; a full AI-first product runs $8,000–25,000 over eight to sixteen weeks. The number most quotes omit is the running cost, which scales with usage and commonly lands between $5 and $60 per active user per month before optimisation — and between $2 and $18 after trimming context, caching prompts and routing simple requests to smaller models.
Two numbers decide whether an AI feature is a good idea, and most proposals only contain one of them.
The build cost is what everyone asks about and the smaller figure over three years. The running cost is what turns a well-received feature into a margin conversation eighteen months later. Both are estimable before you start.
Build cost, by shape of project
| Project | Cost | Elapsed |
|---|---|---|
| Feasibility / discovery | $600 – $1,800 | 3–5 days |
| One feature into an existing product | $3,000 – $8,000 | 3–6 weeks |
| RAG system over one corpus | $4,000 – $10,000 | 4–8 weeks |
| Constrained agent with tool access | $8,000 – $20,000 | 6–12 weeks |
| Full AI-first product or MVP | $8,000 – $25,000 | 8–16 weeks |
What actually moves a project within its band, roughly in order of impact:
- The state of your data. Clean, accessible, well-permissioned data is the single biggest determinant. Data spread across four systems with no consistent identifier can double a project before any model work starts.
- Whether it acts or only answers. Anything taking actions in your systems needs permission design, audit logging and confirmation flows. Roughly doubles the surface.
- Permission complexity. "Everyone sees everything" and "each user sees only their own records" are weeks apart in a retrieval system.
- Where the model runs. A hosted API is the cheap path. Self-hosting an open-weight model because data can't leave adds infrastructure work and ongoing operations.
- How wrong it's allowed to be. A drafting assistant with a human in the loop is forgiving. Anything customer-facing and unsupervised needs a materially deeper eval suite and more guardrail work.
Running cost, and how to work out yours
The arithmetic is genuinely simple. What makes it feel unpredictable is that people estimate token counts badly — in our experience most teams underestimate their input tokens by three to five times, because they forget the retrieved context, the system prompt and the conversation history all count.
monthly cost =
active users
× requests per user per month
× ( input tokens × input price
+ output tokens × output price )
Worked example — a grounded Q&A feature:
500 users × 40 requests
× ( 6,000 input tokens × $3 /1M
+ 700 output tokens × $15 /1M )
= 500 × 40 × ( $0.018 + $0.0105 )
= $570 per monthThat's $1.14 per user per month, which is comfortable. Now hold everything constant and multiply the users by a hundred.
| Active users | Naive | Optimised |
|---|---|---|
| 500 | $570 / mo | $180 / mo |
| 5,000 | $5,700 / mo | $1,800 / mo |
| 50,000 | $57,000 / mo | $18,000 / mo |
At the top row the difference is a rounding error. At the bottom it's a headcount. This is why the cost model belongs in the scoping conversation and not in a review after launch.
The three levers that actually matter
In order of effect, and none of them involve a worse product.
1. Trim the context you send
The largest and most consistently ignored lever. Most retrieval systems pass ten passages when three would answer the question, because passing more feels safer. It isn't — beyond a point, extra context measurably degrades answer quality as well as costing money.
Re-ranking down to the three or four genuinely relevant passages typically cuts input tokens by half or more, and usually improves accuracy at the same time. It's the rare optimisation with no trade-off.
2. Cache the stable part of the prompt
Every major provider now offers prompt caching, and it's substantially discounted on cached input tokens. If your system prompt, tool definitions and few-shot examples are constant across calls — and they almost always are — that's a large fraction of your input tokens at a fraction of the price.
It requires structuring prompts so the stable prefix comes first and the variable part last. Doing that from the start is free; retrofitting it is a day.
3. Route by difficulty
The price gap between a small model and a frontier one is commonly ten to thirty times. Most production workloads are a long tail of easy requests with a minority of hard ones.
Classify cheaply, handle the easy majority with a small model, escalate the rest. The eval suite is what makes this safe — you can measure whether the small model is good enough per case type rather than guessing. Without evals, routing is a gamble; with them, it's the largest cost win available after context trimming.
Three years, not three months
Put the numbers on the same timeline before deciding anything.
| Year 1 | Years 2–3 | Total | |
|---|---|---|---|
| Build | $6,000 | — | $6,000 |
| Model usage | $21,600 | $43,200 | $64,800 |
| Retainer | $30,000 | $60,000 | $90,000 |
| Total | $57,600 | $103,200 | $160,800 |
The build is under 4% of the three-year cost. Which is worth sitting with, because it reframes the decision: choosing a studio on build price is optimising the smallest line on the sheet, while the two large ones — running cost and ongoing ownership — are precisely what a good build makes cheaper.
What we'd tell you on a call
If your feature serves under a thousand users, don't spend a week optimising tokens. Ship it, measure real usage, optimise when the number is large enough to care about. Premature cost engineering on an AI feature is as wasteful as premature optimisation anywhere else.
If you're heading past ten thousand active users, model it before you build, because the architecture that's cheap at scale — write-time enrichment, aggressive caching, model routing — is not the same architecture as the obvious one, and retrofitting it is more expensive than choosing it.
Our full published ranges for every service are on the pricing page, and how we scope an AI project covers what discovery produces.