How we score maintainability (SQALE, explained)

A single letter grade is a great way to communicate and a terrible way to hide things. So here's exactly how maintainability gets scored — no black box.

Debt as time

We use a SQALE-style model: every issue is assigned a remediation cost measured in time. A trivial code smell might be five minutes; a deeply nested function that needs restructuring might be a few hours. Add them up and you get technical debt — an estimate of how long it would take to bring the code to a clean baseline.

The debt ratio

Absolute debt is hard to compare across projects — 40 hours is a lot for a small library and nothing for a monorepo. So we normalize it against the estimated cost of building the code in the first place. That gives a debt ratio, and the ratio maps to a letter grade:

• A — under 5% debt ratio
• B — 5–10%
• C — 10–20%
• D — 20–50%
• F — over 50%

Why we don't grade on a curve

It would be easy — and flattering — to score everyone a B so the charts look green. We don't. If your reliability is a D, you'll see a D. A score you can't trust is worse than no score, because it makes you feel safe while shipping risk.

The grade is a starting point, not a verdict. Click into it and you'll see the specific issues driving the debt, ranked so you fix the expensive ones first.