Technical debt is a CEO problem pretending to be a developer problem
TL;DR: Technical debt eats 20-40% of every technology estate (McKinsey) and constrains AI adoption for 81% of executives (IBM Institute for Business Value). It looks like an engineering problem, but it's solved at the CEO level — through budget, language, and prioritization decisions the engineering team can't make alone. The cost of delaying that decision compounds.
The most expensive technical debt I've ever seen wasn't in the code. It was in the gap between what the CTO knew and what the CEO would approve. I've spent 20+ years leading software development teams, and we've sat on both sides of that gap repeatedly — including nine years inside one US scaleup's growth curve. Every time, the cost of closing the gap late was higher than the cost of closing it early. And every time, no growth-phase CEO wanted to hear that.
This article is for the CTO who's tried to bring it up three times in five quarters and watched something more urgent eat the agenda. And for the CEO who's read the word "refactor" in too many engineering updates and isn't sure what they're being asked to fund.
What technical debt actually is (and the part most CEOs miss)
Every scaleup has technical debt. Not because the engineering team was sloppy — because that's the way scaleups get built. You ship the MVP in 3 months, find product-market fit, hire fast, ship features faster, and the codebase your founding engineers wrote at 2 AM in year one is still the spine of your product in year four.
The canonical definition comes from Ward Cunningham, who coined the term in 1992: technical debt is what you accumulate when you choose a faster, less-clean solution today, with the intention of paying off the cleanup later. Martin Fowler later sharpened this into a 2×2 quadrant — debt can be deliberate or inadvertent, reckless or prudent. All four are real. All four cost money.
But the part most CEOs miss isn't the taxonomy. It's that technical debt isn't primarily about tech. It's about loss of trust, lost momentum, increased bug rates, slower hiring, and rising infrastructure costs. Each of those has its own price tag. And the spicy part — the part that doesn't show up on any board deck — is that they compound. They happen at the same time. The bug rate goes up while delivery slows down while a senior engineer quits while the AI initiative stalls. Four costs hitting one quarter, mutually accelerating.
That's the part nobody quantifies. That's why "we'll fix it later" stops being a strategy and becomes the strategy that fails.
The four costs that compound on the same quarter
Most articles list the costs of technical debt in isolation. Velocity tax here, hiring tax there. The honest version is that they all hit you together, on the same quarter, and the price tag explodes because each one accelerates the others.
The feature velocity tax
What used to ship in 2 weeks now takes 6-8. Every new feature touches fragile code in 5 places. Regression bugs spike after each release. McKinsey's 2020 survey of 50 CIOs found tech debt eats 20-40% of every technology estate. That's not abstract. That's a quarter of your engineering payroll going to fight code that fights back — and the honest version is that nobody on the engineering team gets to spend that quarter on the work that grows the business.
The hiring and retention tax
In our experience, senior engineering roles at growth-phase scaleups sit open 60-90+ days, partly because the best engineers can read a codebase in an interview and know whether they want to live in it. The ones you do hire take months to be productive instead of weeks. The ones already on the team start interviewing elsewhere, because nobody enjoys spending their best years on a codebase that fights them on every pull request (PR).
The trust and customer tax
Bug rates rise. Outages last longer because nobody fully understands the affected path. Customer support tickets balloon. Sales starts hedging on what's "in the next release" because they've been burned. The compounding part: the CTO can't fix this fast because the engineering team is firefighting instead of building, and the firefighting is happening because the foundation is cracked.
The AI and exit-value tax
This one is new and getting bigger every quarter. 81% of executives say tech debt constrains AI success (IBM Institute for Business Value, "The CEO's guide to generative AI," 2024). Investors doing technical due diligence before a Series C or an exit have started knocking value off the offer when they find what's actually in the codebase. The penalty for shipping debt forward into a fundraise stopped being something you could clean up "before the data room opens." It's now part of what the data room shows.
Add the four together, in the same quarter, and the bill is no longer 20-40% of your tech estate. It's a step change in the rate of growth. Which is exactly why no growth-phase CEO wants to look at it.
Why your CTO can't sell this on her own
I've been the CTO of someone else's company. We act as fractional CTO for non-technical founders, and I've sat through several years of being on the receiving end of "ship the feature, the refactor can wait."
The dynamic is consistent. The CEO is under pressure from the board for feature velocity. The board is under pressure from investors for growth metrics. The product team is under pressure from sales for the deal-breaker feature. Engineering is the one team in the room with no external customer pulling on them — and the work they want to do is invisible, technical, and impossible to demo on a slide.
So engineering loses the priority fight, quarter after quarter, even when the CTO is right. Even when she's spelled out the cost. Even when she's used the words "this will break." The CEO has heard those words before, the prediction didn't hit on the timeline the CTO claimed, so the next prediction gets discounted.
The dynamic only breaks when the bill arrives. And by then, the bill is usually the kind of incident that costs more than 18 months of remediation budget would have.
This is why technical debt is a CEO problem. Not because engineering should stop owning it — because the political mechanism that's blocking the fix lives at the CEO level, and only the CEO can rewrite that mechanism.
What it actually looks like in your codebase
Per Fowler's quadrant, debt comes in four flavors. Here's what each one looks like in a real growth-phase codebase:
In a growth-phase scaleup, all four exist simultaneously. The diagnostic question isn't "do we have debt." It's "which of these is currently costing us the most, and what's the fastest way to find out."
The €5K diagnostic before the €50K-€150K remediation
In our experience, the remediation work for serious tech debt at a 50-250 person scaleup runs €50,000-€150,000 — depending on scope, codebase shape, and how much can run in parallel with feature delivery. That's a real number to defend to a board. It needs evidence.
The cheap way to get that evidence is a structured audit. Our Tech Health Audit is €5,000 and takes a week. It produces a written report covering the four costs above, mapped to specific parts of your codebase, with a remediation sequence and rough effort estimate. A board can read it. A CFO can model it. A CEO can decide off it.
If you want the full checklist of what a tech debt and due-diligence audit should cover before you commission one, we wrote it up here — it's the same instrument we use internally on rescue projects.
The €5,000 isn't the value. The value is that the next conversation with your CEO is grounded in evidence rather than engineering's opinion. That's the conversation that gets the remediation funded.
Two stories about what fixing it actually looks like
Rockpoint Legal Funding: the bill that finally arrived
Rockpoint is a US legal funding company. We've been their development partner for 9+ years. They process thousands of cases, run a $150M+ portfolio, and grew 10× during our partnership.
In the early years, we were pushed hard by the CEO to implement features as fast as possible. The pace was incredible. The growth was incredible. The codebase paid the price.
Jira's urgency labels evolved over the years from "urgent" to "very urgent" to "mega urgent" to "hyper urgent." Eventually anything below "mega urgent" went unnoticed for months. We warned the CEO repeatedly that something would break. He acknowledged the risk, then went back to the feature pipeline because the business was on fire in the good way.
The bill arrived as a single incident that took down the company for half a day. I'm going to skip the specifics — every CTO reading this can imagine a half-day company-wide outage and supply their own version. The point is the price tag. That single day was more expensive than 18 months of remediation budget would have been.
After that, we got the time and the budget. The codebase got rebuilt in stages, with no major downtime. The platform now handles the $150M+ portfolio, the 200-300% YoY growth, and a credit line in the hundreds of millions. The Angular 1 to Angular 5 migration ran without downtime. The CRM and workflow systems were rebuilt on Symfony. Automated testing and 2FA went in. The codebase that was the brake on the business became the thing that's now ready for the next 10×.
The lesson Rockpoint's CEO and I both took out of this: the price tag for closing the gap late was orders of magnitude more than closing it early would have been. We both wish we'd had the conversation differently, two years earlier.
QuantPedia: the framework lock-in case
QuantPedia is a global platform for algorithmic investors. When we first met them, the platform ran on a custom-built .NET CMS that had become a prison. Every content update required a developer. Adding a new strategy parameter to the screener tool took weeks. There was no flexibility for new features because the framework itself was the constraint.
This wasn't "shipped fast, accumulated cruft." This was deliberate, inadvertent debt that aged badly. The original CMS choice made sense in its time. By year five, the world had moved on, and the platform couldn't.
We rebuilt the platform on WordPress with a Bedrock security base, Pods.io for structured data, WP All Import for the migration, and HighCharts for the financial visualizations. We rebuilt the screener — the complex filter tool over 20+ strategy parameters — from scratch. We migrated the entire content base without losing search ranking.
Subscriptions and traffic grew 300% in the years after the rebuild. Zero security incidents in 2+ years. The client got full content autonomy back — the marketing team stopped filing tickets and started shipping campaigns. New subscription models launched on the back of capabilities the old platform couldn't have supported.
The framework lock-in had been quietly costing them growth for years. They didn't know how much until they were out of it.
AI just made all of this more urgent
Everything above held in 2022. Here's what AI changed.
The window for "we'll fix it later" closed somewhere in the last 18 months. AI is a force multiplier. In a healthy codebase, AI-assisted development meaningfully speeds up real engineering work — type-checking, refactor support, test generation, even architectural exploration. In a messy codebase, AI is a force multiplier in the wrong direction. It accelerates whatever is already there. Bad codebase plus AI equals more bugs faster, more half-understood patterns, more dependencies on context that doesn't exist anywhere a model can read.
The framing I use with clients: AI is nitro. It accelerates whatever is in the engine. If the engine is healthy, you go faster. If the engine has a crack in it, you go faster toward the crash.
Beyond velocity, there's the agentic readiness problem. The next layer of competitive pressure for SaaS is whether your product is consumable by AI agents — whether your APIs are machine-readable, your authentication is agent-friendly, your event model supports async agent workflows. Model Context Protocol (MCP) wrapper patterns can bridge legacy APIs to agents, but LiquidMetal AI's piece If your MCP is an API wrapper, you're doing it wrong describes the failure mode cleanly: the agent works for the first five calls, then gets stuck on the sixth. Bridging is a tactic. Cleanup is the strategy.
Gauge.sh CTO Evan Doyle put it directly: "the penalty for having a 'high-debt' codebase is now larger than ever" (Gauge.sh, November 2024). That's not a sales line. That's the consequence of AI changing what a "fast" engineering team can ship — and the gap between high-debt and clean-debt codebases widening as a result.
If you're a CEO trying to figure out whether the AI investment your competitors are making is a real threat: the answer depends almost entirely on the state of your codebase. Building AI features on a healthy codebase is closer to 3D printing the next floor of a house. Building AI features on a debt-loaded codebase is closer to trying to add a floor by hand-stacking rocks.
FAQ
What's the difference between technical debt and just bad code?
Bad code is undisciplined work that should never have shipped. Technical debt is a deliberate or unintentional choice to ship a less-clean solution under time pressure, with the implicit promise to clean it up later. The shape is similar; the framing matters because tech debt should be tracked and paid down, whereas bad code is a quality control problem.
How much does technical debt cost a typical scaleup?
McKinsey's research puts it at 20-40% of the technology estate. At a 50-250 person scaleup with a €5M-€20M engineering budget, that's €1M-€8M per year of wasted capacity. Most of it shows up as slower feature delivery, longer hiring cycles, higher bug rates, and reduced ability to launch adjacent products.
Can we just keep shipping features and ignore it?
You can, for a while. The compounding mechanism is what makes "ignoring it" a strategy that fails predictably rather than randomly. The four costs accelerate each other. You don't pay them in equal annual installments — you pay them in step changes that arrive together, usually around the time you're trying to do something hard like raise a round or launch a new product.
Who in our company should own technical debt?
The CTO owns the inventory and the remediation plan. The CEO owns the budget decision and the political cover. Without both, the work doesn't happen. If you don't have a CTO and your engineering team is below 15 people, a fractional CTO can fill the inventory-and-plan gap — we wrote about when that's the right move here.
Is rewriting the whole thing ever the right move?
Rarely. Most "full rewrites" run 2-3× over budget and ship something that's slightly different but not obviously better. Strategic rewrites of specific subsystems, in parallel with continued feature work, almost always beat a full rewrite. QuantPedia is one of the exceptions — the framework lock-in made strategic incrementalism impossible. The default answer should be "no, refactor in sequence."
How does AI change the calculation?
AI accelerates whatever you have. Healthy codebases get faster, more reliable, and more agentic-ready. Debt-loaded codebases get worse, faster. Gauge.sh's CTO put it directly: the penalty for high-debt codebases is now larger than ever. And IBM's Institute for Business Value found 81% of executives say tech debt constrains their AI initiatives. The window for "we'll fix it later" closed somewhere around the second half of 2024.
What's the first move if we know we have a problem but don't know its shape?
A structured 5-day audit. Independent, written, mapped to specific costs and a remediation sequence. Our Tech Health Audit is €5,000. The audit's job is to convert "we have tech debt" from engineering opinion into a board-readable artifact. Once you have that, the conversation about the €50,000-€150,000 remediation budget gets easier.
Closing CTA
If you've read this far, your codebase is probably costing you more than your engineering team can explain on a slide. That's not their fault. The thing they need from you isn't more sprint pressure. It's the budget and the political cover to fix the foundation while still shipping features.
The cheapest move is a structured audit that converts engineering's diagnosis into a CFO-readable plan. Our €5,000 Tech Health Audit produces exactly that, in a week. I've personally led 50+ rescue and remediation engagements at growth-phase scaleups over the last 20 years, and the audit is how almost every successful remediation we've shipped actually started. If you want a 30-minute call to talk through whether an audit makes sense for your situation, reach out.
The price tag for closing the gap late is always orders of magnitude more than closing it early. Don't be the company where the bill arrives as the lesson.
Sources
- Cunningham, Ward. The WyCash Portfolio Management System. OOPSLA, 1992.
- Fowler, Martin. Technical Debt Quadrant. 2009.
- McKinsey & Company. Tech Debt: Reclaiming Tech Equity. 2020.
- IBM Institute for Business Value. The CEO's guide to generative AI. 2024.
- Doyle, Evan (Co-Founder & CTO, Gauge). AI Makes Tech Debt More Expensive. November 13, 2024.
- LiquidMetal AI. If your MCP is an API wrapper, you're doing it wrong.
