Stratégie
Technical Debt: The Real Cost (And How to Reduce It)
PULSE.digital · 5 min
Marc is CTO of a Geneva-based logistics scale-up. His team of 12 developers is delivering less and less every sprint. Bugs are piling up. New features take three times longer than they did eighteen months ago. In the board meeting, the CEO asks the question everyone dreads: "Marc, why is our roadmap constantly slipping despite our investment?"
Marc knows the answer. He just doesn't know how to quantify it yet.
This article is for Marc. And for his CFO.
TL;DR - What You Need in 60 Seconds
- Technical debt = code that works but is difficult to modify, test, or understand
- Typical cost: 25–40% of team velocity lost to maintenance and workarounds
- Formula: Number of devs × Annual loaded salary × % time on maintenance = CHF lost per year (e.g. 10 devs × CHF 120k × 30% = CHF 360k/year)
- Red flag: if your PR cycle time has doubled in 18 months, debt is accumulating faster than you're paying it off
- Key insight: don't always pay off the debt - sometimes it's smarter to live with it if the business changes in 12 months
Technical Debt Explained to Your CFO in 3 Minutes
Your CFO understands loans. They understand interest. Use that.
A variable-rate loan. When you launched, your team coded fast. The shortcuts taken to hit deadlines - that's the capital you borrowed. For months, you paid low interest: minor bugs, some maintenance. Then interest compounded. Eighteen months later, every new feature touches fragile, undocumented, untested code. Delivery cost rises. You're paying interest without ever touching the principal.
The house built without an architect. Imagine a house built in a rush, without blueprints, to meet a deadline. It stands. But when you want to expand the kitchen, you discover load-bearing walls where none should be. Every renovation triggers surprises. Every change costs three times what it should.
What developers say - and what they actually mean:
| What developers say | What it actually means |
|---|---|
| "The legacy code is a problem" | Nobody dares touch it - nobody truly understands it |
| "We don't have time to refactor" | We're paying interest daily without reducing the principal |
| "It's going to blow up someday" | You're already losing money now, not in the future |
| "We need a rewrite" | Accumulation cost now exceeds the cost of repayment |
Technical debt is not an engineering problem. It's a P&L problem.
The 4 Causes of Technical Debt (and Which One Applies to You)
Debt doesn't appear from nowhere. It has specific origins. Diagnosing the cause is the first step toward solving it.
1. Delivery Pressure
"We'll handle the refactoring after launch."
Spoiler: after never comes. The launch generates new bugs, new requests, a new sprint. Refactoring stays in the backlog, perpetually deprioritized. Six months later, the code that was supposed to be temporary is now the foundation everything else is built on.
This is the leading cause in startups and scale-ups in hypergrowth mode. When survival depends on time-to-market, quality comes second. That's rational in the short term. It's devastating at the 18-month mark.
2. Poor Initial Choices
Every engineering team makes technology decisions. Some age badly.
- An open-source library chosen in 2019, abandoned by its maintainers in 2021
- A monolithic architecture that can't scale at 10x user load
- A database chosen for simplicity, inadequate for current data volumes
- A framework selected because the previous CTO knew it well
These aren't mistakes. They're decisions made with the information available at the time. The problem is when they're never revisited.
3. Team Turnover
Every developer who leaves takes irreplaceable knowledge with them: why this piece of code works the way it does, which decisions were made and why, which side effects to watch for.
Their replacement discovers code without documentation, without context, without tests. They do their best. They add their own layer of workarounds. The debt compounds.
In a market like Switzerland where senior developers are scarce and highly sought after, turnover isn't an exception. It's a structural reality you have to account for.
4. Absence of Automated Tests
This is the multiplier of every other problem.
Without tests, safe refactoring is impossible. Every code change might break something elsewhere - and you won't know until production. Result: nobody touches the existing code. Debt accumulates, untouchable.
Test coverage isn't a developer vanity metric. It's insurance that determines your ability to repay debt.
5 Metrics to Quantify Technical Debt Without Being a Developer
You don't need to read code to measure technical debt. These five indicators are readable by any manager.
| Metric | Measurement Tool | Red Flag | What It Reveals |
|---|---|---|---|
| PR cycle time | GitHub / GitLab Analytics | Doubled in 12 months | Each change takes longer: complex reviews, fragile dependencies |
| Bug rate (bugs/sprint) | Jira / Linear | > 30% of sprint on bugs | Existing code generates more problems than it produces value |
| Test coverage | SonarQube, Codecov | < 60% | Risk zone: dangerous modifications, refactoring impossible |
| Onboarding time | Observation | > 4 weeks to productivity | Absent documentation, incomprehensible code, opaque dependencies |
| Sprint velocity | Jira Velocity | > 20% drop over 6 sprints | Team delivers less with the same resources |
How to get this data?
Ask your CTO to share GitHub/GitLab and Jira analytics for PR cycle time and velocity. It's native - no extra tools needed. For test coverage, SonarQube installs in hours and generates a clear dashboard.
If your CTO can't provide this data within 24 hours, that's already a signal.
Calculate Your Technical Debt in CHF: The Simple Formula
Here's the formula Marc used with his board:
Annual cost of technical debt =
Number of developers
× Annual loaded salary (including employer contributions)
× % of time spent on maintenance and workarounds
= CHF lost per year
This isn't a theoretical estimate. This is the money you invest in your team every month that produces zero business value.
Concrete Examples
Startup - 5 developers: 5 devs × CHF 120k × 20% = CHF 120,000/year lost to maintenance
That's the cost of a full-time senior developer who delivers nothing new.
Scale-up - 10 developers: 10 devs × CHF 130k × 30% = CHF 390,000/year lost to maintenance
Three senior developers working exclusively to maintain the existing system.
Enterprise - 25 developers: 25 devs × CHF 140k × 35% = CHF 1,225,000/year lost to maintenance
Over a million Swiss francs per year disappearing into unproductive maintenance.
Key Benchmarks
| Zone | % Time on Maintenance | Interpretation |
|---|---|---|
| ✅ Healthy | < 15% | Debt under control, productive team |
| ⚠️ Watch | 15–25% | Visible accumulation, address within 6 months |
| 🔴 Red Zone | 25–40% | Significant velocity and value loss |
| 💀 Critical | > 40% | Urgent remediation, major operational risk |
How to estimate maintenance percentage?
Ask your CTO to categorize the last three months of Jira/Linear tickets into two buckets: new features vs. maintenance/bugs/debt. The ratio gives you your number. An honest sprint planning session reveals everything.
Real Case Study: CHF 420k/Year Lost at a 10-Developer Scale-Up
Back to Marc.
Three weeks after that uncomfortable board meeting, Marc commissioned a technical assessment from PULSE. The 48-hour diagnostic produced these findings:
The diagnosis:
- 10 developers × CHF 120k loaded salary
- 35% of time spent on maintenance, workarounds, and bug fixes
- Sprint velocity down 40% over the past 12 months
- PR cycle time increased from 2 days to 5 days over 18 months
- Test coverage: 28% - well below acceptable threshold
The calculation: 10 × CHF 120k × 35% = CHF 420,000 lost every year
Marc presented this figure to his board. For the first time, the conversation shifted from "why is this slow" to "how much is this costing us and how do we fix it."
The solution: PULSE reinforced the team with 4 refactoring specialists for 6 months. Approach: incremental refactoring, module by module, without stopping delivery of new features.
Results at 9 months:
- Maintenance reduced from 35% to 15%
- Sprint velocity up 60%
- PR cycle time back to 2.5 days
- Test coverage at 74%
- CHF 240,000/year recovered - the 4 PULSE developers were effectively financed by the debt repaid
His CFO understood. His board approved. His team could breathe again.
When to Pay Off Your Debt (And When Not To)
This is the section that 90% of technical debt articles forget to write.
Repaying debt costs money. It's not free. Before launching a refactoring initiative, ask one simple question: will the code you're refactoring still be relevant in 12 months?
If your product is pivoting, if you're considering an acquisition, if your business model is shifting - refactoring today could be a financial mistake.
The decision matrix:
| Debt Level | Business Horizon | Decision | Recommended Strategy |
|---|---|---|---|
| 🔴 High | Long term (3+ years) | ✅ Repay now | Planned refactoring, dedicated budget |
| 🔴 High | Short term (< 12 months) | ⚠️ Evaluate | Repay only critical blockers |
| 🟡 Low | Long term | ✅ Repay progressively | 20% of each sprint on refactoring |
| 🟢 Low | Short term | ❌ Ignore | 100% focus on new features |
What this matrix means in practice:
A startup in product validation mode that will pivot in 6 months has zero reason to refactor their codebase. The accumulated debt will die with the pivot. Better to ship fast, learn fast, and rebuild cleanly on the next version.
On the other hand, a scale-up operating a core product for 3 years, with a 15+ dev team and a 3-year roadmap - every month of delay in repaying debt costs more than the repayment itself.
The rule of thumb: if your debt costs more than CHF 200k/year and your business horizon exceeds 18 months, the ROI of repayment is nearly certain.
Refactoring, Strangler Pattern, or Big Rewrite: Which Strategy?
Once the decision is made, three strategies are available. They're not interchangeable.
1. Incremental Refactoring
Description: Modify existing code progressively, module by module, without rewriting the application from scratch. The product continues to function during the process.
Advantages: Low risk, service continuity, visible results quickly.
Risks: Slow. Requires discipline. Can be derailed by delivery emergencies.
Estimated CHF cost: CHF 80k–200k depending on codebase size and duration.
Timeline: 3 to 9 months.
Ideal for: Viable codebases with a globally sound architecture but degraded sections. Teams continuing to deliver features in parallel.
2. Strangler Pattern (Strangler Fig)
Description: Replace the legacy application module by module, building the new version in parallel. You progressively "strangle" the old application until it's completely replaced.
Advantages: Less risky than the big rewrite. Enables migration without downtime. Validates new architecture progressively.
Risks: Complexity of running two systems simultaneously. Requires solid routing strategy and data migration planning.
Estimated CHF cost: CHF 150k–400k depending on application complexity.
Timeline: 6 to 18 months.
Ideal for: Applications with identifiable architecture, well-delimited modules, and a need for zero-downtime migration.
3. Big Rewrite
Description: Start from scratch. New architecture, new code, new foundations. The team builds version 2 while version 1 continues operating.
Advantages: Can be fast if well managed. Allows adoption of modern technologies. Eliminates all debt at once.
Risks: This is the most dangerous strategy. Big rewrites have killed companies. If the project runs late - and it will - you're funding two teams for two products. Timelines extend, budgets explode, morale collapses.
Estimated CHF cost: CHF 300k–1M+ depending on application size.
Timeline: 12 to 36 months.
Ideal for: Applications with fundamentally unviable architecture, or obsolete technology (end of support, critical security vulnerability). Reserve for cases where incremental refactoring is no longer possible.
PULSE recommendation: In 80% of cases, incremental refactoring combined with the strangler pattern for critical modules is the optimal approach. The big rewrite is only justified in extreme cases, and always with a dedicated external team.
When Your Internal Team Can't Repay Alone
This is the reality for most organizations. Not an admission of weakness. A structural observation.
Scenario 1: The team is 100% on delivery.
If your developers are shipping features full-time, they can't simultaneously refactor existing code. Every sprint that passes is a sprint without debt repayment. The solution: either slow down delivery (rarely acceptable), or bring in dedicated resources.
Scenario 2: Architecture expertise isn't in the team.
Refactoring a complex microservices architecture, migrating a monolith to distributed architecture, introducing a strangler pattern on an 8-year-old legacy application - these require specific expertise that not every developer has. Sending a mid-level developer into this is risky and potentially more expensive than bringing in a specialist.
Scenario 3: The team can't see the problems anymore.
This is the familiarity bias. Developers who've worked on the same codebase for 3 years have internalized its dysfunctions. They code around problems without seeing them. An outside perspective identifies in 48 hours what the team stopped seeing 18 months ago.
Scenario 4: Budget approved, resources unavailable.
You've had a refactoring budget approved by your board. But hiring 3 senior specialist developers in Switzerland takes 4 to 6 months on average. And if you find the profiles, they might leave in 18 months.
An external partner like PULSE delivers profiles in 2 to 4 weeks, integrated into your team, with immediate expertise.
PULSE Assessment: Know in 48h What Your Debt Costs
PULSE offers a structured technical diagnostic for organizations that want to quantify their debt before investing.
What the assessment includes:
- Codebase analysis: architecture review, risk zone identification, test coverage evaluation
- Productivity metrics: GitHub/GitLab, Jira data analysis, cycle time, velocity
- CHF quantification: annual debt cost calculation using your own salary data
- Prioritized roadmap: ordered list of refactoring initiatives by descending ROI
Team reinforcement:
After the assessment, PULSE can embed specialized developers directly into your team - nearshore from Lausanne or Marrakech - to execute the roadmap without slowing your delivery.
Typical result: 30–40% reduction in maintenance time within 6 months.
FAQ - The Real Questions CFOs and CTOs Ask
1. How do I convince my CFO to invest in debt repayment?
With numbers. Not technical arguments. Use the formula in this article to calculate your annual debt cost in CHF. Then compare that figure to the cost of repayment. If the ROI is positive over 18 months - and it almost always is - your CFO will approve.
The key: never present refactoring as an "investment in quality." Present it as an operational cost reduction with a measurable, auditable return on investment.
2. How long does a technical audit take?
An initial PULSE assessment takes 48 business hours. You get an analysis, a CHF quantification, and a prioritized roadmap in two days. For a full audit with solution prototyping, plan 2 to 3 weeks.
3. Can you refactor without stopping new features?
Yes - and that's the recommended approach in 90% of cases. Incremental refactoring and the strangler pattern are designed to run in parallel with product delivery. The condition: having dedicated refactoring resources, separate from the product team.
4. What's the difference between technical debt and legacy code?
Technical debt is a financial concept: the cost of shortcuts taken in the past. Legacy code is old code - but not necessarily problematic. Code from 1995 that's perfectly documented, tested, and stable is not debt. Code from 2022 that's untested, undocumented, and incomprehensible is severe debt.
5. How to prioritize: repay debt or hire?
Hiring on a codebase with 40% maintenance sends new developers to drown in existing debt. They'll be less productive, more frustrated, and leave faster. The optimal sequence: audit → resolve critical blockers → hire on a clean foundation. In some cases, both in parallel with separate resources.
Conclusion: Marc, 9 Months Later
Nine months after that uncomfortable board meeting, Marc presented a different kind of update.
His team delivers 60% faster. Sprints are no longer dominated by bugs. New features take the time they should take. The board hasn't asked a single question about roadmap delays in six months.
His CFO - the same one who scrutinized every tech investment with skepticism - approved an engineering budget for the first time without negotiating. Because for the first time, Marc presented an ROI calculated in CHF, measured over 9 months, fully auditable.
Technical debt isn't an engineering problem. It's a business performance problem. And like any performance problem, it can be measured, quantified, and solved with the right strategy.
Want to know what your technical debt is costing you?
PULSE delivers a complete diagnostic in 48 hours: codebase analysis, productivity metrics, CHF quantification, prioritized roadmap.