Custom AI vs off-the-shelf AI: how to decide

The question is framed wrong

"Should we build custom AI or buy a tool" treats the two as substitutes. In an operations stack they rarely compete for the same job. What you can buy is the model, and sometimes a generic workflow around it. What you cannot buy is the part that knows which system owns which fact, who may approve what, and what happens when the order does not match the invoice.

So the useful question is narrower. For each piece of work: does an off-the-shelf tool carry the integration and the approval design you need, or only the model? If all three, buy it. If only the model, you will build the rest whether you plan to or not. The guide to custom AI solutions for business covers what "custom" does and does not mean; this post is about making the call.

When off-the-shelf is the right answer

A SaaS tool wins when the work is the same at your company as everywhere else, when its output stays inside the tool or in a document a person reads, and when nobody needs to approve anything before it takes effect. Meeting transcription, first-draft writing, a dashboard over a database you already have: these are solved problems, and building your own is a way to spend a quarter arriving where you could have started.

The test is whether you can evaluate the tool in a week with real data and no engineering. If it does the job, stop there. A custom build has to earn its place against that baseline, not a blank page.

When it is not

The off-the-shelf answer stops at the first write into a system of record. Once the tool is expected to change a price, raise a purchase order or reply to a customer under your name, it needs three things no generic product can know.

The hidden costs on each side

Buying

The subscription is the visible cost. The invisible one is the integration you build anyway: the connector that pulls the tool's output into the ERP, the script that reconciles it, the person who checks it. Then the data: a tool with access to your orders and customers is a third party holding operational data. And the exception list, which grows, and which the vendor will not prioritize because your exceptions are not their other customers'.

Building

The first version is the cheap part. A custom system has to be hosted, its credentials rotated, its scheduled jobs watched, its prompts revisited when the model provider ships a version that behaves differently. It also needs a security review of its write paths before it is trusted with the ERP. That is a cost of building, not an optional extra.

The most expensive custom failure is over-building: your own model layer, vector search and chat interface, when each is a commodity. Custom should mean custom where your business is different, and bought everywhere it is not.

The hybrid that usually wins

Buy the model. Build the integration and the approval layer. The model is reached over an API and can be swapped when a better one appears, because nothing of yours is inside it. What you own is thin and specific: code that reads your systems, treats the model's output as a proposal, and writes into the system of record only through a deterministic path, only after the right person has said yes.

This is the shape of Butler's support desk at PPC International, a Brdy Holdings portfolio company and a business we own. The model drafts the reply and never executes anything. Orders are executed deterministically by Butler's own code, and a person approves the send. What goes wrong without that split is in three ways an ops agent fails.

Three examples from operations work

End-of-day reporting: buy, then maybe build a little

If the report is numbers from one database, a BI tool is the answer. It becomes a build when the report pulls from the ERP, the storefronts and the shipping platform, applies the company's own definition of shipped, and posts a summary to a channel every evening. The assembly and the posting are built, and they are small.

Purchase planning: build the write, buy nothing in the middle

Reorder suggestions depend on ERP stock, open purchase orders, vendor lead times and this week's sales. Forecasting products exist, but they typically hold the suggestion in their own system and expect a person to re-key the purchase order. The valuable step is the last one: a draft purchase order in the ERP, waiting for approval. That is custom because the ERP and the approver are yours.

Customer support: buy the inbox, build the boundary

Helpdesk products draft replies well. What they cannot safely do is look up the order in your ERP, decide a remedy and apply it. The build is the boundary: the model drafts, deterministic code executes, a person approves. Everything beyond it stays bought.

A decision framework you can run in an afternoon

1. Does it write into a system of record? If no, lean buy. If yes, the write path is custom whatever else is bought.
2. Who approves the outcome today? If "nobody, it just happens", a tool may fit. If it is a name, the approval layer is custom.
3. How many cases are exceptions? Count them for a week. If exceptions are the job, a generic workflow automates the easy part and leaves the team the hard part.
4. Where would the data sit? If operational data would leave your infrastructure, decide that deliberately, in writing, with whoever owns risk.
5. Can you evaluate a tool with real data in a week? If yes, do that first. A build that cannot beat the tool you tried should not happen.

If you are not sure what belongs on the candidate list, that is what an AI opportunity assessment is for. If the list is mostly ERP and ecommerce work, our AI automation for ERP and ecommerce operations page describes the pattern we build to.