Four things people mean by an AI solution
The phrase covers four purchases that behave nothing alike, and the difference decides the cost, the timeline and what happens when you want to change something.
- Buying a product. Somebody else’s software with AI inside it. Fastest to start, cheapest to try, and the one you cannot shape. If it does eighty per cent of what you need, the remaining twenty per cent is usually unreachable at any price.
- Configuring a platform. A vendor’s builder where you assemble a workflow. Quick, and it looks like development from the outside. The trap is that the logic lives inside the vendor’s account, so leaving means rebuilding rather than exporting.
- Assembling services. A model API, a database you already have, and a thin layer of your own code joining them. This is what most real projects turn out to be, and it is the shape I recommend most often.
- Building something custom. Your own application, your own data model, your own interface. Justified when the process is your actual advantage, not when the process is ordinary and you simply want it to be yours.
Nobody should choose between these on the first call. The choice falls out of two questions: how unusual is the work you are automating, and what does it cost you to change your mind in a year.
Most of an AI build is not the model
The model is a paid API you did not write and cannot improve. Almost all of the engineering sits around it, and it is ordinary engineering: getting at data that lives in four systems, forcing the model to answer in a shape your code can rely on rather than in prose, giving it permission to perform actions and bounding which ones, retrieving the right documents before it answers, and recording every request so that a wrong answer next month can be explained rather than argued about.
Two capabilities carry most of that weight. Structured outputs make the response conform to a schema you define, which is what turns a demonstration into something a system can consume. Tool use lets the model call your functions, which is what separates an assistant that answers from one that does. Both are configuration, not research. That is the good news: a competent team can build this. It is also why a quotation that is mostly about the model is a quotation from someone who has not built one.
What I build
- Assistants that reach your systems, not a chat window that only talks. Where the whole project is a customer-facing assistant, that is covered on its own page: chatbot development.
- Document and process work — reading, classifying, extracting and routing what currently arrives as PDFs, emails and photographs of paper.
- Retrieval over your own material, so answers come from your contracts, your manuals and your history rather than from the internet, with a citation attached to every answer.
- Internal tools that put the capability where the work already happens, which is usually a screen your team already opens, not a new one.
- The unglamorous half: the evaluation set, the logging, the permissions, the fallbacks, and the runbook for the morning it answers wrongly.
Where the goal is fewer manual hours rather than a new capability, the honest answer is often plain automation with no model in it at all. That work is described under AI automation.
Building in Arabic is a different build
Every system I build here has to work for customers who write in Arabic, in English, and in the mixture of both that people actually type. That is not a translation task at the end. Retrieval has to find the right paragraph in an Arabic document, which means the text has to be extracted properly from PDFs that were exported without it, and matched despite the spelling variations people use for the same word. Names and numbers have to be repeated back in the form they were given. Amounts, dates and reference numbers have to survive being read in one script and written in another, because that is where silent errors hide.
None of this is difficult once it is in the specification. All of it is expensive when it is discovered after acceptance, which is the usual sequence. The practical test is simple: put twenty real Arabic messages from your own inbox into the evaluation set on day one, and do not accept the system until it passes them.
The evaluation set is the real deliverable
A demonstration proves the system can be right once. What you need to know is how often it is wrong, in which direction, and whether last week’s change made it worse. That requires a written set of real cases with expected answers, run on every change, scored the same way each time. Microsoft’s own design and evaluation guide for retrieval systems puts the same point plainly: evaluation is a phase of the build, not a check at the end.
Insist on it in the contract. A supplier who cannot show you the score sheet is asking you to accept their impression of the system instead of a measurement, and it is the single clause that most often separates a project that improves from one that merely changes.
What it costs to run, and what it costs to keep
The build price is the part everyone compares. The running bill is the part that surprises: tokens per request multiplied by requests per day, plus retries, plus the retrieval index, plus the logging. Success raises it, which is a strange thing to explain after launch and an easy thing to model beforehand.
Then there is the maintenance nobody quotes. Google’s research team named this a decade ago in the high-interest credit card of technical debt: machine-learning systems carry all the ordinary maintenance costs of software plus a set of their own, because the world the system was tuned against keeps moving. Models are deprecated and replaced. Your documents change. Your processes change. A build with no owner and no budget after launch degrades quietly, and quietly is the worst way for it to happen.
What has to be answered before it goes live
Three questions, and none of them is optional here.
- Where does the data go. Which fields leave your network, to which provider, in which country, retained for how long, and whether the provider trains on it. Kuwait’s regulator, CITRA, expects you to collect only what the service needs and to protect what is sensitive, and that principle survives every change of technology.
- What can go wrong on purpose. The OWASP Top 10 for LLM Applications is the shortest useful list: prompt injection, leaking data through the output, and giving the system more authority than the task needs. A build that has not answered them has not been secured, whatever the demonstration looked like.
- Who owns it. The NIST AI Risk Management Framework is heavier than most Kuwaiti companies need in full, but its first function is the one that matters: govern. Somebody by name is accountable for what the system says.
What I will tell you not to build
Anything whose value is a demonstration to the board. Anything that replaces a process nobody has written down, because the writing down is the project and the software is the easy part afterwards; that argument is set out in automating a process nobody has written down. Anything where a wrong answer reaches a customer or a regulator with no human in between and no way to tell it happened. And anything custom where a product would do, which is the most expensive mistake on this page, because it is paid twice: once to build it and again every year to keep it alive.
How the work runs
Four steps, in this order. A short assessment that picks the use case and settles which of the four shapes above you are buying. A written specification: the data, the boundaries, the evaluation set, the failure behaviour and the running-cost model. A build in one narrow slice that reaches real users rather than a pilot that reaches a slide. Then handover, which means your team can run it, change it and read its logs without me. If the technology decisions are larger than one project, that is a fractional CTO engagement instead, and I will say so rather than sell you a build.
Frequently asked questions
How long before we see something real?
Six to ten weeks for a first slice that real users touch, on a narrow use case with data you already hold. Longer than that usually means the scope was never narrowed, or the data turned out to live somewhere nobody had checked. I would rather cut the scope than extend the date, because a system in use for eight weeks teaches you more than a bigger one still in testing.
Do we need to train our own model?
Almost certainly not. Training is expensive, needs a quantity of labelled data most companies here do not have, and the result is behind the general models again within a year. Nearly every business problem is solved by giving a general model access to your own material and your own systems, with strict boundaries. If a case genuinely needs a trained model, that is a finding from the assessment, not an assumption at the start.
Our data is messy and spread across systems. Do we fix that first?
No, and waiting for a data cleanup is how these projects die. Pick one use case, find the data that case actually needs, and fix only that. A narrow build is a much better forcing function for data quality than a data programme with no application attached, because you find out immediately which fields are wrong in a way that matters.
What happens when the model we build on is retired?
It will be, roughly every year or so. That is why the build keeps the model behind a boundary in your own code rather than scattering provider-specific calls through the application, and why the evaluation set exists: swapping the model becomes a change you can run the tests against instead of a rebuild you have to argue about. Ask any supplier how they intend to handle it before you sign.
Do you build it yourself, or manage a team?
Both, depending on size. Small builds I do directly. Larger ones I specify, then oversee the team building it, whether that is your developers or a supplier you already use. What does not change is the specification, the evaluation set and the handover. If you want to understand the decision before committing to any of it, start with AI consulting.