Why CIOs should reopen the build vs. buy question

Many companies are still buying software for workflows that define how they compete. That used to be a rational way to control costs and reduce risk. Increasingly, though, it’s becoming a quiet way to standardize away differentiation.

For most of the last 20 years, the CIO’s answer to build versus buy was clear: unless you’re a software company, don’t build. Buy a SaaS product, integrate it into the stack, and reserve scarce engineering capacity for the few places where custom work is unavoidable. That advice was rational. It protected companies from fragile custom systems, undocumented dependencies, runaway maintenance costs, and the shadow applications that later became operational liabilities.

But defaults age. When they do, leaders often continue defending them long after the conditions that made them useful have changed. The buy-default is reaching that point. The case for buy hasn’t disappeared, but its status as the automatic default has, and the CIO who continues to default to buy without revisiting why is no longer protecting the business from risk but protecting an assumption that’s quietly stopped being load-bearing.

What changed

Three shifts have moved the math, and the technology side of each one gets the headlines. The business consequence is the part the CIO must act on.

The first shift is cost. AI-assisted development has compressed the time from idea to working software from quarters to weeks, and in some cases prototypes that once required a formal six-figure engagement can now be produced by a small team in a sprint, or by a capable operator over a weekend. Productivity surveys of AI-assisted developers put the gain in the 70 to 90 percent range on routine engineering tasks, and several large technology firms now report that AI-generated code accounts for up to 40% of new commits. The business consequence is that workflows previously too expensive to customize are now economically viable. The custom build is no longer reserved for the few capabilities the business can’t live without. It’s available, in principle, for any capability where the off-the-shelf product forces a meaningful compromise.

The second is who can build. The democratization of software development is no longer a category of marketing slide. Gartner has been writing for years about fusion teams and the rise of business-side technologists, and the AI generation of coding tools has accelerated that trajectory beyond what most enterprise architecture functions are tracking.

Recent usage data on AI-assisted coding platforms suggest that roughly 65% of users don’t come from a developer background. They sit in operations, marketing, and finance, and they increasingly produce working internal applications, not just demos or toys. The business consequence is that build decisions will happen whether CIOs govern them or not. The CIO who assumes building still requires hiring a software team is operating on a labor market description that no longer matches reality, and is also operating on the assumption that the build-or-no-build decision still sits inside IT. It doesn’t.

The third shift is what gets exposed. The traditional reasons custom builds failed haven’t vanished. Authentication, scalability, recoverability, security, and maintainability are still real engineering disciplines, and they still consume real effort. What’s changed is they’re increasingly available as managed services, embedded primitives, or platform features.

Authentication can be subcontracted to a specialist provider. Compliance-aware data storage can be procured on a credit card. Documentation can be generated alongside the code it documents. The business consequence is that the risk has shifted from can we build it to can we govern what we build. That’s a different question, and most organizations aren’t yet structured to answer it.

The combination of those three shifts has done something the industry hasn’t fully digested yet: not eliminating the case for buy but eliminating the case for buy as automatic default.

Where the case for build now holds

This isn’t an argument that organizations should now build everything. The places where buy was the right answer for so many years remain the places where it’s still the right answer today.

For commodity workflows, accounting, payroll, calendaring, document storage, identity management, and the common operations of any business, the SaaS market wins decisively. The advantage of building these is small, the cost of maintaining them is real, and the supply of mature products is strong. CIOs are still correct to push back when a business unit proposes building its own ERP. That hasn’t changed, and it won’t.

What has changed is the second category — the workflows that aren’t commodity, the processes that distinguish the business from its competitors, and the operating model details that get bent around the limitations of off-the-shelf systems because no vendor has built a product that matches the actual shape of the work.

In that category, buying has always been a compromise. CIOs accepted the compromise because the alternative was building, and building was unaffordable. With the cost of building no longer prohibitive, that compromise becomes a deliberate choice rather than an unavoidable one. In the workflows where the business is supposed to be different from its competitors, accepting a vendor’s idea of how the work should be done isn’t a neutral position but a slow erosion of the differentiation the business is presumably trying to defend.

The CIO’s job is also to tell the difference between these requests, where buy still wins and the buy-default ones are now obstacles to the business’s competitive position.

This can’t become another category of decisions quietly delegated to IT. If a workflow defines how the business competes, the accountable owner must be the business leader who owns that capability. The CIO should own the architecture, guardrails, risk model, and integration logic, and the business should own the value, adoption, and operating consequences. When that split isn’t explicit, accountability disappears, and the build-versus-buy decision becomes another technology argument with business consequences no one owns.

The risks have moved, not disappeared.

It’d be irresponsible to write this without naming what hasn’t changed. Custom builds still fail when the people building them ignore non-functional requirements. Independent security reviews of AI-generated code report basic failure rates approaching half of the samples examined, with leaked secrets, hardcoded credentials, and misconfigured access controls turning up routinely when the builder isn’t a security practitioner.

Citizen developers still produce systems that look like they work and turn out to be ungoverned, undocumented, and unmaintainable. The single-point-of-failure problem, where the entire build lives in the head of one person who eventually leaves, isn’t theoretical. Most CIOs have either inherited a build like that or watched a peer do so. The reflexes that produced the buy-default aren’t arbitrary, they’re scar tissue.

The shift isn’t that those risks have disappeared. It’s where they sit within the decision’s architecture. They used to live in the column labelled “reasons not to start.” They now live in the “things to design for if you do” column. That’s a different conversation that requires a different role from the CIO than the one most of us were trained for.

In the previous era, the CIO’s value-add was largely defensive. Stop the bad build before it starts. Push the business toward the vendor that the company can hold accountable. Maintain the standardization that makes the environment sustainable. That work still matters, but it’s no longer sufficient.

The new value is architecture, not gatekeeping. It’s the ability to look at a workflow and tell the business whether buying it commoditizes a real differentiator, whether building it is operationally sustainable, what the maturity prerequisites are, and where the build needs to sit relative to the rest of the stack. It’s also the ability to govern citizen development without trying to suppress it, because suppression is no longer a viable strategy. Business users will build with or without IT’s blessing and the CIO who makes that an adversarial relationship loses both the build and the governance.

What this asks of the CIO function

If the build-versus-buy question is no longer settled, the CIO role can’t remain settled either. So, a few things follow.

Architecture must come back to the center of the role. Not enterprise architecture as the bureaucratic ritual it became in many organizations, but as the discipline of deciding which capabilities the business builds, buys, and how the two compose into something coherent. That work can’t be delegated to vendors or business units, both of whom have legitimate but partial views of the question.

Governance of citizen development becomes a real responsibility, not a residual one. The CIO who pretends business users aren’t building loses visibility into a category of growing risk. The CIO who entirely shuts down citizen development loses the ability to capture the value it can produce. The middle path of frameworks, sandboxes, security primitives, and lightweight standards, is harder to design and run than either extreme, and it’s now part of the job.

Talent strategy has to update. The CIO function has been hiring against a labor market that assumed a sharp line between business users and software developers. That line has become a gradient. Hiring needs to follow.

Most importantly, the CIO needs to be willing to retire advice that’s become reflex. The buy-default served the field well for a long time. The unwillingness to revisit it serves the field poorly now.

So the build-versus-buy question isn’t really about software but about which capabilities the business must control, which it can safely consume, and who owns the consequences when that choice proves wrong. The old default protected organizations from one kind of risk. Leaving it unexamined now creates another.

The economics have shifted and the default shouldn’t survive unexamined. The better question is no longer whether responsible CIOs should build or buy but whether they know which business capabilities are too important to leave to a vendor’s operating model.