Adding AI Features to Software You Already Run

The integration problem, not the modelling problem

Most AI features fail by being ignored, not by being wrong. A suggestion sitting in a separate AI tab nobody opens is worse than no feature at all, because it was paid for. The ones that get used appear in the order screen, the approval queue, or next to the field a person was already about to type into — which is an integration problem more than a modelling one.

Can you add AI to a system you did not build?

Usually, yes. What decides it is whether the system exposes an API or a database that can be read, and whether there is a screen the result can be put into. A closed SaaS product with neither is the hard case. Anything custom-built — including systems built by other agencies — is normally straightforward.

How the work runs

• Name the decision the feature affects, in one sentence, with the cost of getting it wrong
• Set the review rule: automatic, suggested-with-confirmation, or flagged for a human
• Build the thinnest version that touches real data and measure it against real cases
• Design the failure path first — what happens when the model is slow, unavailable, or unsure
• Ship behind a switch your own team can turn off without a deployment

What it costs, and what is not fixed

The build is quoted fixed against a written scope, like the rest of our work. The part clients underestimate is the running cost — model inference is billed per use, so a feature used two hundred times a day carries an ongoing bill. That gets modelled at your expected volumes and put in the proposal rather than surfacing as a surprise later.

What we will not promise

No accuracy figure before we have seen your data, and no claim that the model will always be right — the screen is designed around the assumption that it sometimes will not be.