Why cheaper code isn’t always cheap

Tell me if you've heard this one before: "We can just build it ourselves now instead of buying it. Claude Code changes everything."

‍

I've been writing software for over 20 years. I've been an engineer, a CTO, and now, as Global Head of Solutions at Vanta, I spend my time helping technical companies navigate compliance and the increasingly agentic world. 

‍

And lately, I hear some version of that sentence in almost every conversation I have with founders.

‍

I get it. And honestly, I love it! When you can spin up a working prototype in an afternoon, the marginal cost of writing code feels like it's approaching zero. I felt something similar when Ruby on Rails arrived: Suddenly, you could prototype a web app in a weekend instead of a quarter, and the range of ideas worth attempting exploded. 

‍

But here's what I've learned from living through several of these waves, and what I’d remind founders during the latest AI wave, as well: The cost of writing code was never the bottleneck. The cost of owning it is.

‍

We've been here before

Each wave of "this changes everything"—shrink wrap, the web, Rails, mobile, now AI—has followed roughly the same arc. The barrier to building drops, the range of ideas explodes, and the people who win are the ones who direct that new energy toward something genuinely new rather than rebuilding what already exists.

‍

That's what worries me about our current inflection point and the instinct many have to rebuild what already exists. I don't want to see innovation stagger. I want founders to use AI to dream up things nobody has built yet, not to spend the next five years maintaining a tool that someone else already figured out.

‍

There's a metaphor I like: You can keep hammering at a rock until it splits, but wisdom is knowing which rock to hit. Right now, AI-written code is an effective hammer. The harder question—the one I don't hear enough people asking—is which rocks are actually worth breaking.

‍

The 90% cost reduction illusion

AI coding tools are genuinely impressive. Controlled studies and enterprise experiments report roughly 20% to 55% faster task completion on isolated coding tasks, and Anthropic's internal benchmarks show Claude Code completing complex features increasingly autonomously.

‍

But this fixation on coding speed glosses over something every engineer who's shipped production software knows in their bones—and what Barry Boehm established in Software Engineering Economics decades ago: Initial development accounts for only 20% to 30% of total software lifecycle cost.

‍

The remaining 70% to 80% is maintenance, operations, security patches, compliance updates, and the slow grind of keeping something alive in production.

Do the math: If AI reduces your coding time by 50%, and coding represents 20% of your total cost, you've saved roughly 10% of the actual bill. Not 50%. Not 90%. Just 10%. The "90% cost reduction" that makes for great demos applies to a small fraction of your real expenditure.

‍

The total cost of ownership, honestly

So what happens when a company actually acts on that logic and decides to build an internal platform with AI tools like Claude Code instead of purchasing one? My team modeled a GRC platform "build versus buy" scenario for a Series C or D company. 

‍

Here's how it broke down:

‍

‍*Note: These figures are illustrative estimates based on internal modeling and are not derived from published market research.

‍

Even with AI cutting initial development time by 40% to 60%, the five-year total cost of ownership for building remains 3–6 times higher than buying today. 

‍

Plus, this table is generous to the build side. It doesn't account for risks that rarely show up in planning spreadsheets. BCG finds that more than two-thirds of large-scale technology programs miss their targets on time, budget, or scope. Developer turnover creates catastrophic knowledge loss on custom codebases. And McKinsey estimates that technical debt consumes 20% to 40% of the value of an organization's entire technology estate.

‍

Then there's security. A 2024 analysis by Veracode found that nearly half of AI-generated code contained security vulnerabilities in tests, and an NYU study documented that 40% of Copilot-generated code contained security vulnerabilities in tested scenarios. AI is a powerful tool, but it still needs human oversight, especially when what you're building touches sensitive data or regulated workflows. That risk doesn't disappear when the code ships. It becomes part of the ownership burden.

‍

Let vendors maintain point solutions to keep your engineers on-task

C.K. Prahalad and Gary Hamel argued definitively in their 1990 HBR paper, "The Core Competence of the Corporation," that companies should relentlessly focus resources on activities central to competitive advantage and externalize everything else. The insight wasn't about cost. It was about attention.

‍

I think about this through what I call "compounding distraction costs." Every month your team spends maintaining an internal compliance tool is a month your competitors—who bought a purpose-built platform—are shipping features to customers instead. Gartner research estimates that the average organization spends 60% to 80% of its IT budget on maintenance and operations, leaving only 20% for strategic initiatives. Building non-core tools accelerates that ratio in the wrong direction.

‍

Plus, consider this: AI builds what it interprets you asked for, not always what you meant—and closing that gap requires real human oversight. We've already seen what happens without it: agentic coding tools have deleted production databases because they "misunderstood" the developer's instructions. 

‍

That iteration doesn't disappear just because the code got cheaper to generate. And even as AI improves, one thing won't change: Your engineers' attention is finite. Every hour they spend steering AI is an hour they're not spending on the product that differentiates you. The cost of ownership isn't just dollars. It's focus.

‍

There's also a market efficiency argument. Oliver Williamson's Nobel Prize-winning work on transaction cost economics shows that markets can aggregate demand in ways no single team can replicate. A purpose-built vendor serving hundreds of customers develops regulatory expertise, battle-tested integrations, and pattern-matching at a scale your internal team simply won't reach, no matter how talented they are.

‍

Consider Vanta. What Christina Cacioppo built is a highly specialized platform so that every other company doesn't have to. Her core insight: Compliance isn't your company's core competence (unless you're Vanta). It's a requirement. There's a meaningful difference.

‍

The discipline to know what not to build

I've lived through enough technology waves to know how this one ends. The shrink-wrap era didn't eliminate workers, it rewarded those paying attention. Rails didn't kill professional software engineering, it expanded who got to participate. AI won't hollow out engineering teams. It'll free them to do more interesting things, if they let it.

‍

The best leaders I've worked with have one thing in common: They know what not to build.

‍

They understand that cheaper code doesn't change the strategic calculus. It just makes it easier to make the wrong decision faster. If your company's core competence is compliance automation, build it. That's what Vanta did.

‍

But if your core competence is something else—healthcare, finance, logistics, or any of the thousand other domains where software is eating the world—buy the compliance platform, get your engineers back to the work only they can do, and go build something nobody has thought of yet.