AI is separating two decisions enterprises used to treat as one: what should we build, and what should we own.
For years, enterprises framed the choice at the application level: buy a product or fund a team to build one. Coding agents weaken that framing. Teams can now create workflows, interfaces, integrations, and decision logic much faster, without rebuilding the platforms underneath them.
This makes the application an increasingly poor unit for a build-versus-buy decision. A company might buy the system of record, compose the workflow, and build the logic that differentiates its business.
But building something does not necessarily mean it is worth owning. And owning something does not require writing all of its code.
The distinction matters because ownership begins where generation ends: accountability for security, data quality, support, continuity, upgrades, cost, and eventual handover to someone who did not create it.
The shift is already visible. In McKinsey’s August 2026 State of AI survey, 32% of respondents said their organizations had decided against buying at least one software product or feature because they could build it internally with coding agents. Yet only 37% attributed at least some enterprise-level EBIT impact to AI, broadly unchanged from the prior year. Choosing to build is not evidence that building created value.
Stop deciding at the application level
Imagine a sales team asking for a tool that combines contract terms, opportunities, customer interactions, and a suggested next action.
The wrong first question is whether to buy or build “the sales app.”
The customer record and contract repository may belong in established systems of record. Permissions and audit trails can follow existing enterprise controls. But the logic that interprets contract terms, prioritizes opportunities, and determines what action to recommend may encode something distinctive about the business.
The company could therefore buy the underlying platforms while owning the decision logic and workflow that sit across them.
That produces four choices at the capability level: buy something standard, configure a product within its supported boundaries, compose existing services into a workflow, or build what requires custom software.
Those choices answer how a capability is created. A separate question is what the organization intends to own.
Ownership is more than code
Coding agents can compress the time needed to produce a first version. They do not answer who is accountable for it, who can change it, where its data came from, how it is tested, what happens when an upstream API changes, or who gets called when it fails.
AI-enabled workflows add model behavior, prompt and tool changes, evaluation, usage cost, and human override.
This is why ownership should not be confused with custom development. A company can own its decision logic while renting the platform that executes it. It can own a workflow assembled from vendor APIs. Conversely, it can possess thousands of lines of generated code without having meaningful ownership if nobody is accountable for operating them.
Consider an internal assistant that reads customer data and writes recommendations into a CRM. It works, adoption grows, and the company avoids another software subscription.
Six months later, its creator has moved on. Its permissions are broader than they should be. An upstream model has changed, and nobody has budgeted for regression testing. The code belongs to the company. The capability effectively belongs to nobody.
Make ownership manageable
This changes the role of enterprise architecture.
Instead of deciding which applications teams may build, architecture should provide the components that make ownership manageable: reusable identity and authorization, approved data access, deployment patterns, observability, evaluation, cost attribution, and clear service ownership.
Teams can then assemble or build differentiated capabilities without recreating basic controls each time.
There is an obvious danger. A “paved road” can become another governance layer. The practical test is whether a team can ship a supported workflow faster using the standard path than by bypassing it. If not, the platform needs work.
Test both decisions
At the next SaaS renewal or feature request, pick one bounded capability rather than comparing an entire product with an entire custom application.
First ask how it should be created: buy, configure, compose, or build. Then ask what the enterprise is prepared to own after launch.
Put the options against the same requirements: business outcome, implementation time, three-year operating cost, security and data obligations, switching cost, service level, and a named owner.
Make the assumptions testable. If a composed or custom option cannot meet the required service level, pass security review, and outperform the purchased alternative on agreed cost and time-to-value measures, buy the capability. Where proprietary logic or workflow creates sufficient value to justify the ongoing obligation, own that layer deliberately.
Record the assumptions and revisit them six months later.
AI is making it easier to create software without owning an entire application stack. Enterprises should use that freedom deliberately.
The question is no longer simply what to build or buy. It is where ownership should begin and end.