Solutions
Turn “it's bad” into numbers your CFO can act on.
Leadership asks “how bad is the tech debt?” and engineering says “bad.” That's not a budget conversation. Axiom Refract replaces qualitative hand-waving with quantified structural metrics that justify investment.
The problem with “it's bad.”
Every engineering team knows their tech debt is a problem. But when the conversation moves to budget allocation, “it's bad” doesn't compete with “this feature will generate $2M in revenue.” Revenue has numbers. Tech debt has vibes.
The result is predictable: tech debt gets deprioritized quarter after quarter until it manifests as an outage, a failed migration, or a new hire who takes 3 months to become productive because nobody can explain the system architecture.
The fix isn't convincing leadership that tech debt matters. They already believe you. The fix is giving them numbers they can put in a spreadsheet next to the revenue projections.
Six metrics that make tech debt measurable.
Each metric is computed from the dependency graph and AST analysis. No surveys. No self-assessments. No subjective scoring.
Dead Code Volume
What it measures
Total recoverable lines of code — files, functions, and database tables that are defined but never used.
Why it matters to leadership
Tells leadership exactly how much of the codebase is maintenance overhead with zero value. A concrete number, not a feeling.
SPOF Count & Severity
What it measures
Number of single points of failure, ranked by blast radius and centrality score.
Why it matters to leadership
Translates architectural risk into incident probability. Three critical SPOFs with 40+ dependents each is a quantified liability.
Dependency Complexity
What it measures
Graph metrics — average fan-in, fan-out, circular dependency chains, transitive closure depth.
Why it matters to leadership
Shows how tangled the system is. High dependency complexity means slow feature delivery and unpredictable change impact.
Blast Radius Distribution
What it measures
How many files have high blast radius (20+ dependents) vs. low blast radius (0–5 dependents).
Why it matters to leadership
Shows whether risk is concentrated or distributed. A system where 5 files have blast radius >50 is structurally fragile.
Architectural Zone Health
What it measures
Per-zone risk scores based on SPOF density, dead code percentage, and dependency coupling.
Why it matters to leadership
Pinpoints which parts of the system need investment. Instead of “the whole codebase needs work,” you can say “the auth zone is critical.”
Ghost Method Count
What it measures
Symbols called but never defined — functions that your code references but that don't exist.
Why it matters to leadership
These are latent runtime errors. Every ghost method is a crash waiting to happen in an untested code path.
From “we need to refactor” to a funded initiative.
With Axiom Refract's output, the conversation changes. Instead of “we have tech debt,” you present:
- •“18% of our codebase is dead code — 12,400 lines we maintain for zero value.”
- •“We have 4 critical SPOFs. If auth.ts breaks, 53 files cascade. That's our last three outages explained.”
- •“The payments zone has a dependency complexity score 3x higher than any other zone. That's why payments features take twice as long.”
- •“Here's the prioritized remediation plan, ordered by risk reduction per engineering-week invested.”
That's a budget conversation. That's a conversation that gets funded.
Turn “it's bad” into numbers your CFO can act on.
Upload your repository. Get a complete technical debt assessment — dead code, SPOFs, dependency complexity, and a prioritized remediation plan.