Building software is cheap now. Owning it isn’t.
Publishers and digital leaders have always had three choices when it comes to technology investment, whether the decision is a content management system, a subscription stack, or an internal tool. Gartner wrote the menu down back in 2011, but the menu is older than that: build, buy, or borrow.
Buy means renting someone else’s finished product, which today mostly means SaaS. Borrow means starting from open source, foundations like WordPress or Laravel that thousands of other people build, maintain, and patch, and adding your own layer on top. Build means writing it yourself, and owning what you write.
For most of the past two decades that decision had a natural brake built in: building was expensive. AI has released it. “Vibe coding”, having AI generate working software from plain-language prompts, has collapsed the time and cost of getting something built. What used to be a six-figure question can now be a working prototype by Friday. What hasn’t changed is everything that comes after the build. Whatever those tools produce, you own. The hosting, the patching, the moment it breaks in year three: all yours.
So this article is about the Build option, because it’s the one AI has changed, and it’s where we see the most expensive mistakes being made right now.
We’ve built software for publishers for over a decade, and most of what that decade taught us is when not to. The most expensive platforms we get asked to review are almost never the ones where someone bought the wrong SaaS. They’re the ones where someone built a layer that already existed.
And the economics underneath haven’t moved: custom code has never been an asset, it’s a liability you take on.
You don’t pay for software when you build it
Jeff Atwood put it plainly back in 2007: the best code is no code at all. Every line you ship is a line someone has to read, understand, debug, secure, and maintain for as long as it exists. The capability is the asset. The code is the cost of having it.
That cost doesn’t arrive when you build. It arrives every year afterwards, and it compounds. Dependencies age. Security holes get discovered in libraries you forgot you were using. The developer who understood the payment integration leaves. MIT Sloan made a related point about AI coding studies: the impressive productivity gains were measured on isolated tasks, not on software that has to live inside complex existing systems for years.
In our experience, the build is usually the cheapest part of owning software. The bill for everything else arrives later, and it keeps arriving.
What AI actually changed, and what it didn’t
The build side of the equation has genuinely collapsed. Retool surveyed 817 builders for its 2026 Build vs Buy report and found 35 per cent of teams have already replaced at least one SaaS tool with something custom-built, and 78 per cent expect to build more this year. Worth noting Retool sells a platform for building internal tools, so the survey has a barrow to push. But the direction matches what we see in client conversations every week: “what would it cost to build this ourselves?” now comes up at every SaaS renewal.
Be precise about where the collapse happened, though, because it isn’t everywhere. The entry cost fell through the floor: a standalone tool, a greenfield prototype, an internal dashboard now takes days instead of months. Complex systems are a different story. METR’s randomised trial from July 2025 found experienced developers believed AI tools made them about 20 per cent faster on mature codebases, while the measured result showed them 19 per cent slower. Building simple things got dramatically cheaper. Building serious things didn’t, or at least not yet.
And here’s the asymmetry underneath it all. AI collapsed the cost of writing code. It didn’t touch the cost of carrying it. The maintenance tail, the security obligations, the upgrade treadmill, the need for someone with judgement to own the thing: all of it costs what it cost in 2021. When creating code gets radically cheaper and owning it stays the same price, the share of your budget spent carrying code you never needed grows every year.
AI collapsed the cost of writing code. It didn’t touch the cost of carrying it.
There are two kinds of Build now
The decision that actually determines your total cost of ownership isn’t build versus buy, it’s where the building starts.
Build from scratch and every layer is yours. Your own CMS. Your own auth. Your own media pipeline, caching, search, feeds. You are accountable for 100 per cent of that footprint: every dependency, every vulnerability, every architectural decision an auditor will one day ask you to justify from first principles.
Build on established foundations, an open source platform like WordPress or a framework like Laravel, and the shape of ownership changes. You inherit patterns that have been argued over for twenty years, upgrade paths that exist, and a core that thousands of contributors maintain and millions of production deployments have battle-tested. You still own the layer you add. But you carry your layer, and the platform’s maintainers carry the core.
Security is where that gap compounds hardest. When a critical vulnerability lands in a bespoke stack, your team has to find it, understand it, patch it, test the patch, and deploy it, and that assumes you find it at all. When one lands in a mainstream platform’s core, it gets disclosed, patched upstream, and your job is to apply the update. That’s not zero exposure. You’re still accountable for the code you added and for staying current. But the surface you’re personally answerable for shrinks from everything to your additions, and when compliance reviews come around, most of your platform is something documented, widely deployed, and continuously scrutinised rather than something only your team has ever read.
And the clock on all of this is speeding up, because attackers are using AI too. Google’s M-Trends 2026 analysis found the mean time from vulnerability disclosure to exploitation has effectively gone negative, with exploitation now typically underway before a patch exists. Rapid7’s 2026 threat report recorded a 105 per cent year-on-year jump in exploited high-severity vulnerabilities, driven by AI-scaled reconnaissance compressing the gap between exposure and attack. In that environment, being the only team on earth responsible for finding the flaws in your stack gets worse every year. Foundations don’t make you safe. But they put thousands of eyes and an upstream patch pipeline between you and that shrinking window.
Here’s the AI-era problem: vibe coding makes building from scratch so fast that teams skip the question of whether they should own the layer at all. The prototype ships before anyone asks “doesn’t this already exist?” That’s not a tooling failure. It’s a decision failure. The build got cheap enough that nobody pauses at the checkout. The security risks of AI-generated code itself are a separate subject, and we’ve covered them elsewhere.
The publisher who built everything
A few years ago we were engaged to review the technology stack of a well-resourced publishing operation. Big engineering team. Serious budget. They had built almost everything themselves: a custom frontend framework, a microservices architecture, an enterprise integration layer between systems.
The review scored the platform against standard publishing capability on a one-to-five scale, where one meant a critical issue. Content publishing scored one. Technical SEO scored one. Page performance scored one. The critical failures weren’t in the ambitious parts of the architecture. They were the solved problems. The things any competent open source publishing stack does on day one, this platform did badly, because every one of them had been rebuilt from scratch by a team learning the domain as they went.
Meanwhile, the audience-facing products that could have made them genuinely different were starved of investment. Our review summarised it in one line: a disproportionate amount of time and money was being spent innovating on already-solved problems.
Nobody involved was stupid. The team was talented and the ambition was sincere. But when a technical vision is a vacuum, teams fill it themselves, and clever engineers left alone will default to building. That instinct predates AI. AI just removed the last brake on it, which was cost.
The decision is made layer by layer
You don’t choose build, buy, or borrow once per product. You choose per layer.
Take a replatform we delivered for a large publisher with a transactional product attached to its content business. The publishing layer was borrowed: open source WordPress, which meant the editorial workflow, content APIs, and distribution were solved problems from day one. The transactional platform was built, because that product WAS the differentiation and no off-the-shelf option existed. The hosting was bought as a managed platform rather than assembled from raw infrastructure. One product. Three different answers. The project principle we wrote at the time still holds: borrow before rebuilding, and design only what’s missing or vital.
For a publisher, the line is not hard to find. Your editorial workflow, your audience relationships, your monetisation logic: that’s you. Your CMS core, your auth, your media handling, your feeds: solved layers, some of them solved for twenty years.
To be clear, borrowing has an ownership tail too. You still carry the layer you add on top, and keeping a serious open source platform current is real work (work businesses like mine get paid to do, so weigh that as you see fit). But you stop carrying the foundations, and the foundations are where the volume is.
The test before you build anything
The genuine case for building more than you used to does exist, and it’s worth conceding properly. Vendor risk is real. SaaS consolidation, mid-contract repricing, and sunset features have made owning your differentiating capability more attractive, not less. If something is the reason customers choose you, owning it beats renting it, and AI has made that ownership cheaper to establish.
But that argument covers your edge, and only your edge. For everything else, the questions to ask before anyone opens an editor:
Does this layer already exist well? Open source counts as solved. So does a mature SaaS category.
Is this part of why customers choose us? If the honest answer is no, you’re about to build a solved problem.
What does owning 100 per cent of this footprint cost in year three? Not the build quote. The patching, the audits, the person who has to understand it after the person who built it leaves.
Who with real judgement is accountable for it? Not “who prompted it into existence”. Who answers for it in production, at 2am, in year four.
If the build cost were the smallest line item, would we still choose to own this? Because it now is.
Cheap to build is exactly why discipline matters
The old constraint on building software was money, and it did a lot of quiet good. It forced prioritisation. It made “should we own this?” a real question, because the answer cost six figures.
That constraint is gone. What’s left is judgement, and judgement doesn’t scale the way tokens do. The publishers who come out of this era ahead won’t be the ones who built the most. They’ll be the ones who owned the least code per unit of differentiation: foundations borrowed, commodities bought, and every line of owned code pulling its weight as an actual advantage.
Building software is cheap now. Owning it isn’t. Never build a layer that already exists well.
The Code Company has been advising publishers and brands that are facing these challenges introduced by the rise of AI-first engineering. Get in touch if we can help.
