What AI Adoption Actually Costs a Gulf SME

The model is almost never the expensive part. Here is the arithmetic on published API rates, the pricing models you will be quoted, and the one number that decides whether the project pays for itself.

The thing most cost estimates get wrong Almost every published estimate of "what AI costs" prices the model. For a small or mid-sized business that is the smallest line in the budget and the least interesting one. The cost lives in three other places: getting the system connected to what you already run, working out whether it is actually right, and keeping it running once it is. This matters because it changes what you should negotiate. A quote that is mostly model cost is quoting the wrong project. What the model actually costs — with the arithmetic Frontier model pricing is public, so this part can be calculated rather than guessed. Anthropic's published API rates at the time of writing, per million tokens (input / output): Haiku 4.5 — $1 / $5 Sonnet 5 — $3 / $15 (introductory $2 / $10 until 31 August 2026) Opus 5 — $5 / $25 Take a concrete workload: 1,000 customer messages a month , each needing roughly 2,000 input tokens (the message plus retrieved context) and producing 500 output tokens of drafted reply. Input: 1,000 × 2,000 = 2M tokens Output: 1,000 × 500 = 0.5M tokens On Sonnet 5: (2 × $3) + (0.5 × $15) = $13.50 per month On Haiku 4.5: (2 × $1) + (0.5 × $5) = $4.50 per month Prompt caching bills cache hits at a fraction of standard input, and the Batch API discounts work that does not need an immediate answer — both push these numbers lower for anything running on a schedule. The point is not the exact figure, which will have changed by the time you read this. It is the order of magnitude : for a business of this size the model is tens of dollars a month, not thousands. Anyone presenting model cost as the reason a project is expensive has either mis-scoped it or is describing a very different workload. Where the money actually goes Integration — usually the largest line. A model with no access to your CRM, inbox, store or documents is a chatbot. Connecting it properly, with the right permissions and without breaking what already works, is the bulk of the engineering. Evaluation. Building a set of real examples with known-good answers, so you can tell whether the thing works. Skipped constantly; the direct cause of most stalled pilots. The build itself. Genuinely faster than it was three years ago. AI-assisted development has compressed the mechanical half of this line substantially — which is exactly why more of the budget should go to the two above. Running cost. Model usage, hosting, monitoring, and the person who owns it. Small monthly numbers that decide, over a year, whether the project paid for itself. Change. The process it touches will change, and the automation will need to follow. Budget for it or it degrades quietly. The pricing models you will be quoted Three shapes come up, and which one you are offered tells you something about how well the work has been scoped. Fixed price. Works when the scope is genuinely narrow and well understood — one process, one integration, a defined output. The risk sits with the vendor, so expect a margin for it. A fixed price on a vague brief is a warning sign for both sides. Time and materials. Honest for discovery and for work whose shape will change. The risk sits with you, so it needs a cap and a checkpoint, not an open meter. Retainer. Appropriate after something is live and needs maintenance and iteration. Being offered a retainer before anything exists is usually a scoping failure dressed as a relationship. A reasonable structure for a first project is a small paid discovery, priced separately, that produces a written recommendation you own — followed by a fixed price on the narrowed scope. If the discovery concludes you should not build, you have paid a small amount to avoid a large one. What drives an estimate up Number of systems touched. One integration is a project; four is a different project. This is the single biggest multiplier. Data that is not ready. Records in spreadsheets, inconsistent formats, no unique identifiers. Cleaning is real work and it is almost always underestimated. Bilingual from day one. Arabic and English is not a translation pass — it affects the evaluation set, the prompts, the interface and the fallbacks. Built in from the first version it is a modest addition; retrofitted it is close to a rebuild. How wrong it is allowed to be. Drafting for a human to send is cheap. Acting autonomously on money or on customer commitments demands far more evaluation, logging and guardrail work. Channel spread. Customer conversation here arrives on WhatsApp as well as email and web, which means more surfaces to connect than an equivalent business elsewhere. Compliance and data residency. Where data may live, and who may see it, can rule out the simplest architecture entirely. What brings it down A narrow first scope. Two specific things built well cost far less and prove far more than a broad platform. Existing structure. A business whose processes are documented and whose data is already in a real system starts much further along. An owner. A named person who will run it prevents the slow decay that turns a working system into a rebuild eighteen months later. Choosing the smaller model. High-volume, low-value classification rarely needs the most capable model available — see the arithmetic above. The number that actually decides it Not the build cost. The comparison between what the current process costs you per month and what the automated version costs to run per month . You can calculate the first side yourself, and you should, before speaking to anyone: how many people touch the process, how long it takes them, how often it runs, and what an error costs when it happens. Multiply by your own loaded hourly cost. That figure makes every subsequent decision easy — including the decision not to build, which is correct more often than vendors suggest. An automation that costs more to run than the process it replaced is not a saving, however impressive the demo was. This is a real outcome and it is worth checking before signing, not after. Questions worth asking any vendor What will this cost to run per month, at our volume, in year two? Which model, and why that one rather than a cheaper tier? How will we know it is working — what does the evaluation look like? What is it allowed to do without a person, and how does that change? Who owns it after handover, and what documentation do they get? What would make you tell us not to build this? The last one is the most useful. An answer of "nothing" tells you what kind of engagement you are buying. How this was written The model arithmetic uses Anthropic's published API rates and is shown in full so you can substitute your own volumes; rates change, so check them rather than trusting a figure in an article. The pricing models and cost drivers are general commercial practice, not a description of any particular engagement. No engagement prices appear here. Quoting typical project costs would mean publishing figures that were not drawn from real work, and a wrong range is worse than none — you would anchor on it. If you want a number for your own situation, the honest way to get one is to describe the process and its current cost. Related How engagements are scoped is on AI in Kuwait ; what is worth automating, and what is not, on AI Automation ; and model choice on Claude .