A guide to custom AI software for business leaders

Most companies have tried AI by now in some form. A chat assistant, a copilot bundled into software they already pay for, maybe a pilot run by an enthusiastic team. The general tools tend to help with general work like drafting emails and summarizing meetings. They help much less with the jobs that cost the business real money, because those jobs are usually peculiar to the business.

This guide is for leaders wondering whether to build something for those jobs.

What we mean by custom AI software

Custom AI software is written for one organization’s problem. Somewhere inside it there’s AI: a language model reading incoming documents, an agent working through a queue of tasks, a model forecasting next month’s demand. Around that sits a lot of ordinary engineering. The software has to connect to your systems, present something people can use, keep data secure and log what it does.

People are often surprised by how small the AI part is. On many projects it’s a minority of the code. The value comes from fitting the whole thing to how one organization works.

Some examples of the kind of thing that gets built:

• An agent that takes a supplier invoice, checks it against the purchase order and the delivery record, and only asks a person when something doesn’t match.
• A tool that reads incoming claims, pulls out the fields the claims system needs, and flags the ones that look unusual.
• A search tool over a firm’s contracts that answers questions with the clause and page it came from.
• An internal app for a scheduling team that replaces three spreadsheets and a whiteboard.
• A demand forecast built into the screen where buyers place orders, not sitting in a separate report.

Build or buy

Building isn’t always the right call, and anyone who tells you otherwise is selling something. A quick way to think about it is to ask three questions. Is the problem specific to us? Does a product already handle it well enough? And would doing it better than competitors actually matter?

If the problem is specific and no product fits, building is worth a serious look. If a product already does the job at a reasonable cost, buy it. We go into more detail in build or buy AI.

How a project usually runs

The details differ, but good projects tend to follow the same broad path. It’s the one our approach is based on.

Spend time with the people who have the problem

The most common reason AI projects disappoint is that the team built what the brief described, and the brief was wrong. Not badly wrong, just missing the exceptions and workarounds that people handle without thinking. You find those by sitting with the team for a while. This is the main idea behind forward-deployed engineering.

Pick one problem and write it down

From what they’ve seen, the team picks the problem to start with and writes down what the software must do, what it must never do, and how everyone will judge whether it works. Scoping an AI use case covers this step.

Build a prototype and put it in front of users

A rough working version, run on your own data and tried by the people who’ll use it, answers questions that no requirements document can. It shows whether the approach holds up and where the hard parts are, and it’s cheap compared with finding out later.

Build the production version

This is where the bulk of the engineering goes: connecting to your systems properly, security, error handling, testing against the agreed measures, safeguards and monitoring. What makes AI production-ready lists what’s involved.

Hand over, then look for the next problem

Your team gets documentation and training. Results get checked against what was agreed. Often the same software can be extended to a neighbouring problem for much less than the first one cost.

Choosing a firm

Most AI firms will mention the same models and frameworks, so that tells you little. More useful questions:

How will you learn our problem? You want to hear about time spent with the people doing the work, not just interviews with executives.

How will we know it works? Look for measures agreed before the build starts, and a prototype that its users get to try early.

What happens after launch? There should be monitoring, a runbook, and a plan for your people to take it over.

And when would you tell us not to build? A firm that will sometimes say “buy this instead” is easier to trust when it says “build”.

Where to start

Start with a problem. Pick the process or decision that costs the most and hasn’t been fixed by the tools you already own, and go and look at it closely.

If you’d like to talk one through, get in touch. For new articles as we publish them, subscribe.