A build vs buy decision matrix for each AI use case

There are four options rather than two

"Build vs buy" dates from a world where software was either written or licensed. AI use cases arrive in more shapes than that, and treating them as a binary leads to two predictable errors: buying a generic tool for something that defines your business, or building a custom system for something a vendor already does well.

Buy. A finished product or a feature inside one: meeting transcription, email drafting, a vendor's chatbot. It is fast, cheap to start and someone else's problem to run. You get what everyone else gets.

Configure. AI features inside a platform you already own, pointed at your data and tuned to your process. Agentforce on Salesforce is the obvious example. It gives more control than buying, bounded by what the platform allows.

Assemble. Compose a system from commercial model APIs, a retrieval layer over your data, your own application and your own evaluation and security. You own the experience and the data flow without training a model. This is how most serious LLM products are built.

Build. Everything in assemble, plus your own models or fine-tuning, deep integration with your main systems and a team to evolve it. This is justified only where the use case is the business.

The matrix

Two questions place a use case on the matrix. How much does it differentiate you from competitors? And how unique are the data and process behind it?

The matrix is a tool for conversation rather than a verdict. Its value is in forcing two honest answers. Most use cases people want to build are not differentiating; most use cases people want to buy sit on data the vendor will never understand.

The hidden costs on every side

Each option carries costs that rarely appear in the first comparison. Put them on the table before choosing.

The cost most often missed is evaluation. Whichever option you choose, you need to know whether the system is doing the job and whether it still is after the next model update. A bought product does not remove that need; it just hides it. Our cost of LLM applications guide quantifies the buckets.

An illustrative example

Illustrative scenario. A mid-market logistics firm wants three things from AI: meeting summaries for its sales team, a customer support assistant over its service documentation, and a model that predicts delivery delays from its own operational history.

Meeting summaries are not differentiating and the data is standard: buy. The support assistant is customer-facing and shapes experience, but the data is ordinary documentation and the pattern is well understood: assemble, using commercial models and a retrieval layer, as described in RAG explained. Delay prediction is the business, and the data exists nowhere else: build, with a proper data engineering effort behind it.

Notice that the three decisions have three different time horizons and three different teams. A single "AI strategy" that chose one option for all three would have been wrong twice.

The decision checklist

Work through these for each use case. If you cannot answer one, that is the first task.

• Would a competitor using the same bought product erode our advantage? If yes, do not buy.
• Does the vendor's model understand our data, or merely store it? If the latter, configure or assemble.
• Can we export our data, prompts and history if we leave? If not, the price is higher than quoted.
• Do we have, or can we get, an evaluation set? Without one, no option can be judged.
• Who owns the system in two years, and are they funded?
• What is the three-year cost including people, usage growth and the cost of being wrong?
• Does the choice keep us free to change models and providers? See on-prem vs cloud LLMs.

When to change your mind

Decisions on this matrix are not permanent, and the costs of moving are lower than they used to be if you kept your data and evaluation sets outside the product. Revisit when a bought product starts shaping your process rather than serving it, when platform limits are met with workarounds, when a system you assembled becomes central enough to deserve investment, or when something you built becomes a commodity the market now sells. The last case is common and emotionally hard. Build-to-buy is a legitimate direction.

Set a yearly review of the portfolio. It takes an afternoon, and it is the part of AI strategy work that most often changes what the next year's budget buys.

Pitfalls

What matters most

• There are four options: buy, configure, assemble and build.
• Place each use case by how differentiating it is and how unique its data is.
• Most use cases belong in buy or assemble; build is for the few that are the business.
• Every option carries hidden costs; evaluation is the one always missed.
• Keep data, prompts and evaluation sets outside any product so you can move.
• Review the portfolio yearly; build-to-buy is a normal direction of travel.

Related services