Technical debt is a management problem disguised as an engineering problem. The engineering team knows it exists and can describe it in detail. The challenge is that “the authentication module has no integration tests and the session management logic is duplicated in six places” does not translate into a budget allocation or a prioritization decision.
Quantifying technical debt in dollars does not require precision. It requires a consistent framework that converts observed slowdowns and known risks into cost estimates that non-technical stakeholders can evaluate. This post covers the four categories of technical debt, how to calculate carrying cost and remediation cost for each, and how to make the prioritization case to leadership.
The Four Categories of Technical Debt
1. Dependency Debt
Dependency debt accumulates when third-party packages, frameworks, and APIs are not kept current. A library that is one major version behind can typically be updated in a few days. A library that is three major versions behind may require a multi-week migration that touches dozens of callsites throughout the codebase. The carrying cost of dependency debt is primarily security exposure and the increasing cost of eventual updates.
2. Architecture Debt
Architecture debt arises when the structure of the system no longer matches the requirements it must serve. A monolithic application that grew to serve 10 teams with independent release cycles has architecture debt. A database schema designed for a single-tenant product that now serves multi-tenant customers has architecture debt. Architecture debt is the most expensive category to remediate because it requires changes that touch the system at every level.
3. Code Quality Debt
Code quality debt includes duplicated logic that must be updated in multiple places when requirements change, functions with poor naming that requires reading the implementation to understand the intent, missing test coverage on critical paths, and inconsistent patterns that slow down new engineers. The carrying cost is primarily measured in engineering time: extra time to understand modules, extra time to debug without adequate logging, extra time to test changes manually.
4. Infrastructure Debt
Infrastructure debt includes manual deployment processes, missing monitoring, absent disaster recovery procedures, and development environments that do not match production. Infrastructure debt has a different risk profile than the other categories. It does not slow down daily engineering work as visibly as code quality debt — until an incident occurs. When the carrying cost manifests, it manifests suddenly and expensively.
Calculating Carrying Cost
Carrying cost is what the debt costs each month you do not fix it. It has two components: the velocity tax (slower engineering output) and the risk exposure (the expected cost of incidents the debt makes more likely).
Velocity tax calculation:
- Estimate how many hours per month the debt adds to routine work
- Multiply by the number of engineers affected
- Multiply by the loaded cost per hour
Example: An authentication module with no test coverage adds 2 hours of extra work to each feature that touches it. Authentication is touched in 3 features per month. Two engineers work on these features. Loaded cost is $120/hour.
Monthly carrying cost = 2 hours × 3 features × 2 engineers × $120 = $1,440/month
Risk exposure calculation: Estimate the probability that the debt causes a significant incident within the next 12 months, estimate the cost of that incident, and multiply. A 30% probability of a $40,000 incident = $12,000/year expected cost = $1,000/month carrying cost.
Remediation Cost by Category
| Category | Typical scope | Remediation cost | Priority trigger |
|---|---|---|---|
| Dependency | 1–3 major versions behind, 1 package | $2K–$15K | Security CVE or breaking change in next minor version |
| Code quality | One module or service, test coverage + refactor | $5K–$30K | Carrying cost >$1,500/month for 6+ months |
| Infrastructure | CI/CD pipeline, monitoring stack, DR procedures | $8K–$40K | First manual deployment failure or incident >4 hours |
| Architecture | Monolith decomposition, schema redesign, API overhaul | $20K–$150K+ | Feature velocity below 50% of capacity for 3+ quarters |
Prioritization: Payback Period
The payback period converts carrying cost and remediation cost into a single number: how many months until the remediation investment pays for itself?
Payback period = Remediation cost ÷ Monthly carrying cost
Under 12 months: straightforward to prioritize. 12–24 months: strategic judgment call. Over 24 months: re-examine whether the remediation cost can be reduced through incremental approaches, or whether the carrying cost estimate is missing components.
How to Present Technical Debt to Leadership
Feature delay cost. If the debt slows feature development by 20%, and engineering cost is $200,000/month, the monthly velocity cost is $40,000 — before considering opportunity cost from delayed features.
Incident probability × cost. For infrastructure and dependency debt with security implications, expressing risk as expected annual cost grounds the conversation in financial terms that leadership already uses for other risk decisions.
Incremental remediation vs. total replacement. Large architecture debt ($50,000+) is easier to approve when presented as a phased approach: Phase 1 addresses the highest-friction areas and delivers measurable velocity improvement; Phase 2 completes the migration.
The 20% Engineering Capacity Rule
Teams that allocate 15–20% of engineering capacity to technical debt continuously — treating it as a recurring budget line rather than a one-time project — maintain lower carrying costs and avoid architectural debt spirals that require expensive rewrites.
Teams that do not allocate continuous debt capacity typically reach a point where the carrying cost exceeds the team's capacity to absorb it while delivering features. At that point, leadership must choose between a large remediation investment and continued velocity degradation. The continuous allocation avoids that forced choice entirely.
Building the Technical Debt Register
A minimal register entry captures: description (what the debt is and where it lives), category (dependency, code quality, infrastructure, or architecture), monthly carrying cost (with calculation notes), remediation cost estimate, payback period, and priority tier.
Maintaining this register in a format visible to product and engineering leadership converts technical debt from an engineering-only concern into a shared prioritization input. Starting with the five highest-carrying-cost items and building from there is more valuable than attempting to catalog every suboptimal code pattern before anyone acts on any of it.
