The build-vs-buy decision has been debated in every enterprise IT strategy meeting for thirty years. The debate keeps happening because the framing is wrong. The question is what the capability is worth to the enterprise, and where the risk actually lives.
Reframed that way, the answer is a portfolio, not a preference.
The three questions that actually decide
Every capability the enterprise depends on falls out of the same three questions.
Is this capability core to how the enterprise wins? A capability is core if losing it materially changes the enterprise's competitive position, or if running it well is a source of differentiation. A capability is commodity if any competent vendor could run it as well or better than the enterprise ever will. Most enterprise IT capabilities are commodity. Some are core. The ones executives most often get wrong are the ones they assume are core because they have always been internal.
Does the enterprise have the depth to run it well? Owning a capability internally is a decision to develop and retain a team, indefinitely, at whatever labor-market clearing price the capability commands. If the depth is not there today, and the enterprise cannot credibly build it, insourcing the capability creates the risk of running the capability badly with internal staff who lack the specialty depth. That is worse than outsourcing.
What is the risk of external ownership? Some capabilities carry regulatory exposure, data-sovereignty concerns, integration risk, or vendor concentration risk that changes the outsourcing calculus. Handing regulated customer data to a vendor with weak controls is a governance failure even if the vendor is cheaper. Concentrating four critical capabilities on one vendor creates an operational-risk profile no CFO signs off on if it is presented honestly. In EU financial services, this concern has moved from prudential to compliance: the Digital Operational Resilience Act, binding since January 2025, legally requires concentration-risk assessment and tested exit strategies for critical third-party ICT providers.
The three questions produce four answers. Insource. Outsource. Co-source. Retire the capability entirely.
Where each answer breaks
Insource breaks when the enterprise does not have and cannot credibly build the depth. This is common in specialized security, advanced networking, and vendor-specific expertise where the labor market is tight and the specialty is easier to rent than to own. Enterprises that insource these capabilities out of tradition rather than depth end up running them thinly and paying a reliability tax that never appears on a purchase order.
Outsource breaks when the capability turns out to be core after all, and the enterprise has now handed a source of differentiation to a vendor whose incentives will eventually diverge. This failure mode is slow. It surfaces years after the outsourcing decision, when the vendor has become a bottleneck on strategic change, or when the enterprise realizes it has lost the ability to develop the capability internally at all. Rebuilding that depth, once lost, is significantly more expensive than preserving it would have been. The current live example is cloud repatriation. Sixty-seven percent of enterprises have repatriated at least some workloads; eighty-seven percent plan more in the next twelve to twenty-four months. Boeing's reversal from seventy percent to fifty percent outsourcing dependency is the same pattern at a different scale.
Co-source breaks when there is no clear ownership boundary. Co-source works when the enterprise owns the strategy and the vendor owns a defined execution scope. It fails when both parties own everything or when neither party owns the failure mode. The most common co-source failure is a runbook that assumes the vendor will handle what only the enterprise team actually knows how to handle, or vice versa.
Retiring the capability is the fourth answer, and the one most enterprises never seriously consider. Some capabilities are not worth having at all, and the honest assessment is that the enterprise is running them out of habit. Retiring the capability is a governance decision rather than a technology decision, and it is often the highest-return move on the table when it applies.
The co-source middle ground
Co-sourcing is where most mature enterprise portfolios actually land, and it is the answer that most build-vs-buy debates miss because they are structured around the binary.
A well-designed co-source arrangement has three properties. The enterprise owns the strategy, the architecture decisions, and the accountability to the business. The vendor owns a bounded execution scope with clear service-level definitions. And the shared surface between the two has a named owner on each side, on the record, with a defined escalation path.
The failure mode is not co-sourcing itself. It is co-sourcing without the discipline. The arrangement that looks co-sourced on the org chart but has no owner of the shared surface is not a co-source. It is a hand-off waiting to fail during an incident.
What the C-suite actually owns
The insource-outsource-co-source decision is a portfolio decision that the executive team owns, rather than a per-project decision. The IT function can advise. The vendor evaluation function can support. The CFO's team can model the economics. But the trade-off between capability depth, vendor risk, and long-run strategic optionality is a business decision that sits above any of those functions.
The enterprises that get this wrong tend to make the decision by drift. Each individual project makes a defensible local call. The aggregate becomes a portfolio nobody chose, with too much vendor concentration in the wrong places, too much internal ownership of commodity work, and no coherent view of which capabilities the enterprise is deliberately keeping close and which it is deliberately letting go.
The emerging pattern for AI capabilities makes the portfolio question sharper. The industry consensus is buy the platform, build the differentiator. Buy the foundation models, buy the base infrastructure, but build the enterprise-specific application, the domain fine-tuning, and the human-in-the-loop workflow. The enterprises that get AI sourcing right are the ones that already have a capability portfolio discipline, applied to a new category. The enterprises that got it wrong tried to answer it as a build-vs-buy question and picked one.
The move that changes the pattern is a periodic executive review of the capability portfolio, treated with the same seriousness as a budget review. What is core. What is commodity. What is the enterprise deliberately owning. What is the enterprise deliberately not owning. And where has the portfolio drifted from the answers the executive team last agreed to.
That review is where the build-vs-buy debate finally becomes useful, as a portfolio review the executive team owns.
Adam Cooper is a Marine Corps veteran who leads global technology operations across maritime, transportation, hospitality, and industrial environments. He writes about enterprise IT governance, distributed operations at scale, and the executive dynamics of senior technology leadership. Connect on LinkedIn or Send Email.