Build or buy AI for business

Start with the job

The useful way to approach build or buy AI is to begin with a job that is currently slow, inconsistent or hard to scale. “We need an AI strategy” is not a job. “Turn incoming supplier certificates into checked records for the quality team” is. A 40-person manufacturer may have the second problem. It does not need a proprietary language model to solve it.

Write down the user, the input, the decision or output, the consequences of a wrong answer and the existing system of record. If the work is not clear enough to describe in one paragraph, it is too early to select software. Assessing AI readiness is often a better first move than comparing vendors.

A tool is not a use case. Treat “use ChatGPT more” as a prompt to find the real task, owner and measure of a better result.

There are three real choices

Most decisions sit on a spectrum, not a binary. You can buy a finished product, configure a platform around your process, or build a custom application. The middle option is frequently missed because it sounds less dramatic than a new product and more involved than a licence.

Count the cost of ownership

A licence fee or a development estimate is only the first number. The total cost of ownership includes configuration, integration, data preparation, access control, user support, quality checks, monitoring, incident handling and the time a named person spends keeping the work useful. A solution that looks cheap in a demonstration can be expensive once it relies on an operations manager to correct it every day.

Maintenance is the deciding cost

AI systems change even when your process does not. Models are updated, APIs are retired, pricing moves, document formats drift and staff find edge cases. Ask who will review output samples, change prompts or rules, retest a model upgrade and decide when to stop using a feature. If there is no credible answer, reduce the scope or choose a product that carries more of that burden.

This is where AI implementation work needs to be treated as operational work, not a one-off IT project. The best technical choice can still fail if nobody owns the process after the launch week.

Separate recurring operating cost from the cost of learning. A pilot may need more hands-on review than a mature process, and that is normal. What matters is whether the review teaches you how to reduce risk or simply becomes permanent rework. Track the difficult cases, the sources users distrust and the changes that solve them. If the same correction is made repeatedly, the process or data design needs attention before further rollout.

Avoid the API call trap

“It is just an API call” is technically true in the same way that sending an email is just an internet connection. The call is the easy part. Production work needs authentication, permissions, audit trails, sensible failure handling, version control, evaluation examples and a route for people to correct or override a result. It also needs a decision about what leaves your systems and under which contract.

A custom assistant that drafts answers from a policy library sounds simple until the library contains obsolete documents, different departments use different versions and no one has agreed whether the assistant may answer with confidence. A smaller workflow that retrieves approved sources and routes uncertainty to a person is usually a better first release.

• Can a user see the source material behind an answer?
• What happens when a system is unavailable, uncertain or wrong?
• Can you test the work against a fixed set of real examples before and after changes?
• Who can alter prompts, connected data and permissions?

Treat lock-in as a design issue

Vendor lock-in is not automatically bad. A good product may save months of internal effort. It becomes a problem when you cannot take your data, workflow rules, output history or evaluation set with you. Before signing, ask what you can export, in what format, how long it takes, and whether an alternative system could reuse the material.

Keep your valuable assets separate where possible: source documents in systems you control, a plain-language process description, a list of test cases, and records of decisions made by people. If a vendor has a closed connector or owns the only copy of a workflow, the apparent convenience may be storing up future cost. A sensible AI policy should also say who can approve new tools and connections.

Buy is improving faster than plans

The buy option is improving quickly. Features that once justified a custom build, such as summarising documents, extracting fields, drafting routine text, classifying enquiries and searching a controlled knowledge base, are increasingly available in mainstream business software. That does not remove the need for judgement. It does mean you should be sceptical of building a private version of a capability that may arrive in your existing stack before the build is finished.

Custom work still pays where the value comes from your particular combination of process, data and systems. Examples include checking engineering documents against your own rules, coordinating work across a legacy planning system and a customer portal, or applying a carefully governed decision process that a generic product cannot represent. The differentiator is the workflow around the model, not the model itself.

Make the decision on one page

Put the options through the same test. Do not let a striking demonstration set the standard for one option while a spreadsheet sets the standard for another. A short AI consulting assessment can make this comparison concrete before a team commits to procurement or development.

1. Define one workflow, its owner, its current failure points and the cost of getting it wrong.
2. Check whether a product already solves at least 80% of the job with acceptable data, access and review controls.
3. Price configuration and custom work with twelve months of maintenance, not just launch costs.
4. Score each route for speed, fit, portability, control, integration effort and dependence on scarce internal people.
5. Run the smallest safe pilot that can disprove your assumptions, then decide whether to scale, configure further or build.

There is also a fourth response: wait. If no option clears the test, do not disguise uncertainty as a pilot. Spend a short period documenting the process, resolving access problems or collecting representative examples. That work makes the later choice more defensible. It is cheaper to postpone an unclear build than to maintain an unclear system.

Take a clear position: buy for common, low-differentiation work; configure when your context matters; build only when the work is strategically distinctive and you can own it. The discipline is not choosing the most sophisticated route. It is choosing the route you can still support next year. Use the build or buy AI framework whenever a new proposal reaches the same decision.