Buy, build, or partner: a decision tree for enterprise AI tooling

Most teams answer the build-or-buy question once, and they answer it too early. It gets decided at the company level, before there is a real AI project on the table. "We're a build shop, we have engineers." Or the opposite, "we buy, we don't reinvent wheels." And then that one answer quietly becomes the rule for everything that follows.

That is where it goes wrong.

Build, buy, wrap, or partner is not a company policy. It is a decision you make one workflow at a time. The same business should often land on different answers for two workflows sitting one desk apart. A customer-facing document generator, with sensitive data and a stable spec, might be worth building. The internal meeting-notes tool two desks over is something you just buy, because a dozen vendors already do it well and your version would be no different. Same company, same week, two answers that contradict each other, and both of them right.

When one company-wide answer gets applied to every decision, here is what you actually get. The build shop builds things it should have bought, and burns months of engineering time rebuilding software that already exists. The buy shop buys things it should have built, and ends up with a tool that almost fits, owned by a vendor, shaping a workflow that was supposed to be its edge. Both are expensive. Both are avoidable. And neither shows up as a line item, which is exactly why they keep happening.

The rest of this piece is a decision tree. Four options, four signals, walked in order. It will not tell you that building is the serious choice and buying is the lazy one, or the reverse. It tells you which of the four fits the workflow in front of you right now.

Why this mattersWhy one answer can't cover every workflow

The reason the company-wide answer fails is that it sorts on the wrong thing. "Are we a build shop?" sorts on who you think you are. The decision should sort on the workflow itself.

Four signals decide it. Not one of them holds steady across a company. Every one of them shifts from workflow to workflow.

• Workflow specificity
  How particular is this workflow to the way your business actually runs? An approval flow shaped by your own compliance rules is specific. Transcribing meetings is not. The more specific it is, the less likely an off-the-shelf tool will fit, and the more a custom build starts to earn its cost.
• Data sensitivity
  What does this workflow touch? Customer records, contracts, anything regulated — all of it raises the cost of handing the workflow to a vendor whose data terms you don't control. Low-sensitivity workflows make buying easy. High-sensitivity ones push you toward options where you keep your hands on the data.
• Rate of change
  How often will the requirements move? A stable workflow rewards a one-time build. A workflow you're still figuring out punishes it, because you will be rebuilding it. The faster it changes, the more you want an option you can adjust cheaply.
• Internal capacity
  Not "do we have engineers" but "do we have the right engineers free for this, and free to keep maintaining it after launch." This is the signal teams misread most often. They count heads at the start and forget that a build is a standing commitment, not a one-time cost.

Look at what those four have in common. Every one of them is a property of the workflow, not the company. That is the whole argument. A company does not have a build-or-buy answer. Each workflow has its own.

The decision treeThe four options, and what each one costs

The tree above walks three questions. The prose here is the part the boxes can't carry: why each branch goes where it goes.

The first question, specificity, is what rules Buy out. If a workflow is generic, a dozen vendors already do it well and your version wouldn't be meaningfully different, Buy is the honest answer. A workflow that is your competitive edge should not be owned by a vendor.

The second question, capacity, is the one teams get wrong most often. A specific workflow with the right engineers genuinely free points to Build. A specific workflow without that capacity points to Partner. The wrong turn is letting a capacity gap push a specific workflow toward an off-the-shelf tool that was never going to fit. Missing capacity is a reason to bring in help, not a reason to abandon the build.

The last question separates Wrap from Partner, and the difference is depth. A workflow that needs custom behaviour but not a custom model points to Wrap. Your team builds the thin layer, a vendor model sits underneath. A workflow that needs a full custom system points to Partner. An external team builds it alongside your team, and the capability transfers in as they go. Wrap is a layer. Partner is a system.

Here is how the four compare:

None of the four is the sophisticated choice. Build is not a sign of a serious team, and Buy is not a shortcut. The serious move is matching the option to the signals, and being honest about the limitation you're accepting, because every one of the four has one.

The honest partThe trade-off you're actually making

The table names a limitation for every option. Sit with that for a second, because it is the real point of the piece.

There is no clean choice here. Build trades speed for control. You wait longer and you carry the maintenance, and in return you get a system that fits and that you own. Buy trades fit for speed. You move now, and you accept a tool shaped by somebody else. Wrap trades independence for leverage. You get custom behaviour fast, sitting on a model whose direction you don't set. Partner trades pure self-reliance for capability you don't have yet, and it only pays off if that capability actually transfers.

The decision tree is not here to find you the option with no downside, because there isn't one. It is here to make sure the downside you accept is the one you can live with, for this particular workflow.

Why this mattersWhy it matters more than it looks

Deloitte's State of AI in the Enterprise report has tracked a steady pattern.¹ AI spend keeps rising while measurable return stays harder to show than leaders expect. The usual explanation is model performance or skills shortage. A quieter cause is upstream of both. The build, buy, wrap, or partner call was made once, at the company level, and then misapplied workflow after workflow. Money goes to building what should have been bought, or buying what should have been built. The model was never the problem. The routing was.

This is the same operating-model question that decides whether enterprise AI implementation creates compounding value or a portfolio of half-finished pilots, and it sits upstream of the work of moving prototypes to production.

In practiceWhat this leaves you with

The useful shift is small. Stop asking "are we a build company or a buy company." Start asking, for one workflow at a time, what the four signals say.

In practice that is three moves. First, name one real workflow, not a category. Not "customer service," but the specific flow — for example "drafting first-response replies to billing queries." Second, score it cold on the four signals: how specific to your business, how sensitive the data, how fast the requirements move, and whether the right engineers are genuinely free. Be honest on the last one, capacity is the signal most teams flatter themselves on. Third, read where it lands. High specificity with free capacity points to Build. Low specificity points to Buy. Custom behaviour without a custom model points to Wrap. Build-grade signals without the capacity points to Partner.

The answer will vary across workflows that sit close together, and that variation is correct, not messy. A company doesn't have a build, buy, wrap, or partner answer. Each workflow does. Getting that right is quieter than a big AI strategy, and it saves more. For a sharper sense of which of your workflows are real AI candidates in the first place, the same logic applies in how to score an AI use case before you build it.