Skip to content
Comtau
Book a callBook a call

Technical Debt Assessment

Technical debt you can measure, prioritise and pay down

A structured assessment of the debt slowing your delivery - across code, architecture and process - scored by business impact and turned into a roadmap your team can act on.

For engineering leaders whose delivery is slowing under debt nobody has been able to quantify.

Book a debt assessment callSee what the assessment produces
  • Architecture-first
  • Scored, not anecdotal
  • Assessment → remediation

Powered by Comtau Inc.

Debt by layer

Illustrative

  • Codemedium
  • Architecturehigh
  • Infrastructurelow
  • Testmedium
  • Processmedium
Quick winsStructuralStrategic
Debt is measured across layers, not read off a single code-quality score.

What technical debt is - and why it isn’t just messy code

Technical debt is the future cost of past shortcuts: decisions made for speed that now slow delivery, raise risk or block scaling. Some debt is a deliberate, reasonable trade-off. Some is inadvertent and dangerous. Telling the two apart is the first job of an assessment.

Debt exists in more than code. It accumulates in architecture (coupling and drift from where the system needs to go), infrastructure, test coverage, documentation and delivery process. Architecture debt is usually the most damaging and the most often missed, because code-scanning tools don’t see it.

The goal of an assessment isn’t a quality score. It’s a register of specific, scoped items - each tied to a business risk - that a team can actually plan against.

Reckless

Prudent

Deliberate

Deliberate, reckless

A shortcut taken with no plan to repay it

Deliberate, prudent

A tracked trade-off for speed, with a plan to repay it

Inadvertent

Inadvertent, reckless

A gap caused by not knowing the better approach existed

Inadvertent, prudent

A better approach only became clear after the system was built

Prudent debt is a trade-off you can manage. Reckless debt is the kind an assessment has to surface first.

Where debt accumulates

  • CodeComplexity, duplication and risky hotspots
  • ArchitectureCoupling, unclear boundaries, drift from the target
  • InfrastructureOutdated platforms, manual environments
  • TestMissing coverage where change is riskiest
  • DocumentationKnowledge held by people, not written down
  • ProcessSlow, fragile or manual delivery

Signs you need an assessment

When technical debt stops being a code-review comment

Debt becomes a business problem once it starts showing up outside engineering. These are the signals worth acting on.

  • Delivery keeps slowing down

    Estimates that used to hold now regularly double.

  • Defects and incidents are rising

    A growing backlog of “known issues” nobody has time to fix.

  • The team is afraid to change things

    Workarounds piling up instead of fixes.

  • The architecture is hitting a ceiling

    Performance fixes that buy weeks, not a solution.

  • Onboarding takes too long

    Tribal knowledge substituting for documentation.

  • The roadmap is blocked by the platform

    Debt discussed constantly, measured never.

How we measure it

Three lenses, one register

Code metrics alone miss most of what actually slows a team down. Comtau assesses debt across code, architecture and delivery process together.

  • Lens 1

    Code

    • Static-analysis findings
    • Cyclomatic complexity
    • Test coverage
    • Hotspots: churn × complexity

    Complexity and coverage findings · Hotspot map by churn and risk

  • Lens 2

    Architecture

    • Dependency structure
    • Coupling between modules
    • Drift from target architecture
    • Scalability limits

    Architecture drift findings · Scalability risk list

  • Lens 3

    Delivery process

    • Lead time for changes
    • Change failure rate
    • Defect ratio
    • Deployment frequency

    Delivery metric baseline · Process risk findings

The calculation model

  1. Inputs

    • Static analysis
    • Dependency graph
    • Delivery metrics
    • Team interviews

  2. Analysis

    • Classify by type and layer
    • Estimate remediation effort
    • Rate business impact and interest

  3. Result

    • Debt register with a cost and risk score per item

The technical debt ratio (remediation effort ÷ development effort) is one input to this model, not the whole method. Tools are examples; the judgement is the product.

  1. Healthy

    Debt is known, tracked and deliberate, and repaid as part of normal delivery.

  2. Watch

    Interest is visible in slower delivery or rising defects, but still contained.

  3. Critical

    Debt is untracked and compounding faster than the team can pay it down.

How much technical debt is acceptable?

Some debt is a legitimate trade-off - a prototype, a time-to-market bet, a deliberate shortcut with a plan to repay it. It becomes dangerous when it’s inadvertent, untracked and compounding faster than the team can pay it down. Comtau doesn’t score debt against a fixed threshold; acceptability depends on business context, the interest rate the debt is accruing, and whether anyone can currently see it.

Not sure whether it’s a code problem or an architecture problem?

Tell us what delivery looks like right now. We’ll tell you plainly what a technical debt assessment would and wouldn’t answer.

Book a debt assessment call

Direct conversation with a senior CTO/architect. We’ll review your situation and determine the useful next step.

What you receive

A register you can plan against, not a quality score

Every finding is scored, prioritised and tied to a business risk - the same artefact your team keeps and revisits.

Debt priority matrix

Illustrative format · not client findings

Business impact →

Fix now

Plan

Monitor

Accept

Remediation effort →

Debt register · preview

  • D1No tests around billing rulesTestFix now→ Quick wins
  • D2Manual release stepsProcessFix now→ Quick wins
  • D3Two services share one databaseArchitecturePlan→ Structural
  • D4Synchronous calls across servicesArchitecturePlan→ Structural
  • D5Outdated logging libraryCodeMonitor→ Fix when touched
  • D6Legacy admin UI frameworkCodeAccept→ Document and revisit

  • Debt register & map

    Every item by layer and system area, with its type and the business risk it creates.

  • Severity & cost of delay

    For each item, how severe it is and what waiting costs, in delivery and risk terms.

  • Prioritisation matrix

    Items placed by business impact against remediation effort, so the order is explicit.

  • Phased remediation roadmap

    Quick wins, structural work and strategic changes, sequenced against delivery priorities.

  • Executive summary

    The picture in plain language for non-technical stakeholders and the board.

Discuss your codebase

Assessment process

How the assessment runs

A fixed sequence, senior-led, ending in a roadmap rather than a slide deck.

  1. 01

    Scope & access

    Agree what’s in scope and get the access needed to look at it properly.

    Assessment scope

  2. 02

    Analysis

    Examine the code, architecture and delivery data together.

    Draft findings

  3. 03

    Interviews

    Check findings against how the team actually experiences the system.

    Validated findings

  4. 04

    Findings workshop

    Walk the findings through with the team and leadership before anything is finalised.

    Agreed prioritisation

  5. 05

    Roadmap handover

    Hand over a register and roadmap the team owns from day one.

    Debt register + roadmap

Duration depends on the size of the system and is agreed at scoping.

Remediation

From roadmap to execution

A register that sits in a drawer isn’t remediation. Comtau can hand the roadmap to your team, lead the work alongside them, or execute a defined phase directly.

Remediation strategies

  • Incremental refactoring inside normal delivery
  • Strangler-style migration for architecture debt
  • Platform and infrastructure upgrades
  • Test automation where change is riskiest
  • Process changes that stop new debt forming

Roadmap phases

  1. 01Quick wins

    High-impact, low-effort items, started straight away.

  2. 02Structural

    Planned slots in the roadmap for larger changes.

  3. 03Strategic

    Bundled with a larger architecture change.

Who does the work

  • Advisory only

    Intensity: light

    You own remediation. Comtau delivers the register, the roadmap and a review session with your team.

  • Comtau leads with your team

    Intensity: regular

    Comtau plans and leads remediation, working through your existing engineers rather than replacing them.

  • Comtau executes a phase

    Intensity: deep

    Comtau takes hands-on ownership of a defined remediation phase - typically the highest-risk structural work.

When Comtau executes: remediation in bounded, verified units

Debt work fails when it turns into an open-ended rewrite. Comtau runs remediation through its own engineering system, where each register item becomes a small unit of work with a fixed scope and a proof that it is done.

  1. Debt inventory

    Every item in the register, scored by business impact and effort.

    Output: Technical-debt register

    Gate: Register reviewed with you

  2. Prioritisation

    Pick the next items by risk and cost, and record any design decision the fix depends on.

    Output: Prioritised items and decision records

    Gate: Priorities agreed with you

  3. Bounded remediation

    Each item becomes a scoped unit, implemented with AI-assisted engineering under human control.

    Output: Remediated units

    Gate: Stops if a fix starts to spread

  4. Verification

    Tests prove the fix and prove what must not break; an independent review signs it off.

    Output: Evidence, and the register updated

    Gate: Checks pass; reviews have no blocking findings

Controls on every remediation unit

Bounded units of work
Every unit states its mission, the parts of the system it may change, what is out of scope and the checks that will prove it.
No green by shortcut
Tests are never weakened, skipped or rewritten to make a check pass. An unexplained failure blocks closure.
Stops instead of improvising
When a unit meets scope growth, a failing check, a conflict or a missing approval, execution stops and a person decides.
Evidence per unit
Each unit closes with the exact commands run, their results, the tests that prove the change and the tests that prove what must not happen.

Ongoing management

Keep the register alive

Debt is managed, not eliminated. After the assessment, the register becomes a living artefact with a regular review cadence and a share of delivery capacity set aside for paying it down.

  • One owner for the register, senior enough to weigh debt against features
  • A fixed share of each sprint reserved for remediation
  • Debt reported to non-technical stakeholders as delivery risk and cost, not code quality

  1. 01

    Measure

    Track the same code, architecture and delivery metrics over time.

  2. 02

    Prioritise

    Re-rank the register as business priorities change.

  3. 03

    Remediate

    Pay down items within a set share of each sprint.

  4. 04

    Review

    Re-assess on a regular cadence, for example quarterly.

Related services

  • Software Architecture Review

    An independent assessment of whether the architecture fits where the system needs to go.

    Learn more

  • Technical Due Diligence

    The investor-side review, run ahead of a funding or acquisition decision.

    Learn more

  • Software Architecture Consulting

    Design the target architecture that structural debt remediation moves towards.

    Learn more

FAQ

Technical debt questions

What are the types of technical debt?

The classic framing splits debt by intent and awareness: deliberate-prudent (a tracked trade-off), deliberate-reckless (an untracked shortcut), inadvertent-prudent (learned too late) and inadvertent-reckless (a knowledge gap). Comtau also assesses debt by layer - code, architecture, infrastructure, test, documentation and process - since architecture debt is usually the most damaging and the easiest to miss.

How do you measure or calculate technical debt?

Across three lenses: code (static analysis, complexity, coverage, change-risk hotspots), architecture (coupling, dependency structure, drift from the target architecture, scalability limits) and delivery process (lead time, change failure rate, defect ratio). No single metric stands in for the whole picture.

What does a technical debt assessment include, and how long does it take?

Scoping and access, code and architecture analysis, team interviews, a findings workshop and a roadmap handover. Timing depends on the size of the system being assessed - we’ll scope this with you before starting.

Technical debt assessment vs architecture review vs technical due diligence?

An architecture review examines whether the current architecture fits where the system needs to go - see software architecture review. A technical debt assessment quantifies and prioritises the cost of past shortcuts across code, architecture and process. Technical due diligence is the investor-side equivalent, run ahead of a deal.

Is technical debt always bad?

No. A tracked, deliberate trade-off for speed can be the right call. It becomes a problem when it’s inadvertent, untracked, and compounding faster than the team can address it.

Who should own technical debt inside the company?

Someone senior enough to weigh it against business priorities - ideally the person accountable for technology decisions overall. See Fractional CTO for how that ownership can work without a full-time hire.

Can Comtau help reduce technical debt, not just report it?

Yes. The assessment ends in a roadmap, and Comtau can lead or execute remediation alongside your team rather than handing over a report and leaving.

Turn technical debt into a plan you can execute

Tell us what delivery feels like right now. We’ll help you work out whether a structured assessment is the right next step.

Book a debt assessment callSee software architecture review

Direct conversation with a senior CTO/architect. We’ll review your situation and determine the useful next step.

What happens next

  1. 01You describe where delivery is slowing down
  2. 02We scope what an assessment would cover
  3. 03We agree the assessment and what it will produce