On Forward / AI Workflows Hub
Decision

Build vs buy AI: the question that is actually wrong

If you lead operations or finance at a mid-market company, you have probably sat through some version of this debate. Do we build our own AI, or do we buy a platform? It feels like the decision. It is not.

The build vs buy framing is everywhere right now, and the published guidance has actually converged. The honest read across the 2026 analyses is that most enterprises no longer pick a side. They run a hybrid: buy the foundation, build the part that is specific to them. One widely cited industry breakdown puts it at roughly 47 percent hybrid, with pure buy succeeding far more often than pure build.

The piece we are responding to Digital Applied, Enterprise AI Agents 2026: Build vs Buy Decision Guide. A good, widely shared summary of where the market landed: hybrid is now the default, and pure internal builds have the lowest success rate.
BUILD own the logic BUY own the speed DOES THE TEAM ACTUALLY USE IT? value or nothing
Build and buy are both upstream of the only question that decides ROI.

Why the debate is a distraction

Here is what we see from the inside. A company spends two quarters deciding build vs buy, lands on a sensible hybrid, ships something, and then six months later the workflow it was meant to fix is still being done by hand. The tool exists. It just is not the thing people reach for when the work comes in.

That is not a build vs buy failure. It is an adoption failure, and adoption is decided long before you choose a vendor or a stack. It is decided by whether the system was shaped around how the work actually happens, who touches it, where the exceptions go, and whether the person doing the job trusts the output enough to stop double checking it.

A tool nobody uses is the most expensive thing you can buy, and the most expensive thing you can build.

The question we ask instead

When we sit down with an operations lead, we do not open with build or buy. We ask: are you looking for a tool your team runs themselves, or a partner who comes in, builds it around how you work, and gets it adopted? If the honest answer is the first one, off the shelf software is probably the better call and we will say so.

But for the workflows that are messy, specific, and spread across four systems that were never meant to talk to each other, the deciding factor is never the build vs buy line item. It is whether someone goes inside, maps the real process, and builds for that. We have done this three times in production. In a logistics firm we replaced three days a week of manual invoice matching with an agent built around their exact rules, and it stuck because it matched how they already worked, not how a generic tool assumed they did.

So before you spend a quarter on the build vs buy question, answer the cheaper one first. If we built or bought this tomorrow, what would have to be true for your team to actually use it on Monday? Start there. The rest follows.

About the author