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 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 , 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 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.