AI is making software cheap to build. Is your organization ready for what comes next?

What happens once building software stops being expensive? That’s the question at the center of this piece, and I think it’s about to matter for every CIO/CTO managing an enterprise technology budget.

For decades, that expense has quietly shaped how enterprises operate. When custom development takes months and a full team, companies buy SaaS products instead. When engineering capacity is limited, CIOs/CTOs prioritize a backlog. When a business unit wants a new application, it competes with everyone else for budget and developer time. Enterprise IT’s whole structure exists partly because software has always been hard to make.

A recent example from Perplexity convinced me that assumption is starting to break down faster than most of us expected, and it’s worth walking through in some detail before getting to what it means for the rest of us.

The buy versus build math is shifting

Perplexity has disclosed that two engineers, working with hundreds of AI coding agents, built a custom database called CobbleDB in roughly two months. This was not a prototype. CobbleDB is a roughly 40,000-line Rust key-value store that now handles part of Perplexity’s production search traffic, built to replace some DynamoDB reads after the company decided it wanted more control over latency and cost.

The numbers are hard to ignore. According to reporting by The New Stack, Perplexity cut its median read latency by more than 80% and expects to save at least 20% on cost compared with DynamoDB, though the comparison wasn’t a controlled benchmark and the savings estimate leaves out the cost of maintaining a custom database. Even with those caveats, two engineers built a substantial piece of infrastructure in eight weeks, and this isn’t a story about one company’s database.

This is already playing out at a smaller scale. Payhawk CEO Hristo Borisov described replacing a commercial performance-management product costing $70,000 a year with software his company built itself using AI-assisted development. Microsoft is pushing the same idea into the broader workforce with its 365 Copilot App Builder, which lets an employee describe an application in plain language and get a working version in minutes.

The same shift is happening at the opposite end of the size spectrum too. Starbucks is reportedly building AI-developed replacements for a Microsoft system that tracks inventory and an IBM platform that manages maintenance, according to a Bloomberg report cited by Fortune. The coffee chain spends roughly $400 million a year on software, and CTO Anand Varadarajan has told employees there are “clear opportunities to reduce the spend in software.” Some of the internally built systems could launch by the end of 2027, pending testing. A specialized production database, a business user’s lightweight app and a Fortune 500 company’s attempt to displace two enterprise vendors at once look like different stories, but I think they are the same trend at different levels of complexity: creating software is getting cheaper, and that changes what enterprises can justify building themselves instead of buying.

AI does not remove the real costs of custom software. Someone still has to understand the business problem, design the architecture, validate the output, secure it and operate it. Perplexity kept its two engineers in control of CobbleDB’s architecture and production environment throughout, and that distinction matters: agents accelerated the work; they did not replace the judgment behind it.

Abundance creates a different problem than scarcity

Enterprise IT has spent decades managing a shortage of development capacity. There are always more requests than developers and more requirements than teams can deliver on schedule. Now picture that constraint loosening. A finance team builds its own reconciliation tool instead of filing a ticket. Sales generates an app that combines CRM data with account research. A developer asks an agent for a specialized utility instead of writing it by hand. None of these individual choices looks unreasonable, but together they add up to an enterprise software environment that looks nothing like the one most CIO/CTOs are managing for today. The organization may still have 500 applications in its official portfolio, and underneath that could sit thousands of generated tools, scripts and workflows that nobody centrally tracks.

From a risk and compliance standpoint, that gap is more than an untidy IT footprint. Most control environments assume software enters through a small number of known channels such as procurement, a formal development lifecycle or a change advisory board. Every control that matters (segregation of duties, access provisioning, periodic recertification) gets attached to software at one of those checkpoints. A tool generated by an employee in an afternoon skips all of them. It gets built, connected to whatever data it needs and put into use without ever crossing a point where someone was responsible for reviewing it. Control frameworks are built on the assumption that risk gets caught at intake. AI-generated software does not have an intake.

The exposure compounds because nobody owns the exit either. A reconciliation tool built for a six-month initiative does not get decommissioned on a schedule the way a vendor contract does or a system gets retired at end of life. It keeps running quietly, holding whatever access it was given on day one, with no control owner accountable for revisiting that access once the project that justified it has ended. Assigning a control owner and an expiration date at the moment someone decides to build would close that gap, and right now almost nobody does it.

There is a second, quieter shift happening alongside all of this. When creating a new tool is easier than finding out whether one already exists, people will default to creating one. I think that flips one of the oldest assumptions in software: creation is expensive and reuse is cheap. AI is making creation cheap while discovery and reuse stay exactly as hard as they have always been, and for a risk function that means the population of unreviewed software an organization is carrying grows faster than any control process built for the old economics can absorb.

CIO/CTOs should start preparing for abundance, not scarcity

Developers don’t disappear from this picture. If anything, the Perplexity example argues the opposite: when a system genuinely matters, experienced engineers still make the architectural calls, test the assumptions and take responsibility for what reaches production. What changes is how much software those same people can create and oversee at once, and that shifts the question CIO/CTOs need to be asking. It used to be whether a team could build something. Increasingly, it’s whether it should, whether the organization already has something like it, who owns it and what happens when the person who built it moves on. Those aren’t engineering questions. They’re portfolio and governance questions, and most organizations don’t have a clear owner for them yet.

There’s a pattern in how enterprises absorb this kind of shift. When storage got cheap, companies didn’t end up with fewer data problems; they accumulated far more data. When cloud infrastructure became easy to provision, the worry shifted from “can we get the compute” to “how do we control the sprawl and the cost.” Software is headed toward the same transition, and the CIO/CTOs who prepare for abundance now will have a real advantage over the ones still planning around scarcity.

Perplexity’s CobbleDB is interesting because of what the company built. It’s more interesting because of how few people it took to build it. If two engineers augmented by AI agents can produce a production database in eight weeks, it’s worth asking what the rest of the workforce, technical and nontechnical, will be able to create as these tools keep improving. That question belongs on the same agenda as budget, headcount and control ownership planning, not off to the side as a curiosity for the engineering team to sort out on its own.

Enterprise IT has spent decades getting faster at building software. That was never going to be the hard part. Knowing what you own, and when to retire it, is.