For nearly twenty years, CIOs have been given remarkably consistent advice.
Don't build. Buy.
Unless you're a software company, purchase the SaaS platform, integrate it into your technology stack, and reserve your engineering talent for the few areas where custom development is genuinely unavoidable.
For a long time, that was exactly the right advice.
It protected organisations from fragile bespoke applications, undocumented dependencies, runaway maintenance costs, and the inevitable moment when the one developer who understood the system handed in their resignation.
It reduced operational risk.
It increased standardisation.
It allowed IT teams to spend less time maintaining software and more time enabling the business.
The problem is that good advice has an expiry date.
And I think we've reached it.
I'm not suggesting CIOs should suddenly start building everything themselves. Quite the opposite.
What I'm suggesting is that "buy" should no longer be the automatic answer simply because it has been for the last two decades.
The economics have changed.
The technology has changed.
More importantly, the business consequences have changed.
The organisations that fail to revisit this assumption risk standardising away the very things that make them different.
The Default That Became Doctrine
Every generation of technology leaders inherits assumptions from the previous one.
Some remain useful.
Others quietly become dogma.
Build versus buy is one of them.
For years the equation was obvious.
Buying commercial software was cheaper than building it.
Commercial software was usually more secure.
It was better documented.
It received regular updates.
Support was someone else's problem.
Meanwhile, custom software came with a familiar list of headaches:
- undocumented code
- technical debt
- maintenance costs
- scalability concerns
- security vulnerabilities
- dependency on a handful of developers
The CIO who said "no" to bespoke development was often doing exactly what the business needed.
They weren't blocking innovation.
They were preventing tomorrow's operational disaster.
The scar tissue was real.
Many of us inherited systems that nobody fully understood.
Applications that had become so business-critical they couldn't be retired, yet so poorly documented nobody dared touch them.
Entire business processes resting on code written by someone who left five years earlier.
The default to buy didn't emerge because CIOs lacked imagination.
It emerged because they'd seen what happened when bespoke software went wrong.
That instinct served the profession well.
But instincts can outlive the conditions that created them.
Three Things Have Changed
The conversation isn't changing because vendors have become worse.
It's changing because building software has become dramatically easier.
Three shifts have fundamentally altered the economics.
Each is significant on its own.
Together, they completely change the equation.
1. Building Software No Longer Costs What It Used To
This is probably the most obvious change.
AI-assisted development has compressed delivery times in ways that would have seemed unrealistic only a few years ago.
Projects that previously required months of planning, procurement, development and testing can now reach a working prototype in days.
Sometimes hours.
I've watched capable people produce functioning internal applications over a weekend that would previously have justified six-figure consulting engagements.
That doesn't mean the software is production ready.
It doesn't mean it's secure.
It doesn't mean it's maintainable.
But it does mean something important.
The cost of exploring an idea has collapsed.
Historically, organisations avoided bespoke development because the initial investment was simply too high.
Today that investment has reduced so dramatically that entirely new categories of internal software suddenly become economically viable.
The question is no longer:
"Can we afford to build this?"
Increasingly it's becoming:
"Can we afford not to?"
2. The People Building Software Have Changed
The second shift is even more disruptive.
Building software is no longer the exclusive domain of professional software engineers.
For years we've spoken about citizen developers almost as though they were an interesting experiment.
They're no longer an experiment.
They're reality.
Operations managers.
Finance teams.
Marketing departments.
Supply chain specialists.
HR professionals.
Increasingly they're using AI-assisted development tools to solve their own problems.
Some of those solutions are terrible.
Some are genuinely excellent.
But whether IT approves or not has become almost irrelevant.
The important point isn't whether citizen development is good or bad.
It's that it exists.
And it's growing.
The CIO who still assumes every internal application begins with an IT project request is operating against a version of the organisation that no longer exists.
The build decision hasn't disappeared.
It has simply moved.
3. Infrastructure Has Become Someone Else's Problem
Historically, building software meant building everything.
Authentication.
Authorisation.
Databases.
Backup.
Scalability.
High availability.
Monitoring.
Logging.
Disaster recovery.
Documentation.
Deployment pipelines.
Every one of those capabilities represented months of engineering effort.
Today many of them can be consumed as managed services.
Authentication can be outsourced.
Storage can be provisioned in minutes.
Monitoring arrives as part of the platform.
Documentation can be generated alongside the code.
Deployment pipelines can be created automatically.
Entire engineering disciplines have become platform features.
That doesn't eliminate complexity.
It changes where complexity lives.
The question has shifted from:
"Can we build this?"
to
"Can we govern what gets built?"
Those are fundamentally different questions.
Where Buying Still Wins
None of this means organisations should suddenly start writing their own ERP.
Or replacing Microsoft 365.
Or building payroll systems from scratch.
That would be absurd.
Commodity capability remains commodity capability.
Accounting.
Payroll.
Identity management.
Calendaring.
Email.
Document management.
These are solved problems.
The SaaS market is mature.
Competition is fierce.
Products are reliable.
The cost of ownership is predictable.
Buying still wins.
Comfortably.
And I suspect it always will.
When I hear someone suggest building their own HR platform, my first instinct is still to ask why.
Usually, the honest answer is because they underestimate what they're trying to replace.
That hasn't changed.
Where Buying Quietly Starts Losing
The conversation becomes much more interesting when the workflow itself differentiates the business.
These aren't commodity processes.
They're the activities that genuinely influence how an organisation competes.
Customer onboarding.
Manufacturing optimisation.
Pricing logic.
Supply chain intelligence.
Engineering workflows.
Decision support.
Operational visibility.
These processes are rarely identical between competitors.
Yet organisations frequently buy software that forces them into identical ways of working.
That compromise made sense when bespoke software was prohibitively expensive.
Today the compromise deserves re-examining.
Because every time an organisation changes its operating model to fit the software, it gives away a little of the differentiation that made it unique in the first place.
That's rarely visible in a quarterly budget.
It's very visible over a decade.
And that's where I believe many CIOs should be asking harder questions.
The CIO's Real Job Is Changing
This is where I think many organisations are still thinking with yesterday's assumptions.
The build-versus-buy discussion is often treated as though it's a technology decision.
It isn't.
It's a business decision with technology consequences.
The question shouldn't be:
"Can IT build this?"
The question should be:
"Should this capability belong to us?"
That's a fundamentally different conversation.
If a workflow defines how your organisation competes, then outsourcing that workflow to a vendor isn't simply buying software.
It's outsourcing part of your operating model.
Sometimes that's exactly the right decision.
Sometimes it's a strategic mistake.
The CIO's role isn't to automatically favour either option.
It's to understand where that line sits.
Accountability Must Sit With The Business
One of the biggest mistakes organisations make is quietly delegating build-versus-buy decisions to IT.
That made sense when every software project was, by definition, an IT project.
It doesn't make sense anymore.
If a workflow determines how Sales operates...
...Sales should own the outcome.
If it determines how Manufacturing differentiates itself...
...Manufacturing should own the outcome.
If it defines how Customer Service creates competitive advantage...
...Customer Service should own the outcome.
The CIO should absolutely own the architecture.
The CIO should own integration.
The CIO should own security.
The CIO should own governance.
But the business should own the value.
Otherwise every build-versus-buy discussion becomes another technical debate where nobody owns the commercial consequences.
That rarely ends well.
The Risks Haven't Disappeared
This isn't an argument for building software without discipline.
Far from it.
Many of the reasons organisations adopted SaaS remain entirely valid.
AI still produces poor code.
Security vulnerabilities still exist.
Technical debt still accumulates.
Documentation still gets ignored.
Developers still leave.
Citizen developers still create applications that work brilliantly...
...right up until the point they become business critical.
Then everyone suddenly discovers nobody understands how they work.
I've inherited systems like that.
Most CIOs have.
The difference today isn't that these risks have disappeared.
It's that they sit in a different place.
Twenty years ago they were reasons not to begin.
Today they're engineering problems that need solving if you decide to proceed.
That's a subtle but important shift.
The conversation has moved from:
"Don't build."
to
"If we build, how do we govern it properly?"
Those are completely different leadership conversations.
Citizen Development Is No Longer Optional
This is perhaps the biggest mindset change of all.
Some organisations still believe they can prevent citizen development.
I don't think they can.
Business users now have access to AI tools capable of producing surprisingly sophisticated applications.
Some are terrible.
Some are genuinely useful.
Either way, they'll continue being built.
The CIO has two choices.
Pretend it isn't happening.
Or create the guardrails that allow it to happen safely.
Personally, I think the second option is the only realistic one.
The organisations that succeed won't be those that ban citizen development.
They'll be the ones that govern it intelligently.
Architecture Comes Back To Centre Stage
For years, enterprise architecture developed an unfortunate reputation.
Too often it became synonymous with governance meetings, PowerPoint diagrams, and documents nobody read.
That's a shame.
Because architecture is becoming one of the CIO's most valuable disciplines again.
The CIO's role is returning to what it arguably should always have been:
Designing how capabilities fit together.
Not simply deciding which products to buy.
Talent Strategy Needs To Catch Up
The traditional technology organisation assumed clear boundaries.
Those boundaries are fading.
Today's operations specialist might also write Python.
A finance analyst may build internal automation.
A network engineer may spend as much time using APIs as configuring routers.
The CIO who continues hiring against yesterday's role descriptions may struggle to build tomorrow's organisation.
The Default That Now Needs Challenging
Perhaps the most important thing this article asks is surprisingly simple.
Be willing to revisit advice that once served you well.
The buy-default wasn't wrong.
It was exactly what many organisations needed.
But today's conditions aren't yesterday's conditions.
Technology has changed.
Economics have changed.
Labour markets have changed.
Business expectations have changed.
AI has accelerated all of them.
The organisations that continue treating build-versus-buy as a settled discussion may discover they're optimising for yesterday's constraints instead of tomorrow's opportunities.
Final Thoughts
This article isn't an argument for building everything.
Nor is it an argument against SaaS.
It's an argument against intellectual autopilot.
The best CIOs I've worked with rarely fall into absolutes.
They don't believe everything should be bought.
They don't believe everything should be built.
They ask a different question.
Which capabilities genuinely differentiate the business?
Those are the ones worth protecting.
Those are the ones worth owning.
Everything else is simply implementation.
The economics have shifted.
The technology has shifted.
Perhaps it's time our assumptions shifted too.
Because the real build-versus-buy decision was never about software.
It was always about deciding which parts of your business are too important to leave to someone else's operating model.
And in 2026, that's a question every CIO should be asking again.
