Build, Buy, Automate—or Use AI?

When a company decides to “do something with AI,” the underlying question is rarely about AI. It’s the same question businesses have asked about every technology for decades: is this need best solved by building, buying, automating — or by changing the way the work gets done? AI added a branch to that tree. It didn’t replace it. This guide lays out the six possible outcomes and the eight questions that separate them.

Why AI isn’t the default answer

AI is the best tool for one specific kind of problem: decisions that require interpreting ambiguous information, based on patterns a rule can’t capture, with enough data and someone who can verify the output. Outside that territory it tends to be the most expensive option, the least predictable and the hardest to audit.

That’s why starting from “where can we use AI?” gets the order backwards. The useful order is: the need first, then the questions, and the outcome last — whatever it turns out to be.

The six possible outcomes

• Build: your own software, when the capability is part of how you compete and no product handles it the way it needs to.
• Buy: an existing product, configured and integrated, when the capability doesn’t differentiate.
• Automate: let a system run repetitive steps with clear rules, on top of a stable process.
• Use AI: a model that supports — or makes — decisions that require judgment, with data and verification.
• Change the process: remove steps, clarify ownership or eliminate duplicated information, sometimes without writing a line of code.
• Not yet: wait until the data, the owner or the stability the decision needs actually exists.

Outcomes combine. A need can end up as “change the process, then buy,” or “build, with AI in one specific step.” What matters is that every part of the answer has a reason behind it.

The eight questions that separate them

Criterion	Question	If yes…	If no…
Differentiation	Is it part of how you compete?	Leans toward build	Leans toward buy
Available software	Does a product cover most of the process?	Buy and integrate	Build, or simplify
Process stability	Does it run the same way every time?	Automate	Change the process first
Rate of change	Do the rules change often?	Something the business can configure	Fixed rules
Judgment required	Does it involve interpreting ambiguous information?	An AI candidate	Rules, no AI
Data	Is there enough reliable history?	AI is viable	Not yet — or data first
Integration complexity	Must it read and write across several systems?	The cost is in the integrations	Buying or automating is simpler
Risk	Would a mistake be costly or hard to detect?	Human decision and controls	More automation, sampled review

There are no weights or scores. No question decides on its own, and adding up answers hides the one that matters most: if the risk is high, no number of “yes” answers on the other seven justifies taking people out of the decision.

How the answers combine

Some patterns come up often enough to be worth recognizing:

It doesn’t differentiate, and a product exists

Buy it. Building what the market already sells — accounting, payroll, a standard CRM — is rarely an advantage; it’s a maintenance cost nobody budgeted for. The real work is integrating it well and not bending the process to fit it.

The process is unstable

No technology fixes a process that changes depending on who runs it. Automating it locks in its errors; buying software to hold it up just makes them more expensive. Change the process first, then pick the tool.

There’s judgment, but no data

The need is a good AI candidate, but it isn’t viable today. The honest outcome is “not yet,” with a concrete task attached: start recording, reliably, the information a model would need. Often that record alone solves a good part of the problem.

There’s judgment, data, and an expensive mistake

Use AI as support, not as a replacement: the model estimates, recommends or ranks, and a person decides. The AI lives inside the workflow where the decision gets made — not in a separate tool nobody opens.

The capability differentiates, and nobody sells it

Build — but only the part that differentiates. Around almost any custom system there are standard pieces — authentication, payments, email, reporting — that are better bought.

An illustrative example

A field-services company (an illustrative example, not a client) runs three needs through the eight questions:

Need	What the questions said	Outcome
Billing and collections	Doesn’t differentiate; mature products exist; stable rules	Buy, and integrate with the work-order system
Assigning technicians to visits	Differentiates (it’s their service promise); no product respects their zone and specialty rules	Build, with rules operations can edit
Classifying incoming requests	Requires interpreting free text; years of classified history; a mistake gets caught at the next review	Use AI to suggest the category, with human confirmation

Three needs, three different outcomes, and only one uses AI. The company didn’t adopt “an AI strategy.” It made three decisions with the same discipline.

A real case: AI inside the workflow where the decision happens

Prenda Crédito Avanza is a lender in Guatemala that has run on the platform it built with Ciancoders since 2018. Assessing the risk of each application consistently took judgment — and the information needed already lived in the platform: every application and how it turned out. In late 2022, an AI model that estimates the risk of each application was added inside the existing approval workflow, rather than as a parallel tool. The final decision still belongs to the credit team. The written-off portfolio fell 19%, and the delinquent portfolio fell 8%.

That project didn’t come out of applying this matrix. We show it because it meets the conditions of the “use AI” branch: judgment required, reliable historical data, an expensive mistake, and a person who still makes the call.

Common mistakes

• Asking “where can we use AI?” instead of “what does this part of the business need?”
• Building out of pride something the market already solves better and cheaper.
• Buying to avoid deciding, then bending the process until the product fits.
• Automating a process nobody has reviewed.
• Comparing products by features and ignoring the cost of integrating them.
• Taking people out of an expensive decision because the model is “almost always right.”
• Reading “not yet” as failure, when it’s a list of conditions and a date to look again.