The Build Got Cheap. The Bill Did Not.

AI has collapsed the cost of building software — and quietly moved the expensive part to somewhere no one is looking on the P&L.

There was a saying, back in the old days, that captured the entire psychology of enterprise technology in eight words: nobody ever got fired for buying IBM.

It was never really about IBM. It was about safety — the quiet wisdom that, when the stakes are high and the blame would be personal, you choose the option no one can second-guess. The big, the established, the expensive, the defensible. If it worked, you were sensible. If it failed — well, it was IBM; what more could anyone have asked of you?

The saying still stands. It has only changed its name. Today nobody gets fired for buying Microsoft, for standardising on AWS, or for choosing Salesforce, SAP, ServiceNow, Workday or Oracle. The logic is identical, and it is not foolish. For the commodity plumbing of a business — the systems of record that simply have to work — the safe, boring, market-leading choice is very often the right one. You do not want to be the executive who commissioned a bespoke payroll engine and then watched it fail an audit.

But two things are quietly pulling at the old certainty.

The first is that the safe buy is no longer quite so safe. The rent rises. The contract locks you in. Your data accumulates inside someone else’s walls. And — newest of all — the vendor you bought for safety is increasingly the same company racing to climb the stack toward the very capabilities that make you different. Safe was never the same as free, and it was never the same as yours.

The second is more seductive, and it is the one that gets technologists into trouble. If buying is safe and building was always expensive, the gap between the two was filled with compromise — generic software bent awkwardly around a business it did not quite fit. But what if you could simply build the small, niche thing that fills the gap, exactly to your needs, and maintain it, quietly, forever?

Forever. There it is — the most expensive word in software, and the one nobody ever writes on the P&L.

Because here is what has genuinely changed, and changed fast. Software has become astonishingly cheap to build. AI writes the code, scaffolds the system, fills in the boilerplate, and does in an afternoon what used to consume a sprint. By early 2026, more than 80% of developers were using AI coding tools, and at Google and Microsoft AI was already writing over a fifth of new code. The cost of creation has genuinely fallen, and the temptation — for the gap-filler and the safe-buyer alike — is to read that as an unambiguous gift.

And every CTO is now living the consequence — because somewhere across the building, a perfectly reasonable question is being asked: if it is all so cheap now, why does everything still cost so much, and why does anything still take so long?

That question is the conundrum, and it sits squarely on the line between the CEO who owns the P&L and the CTO who has to answer for it. The answer is uncomfortable, and it is the thing this piece is about.

The build got cheap. The bill did not. It simply moved — to several line items most organisations are not yet looking at, and to that one quiet, ruinous word: forever.

The Cost Did Not Disappear. It Relocated.

Here is the part the headline number obscures. Building was never the expensive part of software.

Owning it was. Maintaining it. Understanding it well enough to change it safely. Keeping it secure, current, and coherent as the world it serves keeps moving. The numbers on this have been stable and well-documented for decades, long before AI: the initial build is the small fraction. Across the industry, maintenance and change consume somewhere between half and four-fifths of a system’s total lifetime cost — higher still, 70–90%, for complex enterprise estates in regulated sectors. A widely used rule of thumb puts annual maintenance at 15–25% of the original build cost, every year, for as long as the system lives. The Standish Group’s long-standing finding is that changes made after launch typically cost three to four times the original development. The build was always the down payment. Maintenance was always the mortgage.

AI has made that down payment smaller still. What it has not done — what it arguably cannot do — is lower the cost of the mortgage. If anything, the early evidence is that it raises it.

Because we can now generate code at a speed and volume that no team can fully read, let alone comprehend. One 2026 analysis of enterprise data found that around 61% of organisational code was already AI-generated or AI-assisted — and that 70% of teams now considered maintaining the test suite a heavier burden than writing the code itself. The tooling vendor Sonar put it about as bluntly as it can be put: we are producing code at a volume that has outpaced our ability to understand it.

The cheap part got cheaper. The expensive part got harder. And the gap between them is where the new risk lives.

A system you do not understand is not an asset. It is a liability with a nice user interface. And an organisation that mistakes a low build cost for a low total cost is simply choosing not to look at the bill until it arrives.

The People Line Nobody Wants to Say Out Loud

There is a second cost that moved, and it is the largest controllable line on any technology organisation’s P&L: people.

The seductive read is that cheaper building means a smaller wage bill — fewer engineers, lower cost, fatter margin. The reality emerging from the data is subtler, and more important. The cost is not vanishing. It is repricing — moving from the people who write code to the fewer, more senior people who direct, review, and comprehend it.

The numbers are already stark. Entry-level engineering postings are down roughly 28–40% from their 2022 peak and have not recovered. Employment for developers aged 22 to 25 fell about 20% from its late-2022 peak, even as employment for engineers over 30 in the most AI-exposed roles grew. The talent pyramid is being compressed from the bottom, not eliminated. And the work itself is shifting: a study of Copilot adoption found that senior engineers reviewed about 6.5% more code and saw a 19% drop in their own original output after the tool arrived — because AI moves work from generation to review, and reviewers are the most expensive engineers on the team. Gartner expects that by the end of 2026, around 75% of developers will spend more time orchestrating and architecting than writing code by hand.

So the honest version of the P&L story is not “we need fewer people.” It is “we are paying a different, scarcer, more expensive kind of person to do a different job” — judgement, review, architecture, comprehension — while the cheap, junior, code-producing layer thins out. That carries a sting in the tail the spreadsheet does not show: if no one hires and trains juniors, the supply of the very seniors this model depends on quietly dries up. As one AWS executive put it, stopping junior hiring to save money is one of the dumbest things you can do — you are eating your own future.

The Black-Box Paradox

There is a genuine irony at the heart of this, and it is worth sitting with, because it is also where the opportunity hides.

AI is the great manufacturer of new black boxes. Hand it a vague prompt and it will return something that works, that you did not design, do not fully understand, and cannot confidently change. And it does so at a measurable cost to quality: independent analyses in 2025 and 2026 found AI-generated code produced somewhere between 1.7 and 2.7 times more issues than human-written code, with studies flagging a high share for security vulnerabilities and a marked rise in duplicated code — all of which is maintenance debt by another name. Google’s DORA research, even as it confirmed near-universal AI adoption, found AI use carried a negative relationship with software delivery stability. Technical debt used to accrue slowly, one shortcut at a time. It can now be generated industrially.

And yet the same tool that builds the black box is the first tool in history that can reliably open one.

Point AI at a thirty-year-old mass of undocumented legacy — the COBOL nobody dares touch, the integration layer whose author left in 2009 — and it can read it, explain it, map it, document it, and propose how to untangle it. The thing that makes new systems opaque is also the thing that can make old systems legible at last. For the large enterprise sitting on decades of accumulated black boxes, this is the most significant transformation lever to appear in a generation.

So AI is simultaneously the cause of tomorrow’s technical debt and the cure for yesterday’s. Which one it turns out to be, in your organisation, is not a property of the technology. It is a choice about how you use it.

What Is Your Business, and What Merely Runs It

To make that choice well, you need a map — and the most useful one is older than AI and survives it intact. It is the simple, ruthless distinction between the software that is your business and the software that merely runs it.

Some systems are the business. The customer-facing experience, the thing that gets the actual work done, the part your customers touch and judge you by, the capability no competitor has in quite the same shape. This is where differentiation lives. This is the front of house, and it is, in the truest sense, you.

Other systems are essential but generic. The CRM. The ERP. Payroll, finance, the back-office machinery every company of your size runs in more or less the same way. None of it differentiates you. All of it must work. This is the plumbing — indispensable, and yet utterly interchangeable.

The old wisdom about this map is sound, and AI does not overturn it: build the part that is your business; buy the part that merely runs it. Pour your scarce, expensive, differentiating effort into the front of house, and rent the commodity plumbing from someone whose entire business is keeping it running. Building your own ERP to compete on payroll is a way of spending differentiation you do not have on a battle no customer will ever reward.

What AI changes is not the principle. It is where the lines fall.

AI Moves the Line — On Both Sides

For thirty years, build-versus-buy was a binary, and the binary was decided largely by cost. Building was expensive, so the bar for “build” was high; anything below it, you bought off the shelf.

Now the cost of building has fallen, and the line moves in two directions at once.

On the build side, the territory expands. Things that were once too costly to build bespoke — too marginal to justify a custom team — are suddenly viable. Capabilities you would have compromised on with generic software you can now afford to build exactly as your business needs them.

On the buy side, the calculus shifts underneath you. AI makes it newly cheap to build a thin, bespoke layer over commodity foundations — to wrap, extend, or even quietly replace the SaaS you have rented for years. The question is no longer simply build or buy. A third option has opened in the middle: compose — assemble something that is mostly bought, partly built, and specifically yours, at a cost that used to be impossible. It is telling that even the chief executives of low-code platforms now describe the future developer as a “composer” of agents and workflows rather than a writer of code.

So the binary becomes a spectrum. Rent the pure commodity. Compose the things that sit between commodity and differentiation. Build — and own outright — the things that are genuinely your business.

But the buy side hides its own trap, and it is sharper now than ever. The commodity vendor you rent from is increasingly the same company racing to capture the value you are trying to compose around — bolting AI onto their product to climb up the stack toward your differentiation. And the deeper you compose around a platform, the more your data gravity and integration depth harden into lock-in. The “compose” option is powerful precisely because it sits over someone else’s foundation; the discipline is to compose over commodity you could leave, and never to let convenience quietly mortgage the part that is actually your business.

The Scaling Trap: What Is Cheap to Build Is Expensive to Own

This is where small and large companies meet the same wall from opposite sides.

A small company has a glorious advantage: no legacy, no accumulated black boxes, and a build cost that has never been lower. It can move at a speed that would have been unthinkable a few years ago. The danger is invisible at that size. Building fast with AI, and never pausing to keep the result legible, quietly manufactures the very black boxes that will calcify into next year’s debt — and there is a newer hazard, too. When everyone can build, you do not just get black boxes; you get sprawl: shadow systems, half-finished internal tools nobody owns, a proliferation of cheaply-built software that is itself a governance cost. Cheap to make is not the same as free to govern.

A large company arrives from the other direction. It has the legacy, the debt, the COTS contracts measured in years, the estate no one fully understands. For it, the AI question is whether to keep paying the rising rent on inflexible commodity systems, or to use AI to untangle and rebuild — cheaper to build than ever, but dangerous to own if rebuilt without discipline.

What is cheap to build at small scale becomes expensive to own at large scale — unless it was built to be understood and changed.

The scaling trap, stated plainly: speed without legibility is a loan. It feels free at five people and comes due at five hundred. The companies that scale well are not the ones that built the fastest. They are the ones that built fast and kept what they built comprehensible.

The Hundred-Million-Dollar Argument for Building in Change

There is a number that ought to focus the mind of any CEO weighing this, and it is the cost of getting it wrong at the other extreme — the big-bang transformation.

When organisations let change accumulate instead of doing it continuously, the bill does not merely grow; it compounds into the single most dangerous category of spend in enterprise technology. The landmark McKinsey and University of Oxford study of more than 5,400 large IT projects found that, on average, they ran 45% over budget, came in 7% over schedule, and delivered 56% less value than predicted. Worse, 17% of them went so badly they threatened the very existence of the company. These are not edge cases. This is the average large transformation.

And at enterprise scale, “large” means exactly the figure you would fear. The roll-call of nine- and ten-figure failures is long and well-documented: Hershey’s $112m ERP programme that froze before Halloween and stranded $100m of orders; Lidl abandoning a seven-year SAP effort after €580m; Revlon, Nike, Waste Management, MillerCoors, National Grid, Leaseplan, Birmingham City Council’s Oracle rollout climbing past £100m, Quebec’s public-sector transformation overrunning by half a billion. A hundred million dollars is not the worst case for a big-bang enterprise transformation. It is a fairly ordinary one.

Here is the connection that matters, and it is the whole argument for the new paradigm rendered in hard currency. Big-bang transformations are what you are forced into when you did not build for change. They are the bill for years of deferred adaptability arriving all at once — the accumulated cost of systems that were built to be finished rather than built to evolve, allowed to calcify until the only option left was to rip everything out and start again, betting the company on a single multi-year programme with a coin-flip’s chance of delivering its business case.

Building in change is not a luxury or an engineering nicety. It is the cheapest insurance policy a large enterprise can buy against precisely this catastrophe. A system that can evolve continuously never has to be transformed catastrophically. You pay a modest, ongoing premium — the discipline of legibility, the cost of keeping things changeable — and in return you never have to write the hundred-million-dollar cheque, never bet the business on a big-bang go-live, never become the case study. The continuous cost of staying current is almost always smaller than the discontinuous cost of being dragged, late and all at once, into a present you can no longer avoid.

That is the P&L case, stated as plainly as it can be: the cost of change, paid continuously, is the thing that saves you from the cost of transformation, paid catastrophically.

How Do You Actually Measure “Cost to Change”?

If the number that now matters is the cost of change rather than the cost of the build, then it has to be measurable, or it is just a slogan. Happily, it already is — and the industry has spent a decade refining the instruments.

The clearest are the DORA metrics, which measure delivery as a flow rather than a build: lead time for change (how long from a change being requested to it running safely in production), deployment frequency (how often you can safely ship), change-failure rate (how often a change breaks something), and time to restore (how fast you recover when it does). Read together, these are a direct readout of how expensive change is in your organisation — and they are exactly the metrics on which the research finds AI-accelerated teams quietly regressing on stability even as raw output rises. To those, add a measure of cognitive load — how much of the system any one person can actually hold in their head — because that is the leading indicator of whether the next change will be cheap or agonising.

The practical instruction for a CEO and CTO is simple: stop reporting only on what was built, and start reporting on how cheaply and safely the organisation can change what exists. The first number flatters you. The second one tells the truth.

The Counter-Case, Honestly

It would be too neat to claim the mortgage only ever gets more expensive. The same AI that manufactures debt is genuinely beginning to service it. It can write the documentation no one ever wrote, generate and maintain the tests that catch regressions, explain unfamiliar code to whoever has to change it next, and take on the tedious, continuous upkeep — dependency upgrades, patching, routine refactoring — that makes maintenance so costly. In principle, AI lowers not just the cost of the deposit but some of the cost of the mortgage too.

The honest position is that this is real but unproven at scale, and conditional. The ownership cost falls only for organisations disciplined enough to insist on legibility — to use AI to keep systems understood rather than merely to produce more of them. For everyone else, the same tool simply manufactures debt faster than it services it. The technology is genuinely double-edged; which edge you get is determined almost entirely by the discipline you bring, not the model you buy.

The Paradigm That Is Emerging

So, is there a new model? I think there is, and it is a quiet inversion of how we have thought about software economics for forty years.

The old paradigm treated software as a capital project. You scoped it, budgeted it, built it, and booked it as an asset — a thing that was, at some point, done. The P&L question was “what will it cost to build?”

The emerging paradigm treats software as a living position. In a world of continuous change, nothing is ever done; it is only current, and only for now. The cost that matters is not the build — that is cheap, and getting cheaper — but the perpetual cost of keeping the thing alive, understood, and able to change as fast as the world around it. The P&L question becomes “what will it cost to change?”

And once you ask that question, everything reorganises around it. When building is cheap, the code is no longer the moat — anyone can now generate code. What cannot be commoditised is comprehension: understanding your own domain deeply enough to direct the building, owning the data and the domain model that the building merely expresses, and keeping the whole system legible enough to change at speed. The durable advantage moves from who can build it to who understands it and can change it fastest.

This is the same law every other piece in this series has circled, arriving now through the ledger. In a world of continuous change, the asset was never the artefact. It is the ability to keep changing the artefact. Heroes do not scale; systems do. Target states do not survive; adaptability does. And now: builds do not endure; the capacity to rebuild does.

What a CEO and CTO Should Actually Do

This is not a counsel of despair. It is a short, practical reorientation.

Redraw the map, honestly. Sort your estate into three: what is genuinely your business (build and own), what is pure commodity (rent), and what now sits in the new middle (compose, but over foundations you could leave). Most organisations are over-building commodity and under-investing in their actual differentiation.

Budget for change, not just for build, and measure it. Put cost of ownership and cost of change on the P&L as first-class line items, instrumented with lead time, change-failure rate, and the rest. A system’s build cost is now the least interesting number about it. And treat the small, continuous premium of staying changeable as what it is: insurance against the hundred-million-dollar big-bang transformation you are otherwise quietly saving up for.

Treat comprehension as an asset and defend it. Do not let cheap building become a licence to manufacture black boxes or sprawl. Insist that what you build stays legible — documented, tested, governed by automated checks that fail when the system drifts. Buy the speed of AI; refuse the opacity.

Reprice the team, do not just cut it. The shift is from many code-writers to fewer, senior code-directors — but keep hiring and training the juniors who become tomorrow’s seniors, or you will win this year’s margin and lose the next decade’s capability.

Own your data and your domain. When code is commodity, these are the moat. Rent the plumbing; never rent the understanding of your own business.

You No Longer Budget to Build a System

So here is the shift to carry out of all of this, for the CEO and the CTO who have to navigate it together.

The cheapness of building is real, and it is a gift — but it is a gift that relocates the cost rather than removing it. The money and the risk have moved downstream, from the act of creation to the act of living with what you created. The organisations that thrive will be the ones that stop budgeting for a build that ends and start budgeting for a system that has to keep changing for as long as the business exists.

You no longer budget to build a system.

You budget to keep one alive.

And in the age of AI, that — not the cost of the build — is the number that will decide whether you stay agile, or simply accumulate, faster and more cheaply than ever before, the very things that hold you still.