What AI costs after launch: budgeting the year, not the build

Almost every AI proposal you will read is priced like a website: a build number, a timeline, and a maintenance line that looks reassuringly small. That shape is wrong, and it is why so many AI systems are quietly switched off in their second year. The build is the part you can predict. The year that follows is the part that decides whether the thing survives.
The short answer
For most AI systems we see in Kuwait, the build is a one-off number and the operating cost is a curve that rises with use. If you budget only the first number, you are budgeting the cheap half. The useful question at proposal stage is not “what does it cost to build” but “what does it cost in month twelve, at the volume we actually hope to reach” — because success is what makes the bill grow.
That is the uncomfortable part. A failed AI project is cheap to run. A successful one is not.
The four lines that appear after go-live
Once a system is live, the recurring cost separates into four lines that behave very differently. Budget them separately or you will be surprised by at least one.
Model usage. Charged by volume of text processed, in and out. It scales with how much you ask and how much context you attach to each request. Current rates are published openly — OpenAI’s pricing page and Claude’s are the two most of our work touches — and they change often enough that any figure printed in an article is stale within months. Read them on the day you budget, not from a proposal written last quarter.
Platform and channel fees. Separate from the model, and frequently larger. If the system talks to customers on WhatsApp, Meta charges its own platform fees on top of everything else, and those are set by market. We broke that particular bill down in detail in what a WhatsApp AI assistant actually costs in Kuwait.
Human review. Any system that touches money or commitments needs someone checking a sample of its output, at least early on. This is a real salaried cost and it is almost never in the proposal. It should shrink over time. It should not reach zero on anything financial.
Change maintenance. Your prices change, your products change, a supplier changes their invoice layout, a policy is rewritten. Each of those is a small piece of work. Together they are the line that decides whether the system still tells the truth in month nine.
Why usage cost is hard to forecast — and what inflates it
Teams underestimate operating cost for a specific, mechanical reason: they price the request they imagined, not the request the system ends up making. Three things reliably inflate the real number.
Context you attach to every call. If each question carries a policy document, a product list and six previous messages, you are paying for all of it every time. This is the single biggest driver we see, and it is usually invisible in a demo where the test question was short.
Retries and re-reads. Documents that fail validation get processed again. Requests that time out get repeated. A system with a 15% retry rate costs 15% more than its own arithmetic suggests, and nobody models that in advance.
Scans and images. Visual processing costs more than text, and a photographed invoice at full resolution costs considerably more than the same invoice downscaled to a resolution that is still perfectly readable. The engineering that makes Arabic documents readable, which we covered in reading Arabic invoices with AI, happens to be the same engineering that keeps this line under control.
A twelve-month budget, laid out
Here is the shape we use when scoping. The figures are deliberately left as shapes rather than numbers, because your volumes and the published rates will both differ — but the proportions are what matter, and they surprise people.
| Line | When it hits | Behaviour over 12 months | Usual share of year one |
|---|---|---|---|
| Build | Months 1–2 | One-off, fixed if scoped properly | The largest single line, and the only predictable one |
| Model usage | From go-live | Rises with adoption; can double if context is not controlled | Small at first, and the line most likely to be underestimated |
| Platform / channel fees | From go-live | Rises with conversation or transaction count | Often larger than model usage for customer-facing systems |
| Human review | From go-live | Highest in months 1–3, then falls to a floor | Consistently absent from proposals |
| Change maintenance | From month 3 | Lumpy — quiet, then a burst when something upstream changes | The line that decides year two |
Notice what this table implies. In month one the build dominates and everything looks fine. By month twelve, if the system is being used properly, the recurring lines together are the real story — and that is the number that should have been in the proposal.
Designing for a cost ceiling
The part almost nobody writes about: operating cost is an engineering decision, not just a vendor rate. You can design a system to have a ceiling, and you should, before it is in production.
- Send less. Retrieve the three relevant paragraphs instead of attaching the whole manual. This improves answers and cuts cost at the same time — the two goals are not in tension here.
- Use the cheapest model that passes. Route simple classification to a small model and reserve the expensive one for the hard cases. Most workflows are mostly easy cases.
- Cache what repeats. If forty people ask the same policy question this month, the system should not pay to reason it out forty times.
- Cap and alarm. Set a hard monthly spend limit and an alert at a threshold below it. A runaway loop should cost you an email, not an invoice.
- Downscale images before sending. Quietly one of the highest-return changes in any document pipeline.
None of these is exotic. All of them are cheaper to build in at the start than to retrofit under pressure when a bill arrives.
Buy, subscribe or build — three different cost shapes
The same requirement can be met three ways, and they fail differently rather than one being simply cheaper.
Per-seat subscription is predictable and rises with headcount, not usage. Good when a whole team needs a general tool; poor value when only three people use it heavily.
Per-usage build starts lower and rises with success. Right when the workload is specific and volume is measurable, which is most of the automation work we do — the judgement of when that threshold is crossed is set out in which process to automate first.
Self-hosted converts a variable bill into a fixed one plus operational responsibility. Occasionally right at high, steady volume or where data constraints demand it — a question we worked through in where your company data actually goes. It is rarely the cheap option it looks like once someone has to patch, monitor and back it up.
How we scope it
Every project we scope ends with a twelve-month operating estimate alongside the working system — including the cases where that estimate is the reason not to proceed. We would rather hand over arithmetic that stops a project than a system that gets switched off in month seven, because the second outcome costs you the build fee as well.
We apply the same discipline to our own products, where every one of these lines comes out of our own account. That is where this list came from — not from a spreadsheet template.
If you have a proposal in front of you and want a second opinion on what it will actually cost to run, send it to us on WhatsApp. We will tell you which line is missing.
Frequently asked questions
Why can’t you just tell me what AI costs per month?
Because the dominant variable is your volume, not our rate. A document workflow processing 200 invoices a month and one processing 20,000 use the same system and produce bills an order of magnitude apart. What we can do at scoping is give you the cost per unit of work and let you multiply by a number only you know.
Do model prices go down over time?
Published rates for a given model have generally fallen, and newer small models often outperform older large ones at lower cost. That is a real tailwind. It does not help you if your system’s usage grows faster than rates fall, which is the normal case for a system people actually like.
What is the most commonly missed cost?
Human review, followed by change maintenance. Both are people costs rather than invoices from a vendor, which is precisely why they slip out of a proposal built around software line items.
Is a fixed monthly retainer safer than usage billing?
It moves the risk to your supplier, and they will price that risk in. It is worth paying for when your volumes are unpredictable and a surprise would be genuinely damaging. It is poor value when your volume is steady and known — you are buying insurance against something that is not going to happen.
How do we stop costs running away quietly?
A hard monthly spend cap at the provider, an alert set below it, and a weekly glance at cost per processed item rather than total spend. The per-item figure exposes a problem while it is still small; the total only tells you after the month has closed.

Leave a Reply