The Real Reason Build vs Buy No Longer Works
As the economics and ownership of tech change, moving at speed and with control forces new, non-negotiable questions for COOs.
One of the most common questions we’re hearing from COOs on enterprise technology: Should we build or buy? But it’s increasingly the wrong one – and, in many cases, a costly distraction, because something fundamental has changed.
Systems are now starting to execute work. Agents make decisions, systems trigger actions, and workflows adapt in real time. But that execution is no longer tied to a single functional owner. It is distributed across systems, decision logic, and workflows that span multiple parts of the business.
As a result, the build vs buy question is rooted in an assumption that no longer holds: that someone owns the system – and by extension, owns how decisions are made within it.
The Economics Have Shifted…
Where systems were once large, fixed investments, they are increasingly modular, composable, and consumed on demand.
We are already seeing this play out in how AI is being priced and deployed. NVIDIA CEO Jensen Huang recently described future computers as “manufacturing equipment” that produce tokens, with tokens becoming a core line item in corporate budgets (OpenAI token processing has jumped 20x in two years), much like laptops or software subscriptions.
This framing reflects a new reality: capability is no longer bought upfront but rather consumed continuously and tied directly to output.
As the cost of building capability falls, the cost of getting decisions wrong rises – not in choosing the technology, but in the day-to-day decisions it executes. Those decisions now happen faster, more frequently, and at greater scale, so errors propagate just as quickly.
Importantly, this does not mean the core disappears. Systems like ERP remain critical, but their role is changing. They are becoming the substrate of the enterprise: the place where decisions are enforced, not where they are made.
…And So Has Ownership
Historically, the ownership of tech decisions sat with IT. Systems were implemented centrally, workflows were largely fixed, and decisions were made outside the system – by people, across functions, and then executed downstream. In that world, the tradeoff was relatively clear. You either built capability to fit your needs, or you bought it off the shelf.
But as systems move closer to the flow of work (and leading orgs increasingly move toward workflow-based, end-to-end teams), no single function owns how the business decides anymore.
Against this backdrop, ownership fragments across functions because technology is no longer sitting above workflows but embedded within them. Decisions are now made in the flow of work itself, pulling multiple perspectives and priorities into the same moment:
• The COO is accountable for outcomes: speed, service, cost, and capital. Their concern is whether a given capability improves how quickly and effectively the business can respond to reality.
• The technologist is accountable for system integrity: scalability, security, and control. Their concern is where that capability should sit to maintain a stable and scalable system.
• The functional leader is accountable for how decisions are actually made: the tradeoffs, context, and day-to-day execution. Their concern is whether the solution reflects how decisions are really made, or whether it imposes an external logic that doesn’t fit the business.
Each of these perspectives is valid, but they are not the same – and they are not naturally aligned.
The Consequences
This is why build vs buy starts to fail.
It tries to force a single answer onto what is now a multi-dimensional problem. What gets built might optimize for flexibility but introduce fragmentation. What gets bought might standardize capability but flatten differentiation. What gets layered in through orchestration can sit somewhere in between, but only if there is clarity on where decisions actually live and how they are governed.
The result is misalignment, but also slower decisions, the same logic rebuilt in multiple places, and teams that start acting on slightly different assumptions. Over time, the business stops moving as one, even though the technology itself is capable.
What This Means Now
Instead of asking whether to build or buy, organizations need to ask: Where does this decision live and who defines the logic behind it?
That’s where advantage sits – not in the tools or the stack, but in how decisions are defined and executed across the business. For COOs, this is a control decision and requires making three things explicit:
• Where decisions sit — which system or workflow owns the moment of decision
• How decisions are made — the tradeoffs and logic that govern them
• Who has authority — when decisions are automated, overridden, or escalated
If these elements aren’t deliberately defined, they get defined by default – across tools, teams, and workflows that don’t align. The result is a loss of speed and control.
As one CSCO recently put it, the biggest learning from implementing end-to-end agentic workflows wasn’t the technology. It was the lack of clarity on decision-making.
Rewiring how decisions are owned, defined, and executed is the no-regret move for right now. Until that is clear, no architecture will move the business at speed.