🏥 Health Check

Technical Debt
Health Check

Assess your codebase across 6 dimensions. Get a health score, identify problem areas, and a prioritized remediation plan.

15 questions • 5 minutes

🔧 Maintainability

🧪 Testing

🏗️ Architecture

📚 Documentation

⚡ Velocity

🚀 Deployment

Question 1 of 15 7% complete

🔧 Maintainability

How long does it take a new developer to be productive?

Days — good onboarding, clear code

Can ship small changes in first week

2-4 weeks — decent documentation

Productive after orientation

1-3 months — steep learning curve

Requires significant hand-holding

3+ months — tribal knowledge required

Dependent on specific people

💡

Onboarding time reveals code health

If new developers need months to be productive, your codebase is communicating poorly. Good code is self-documenting. Great codebases have clear patterns, sensible abstractions, and obvious conventions.

🔧 Maintainability

When you make changes, how often do unexpected things break?

Rarely — changes are isolated

Confident in modifications

Occasionally — some side effects

Usually safe, some surprises

Frequently — unexpected regressions

Changes often break other features

Constantly — fear of touching anything

Every change is a minefield

💡

Tight coupling creates fragility

If changes cascade through the system unpredictably, you have tight coupling. Good architecture isolates concerns so changes are local. If you're afraid to touch code, the code owns you.

🔧 Maintainability

How would you describe your code's readability?

Clean — reads like well-written prose

Clear naming, obvious intent

Readable — mostly self-documenting

Some head-scratching moments

Cryptic — requires investigation

Frequent "what does this do?" moments

Obfuscated — archaeology required

Comments contradict code, mystery variables

💡

Code is read far more than written

Every line of code will be read dozens of times but written once. Optimize for readers. Good naming, consistent patterns, and clear structure pay dividends every day.

🧪 Testing

What's your test coverage situation?

Strong — >80% coverage, meaningful tests

Unit, integration, and e2e tests

Moderate — 50-80%, core paths covered

Critical functionality tested

Weak — <50%, many gaps

Some tests but not comprehensive

Minimal or none

Testing is manual or non-existent

💡

Tests enable refactoring

Without tests, you can't safely improve code. Tests aren't about finding bugs — they're about enabling change. The teams that move fastest have the best test suites.

🧪 Testing

How reliable are your tests?

Very — failures indicate real issues

Trust them completely

Mostly — occasional flaky tests

Most failures are meaningful

Questionable — frequent false positives

Often ignore failing tests

Unreliable — ignored or disabled

Tests have lost credibility

💡

Flaky tests are worse than no tests

If developers ignore test failures, your test suite is actively harmful. It creates noise and reduces confidence. Fix or delete flaky tests immediately — they're technical debt.

🧪 Testing

How fast is your test suite?

Fast — run in under 5 minutes

Developers run them frequently

Acceptable — 5-15 minutes

Run on every PR

Slow — 15-60 minutes

Run overnight or before releases

Very slow — hours

Rarely run, slow feedback loop

💡

Slow tests kill productivity

If tests take too long, developers won't run them locally. This means bugs are caught later, when they're more expensive to fix. Fast feedback loops are essential for velocity.

🏗️ Architecture

How well-defined are your system boundaries?

Clear — well-defined modules/services

Explicit interfaces between components

Decent — some coupling between areas

Mostly separable with some leaks

Blurry — responsibilities overlap

Hard to identify where things belong

Non-existent — big ball of mud

Everything depends on everything

💡

Boundaries enable autonomy

Clear boundaries mean teams can work independently. Blurred boundaries mean coordination overhead. The best architectures allow teams to move fast without stepping on each other.

🏗️ Architecture

How many layers of "temporary" fixes exist?

Few — most hacks are cleaned up

Technical debt is actively paid down

Some — a backlog of known issues

Documented but not addressed

Many — layers of workarounds

Hacks on top of hacks

Pervasive — "temporary" is permanent

The whole system is held together with duct tape

💡

Temporary becomes permanent without intention

Every "quick fix" you don't revisit becomes architecture. Technical debt compounds. The difference between good and great teams isn't avoiding debt — it's paying it down systematically.

🏗️ Architecture

How current are your dependencies?

Current — regularly updated

No major version behind

Recent — within 1-2 major versions

Some upgrade work needed

Dated — multiple major versions behind

Known security vulnerabilities

Ancient — end-of-life dependencies

Can't upgrade without major effort

💡

Dependency rot is silent killer

Outdated dependencies accumulate security vulnerabilities and block you from modern tooling. Regular updates are cheaper than big bang upgrades. Treat dependency maintenance as ongoing hygiene.

📚 Documentation

How well is your system documented?

Comprehensive — ADRs, runbooks, guides

Anyone can understand the system

Adequate — key decisions documented

Important stuff is written down

Sparse — outdated or incomplete

Documentation exists but isn't trusted

Non-existent — oral tradition only

If the original author leaves, knowledge leaves

💡

Documentation prevents repeated mistakes

Without documentation, every new developer makes the same mistakes. ADRs (Architecture Decision Records) capture context that code can't. Good docs prevent knowledge loss.

📚 Documentation

How accurate is your documentation?

Accurate — kept in sync with code

Updated as part of PRs

Mostly accurate — some drift

Generally trustworthy with gaps

Often outdated — requires verification

Better to read the code

Unreliable — contradicts reality

Documentation causes confusion

💡

Outdated docs are harmful

Wrong documentation is worse than no documentation — it actively misleads. Keep docs close to code. Generate what you can. Review docs as part of code review.

⚡ Velocity

How has your development velocity changed over time?

Improving — getting faster

Better tooling, patterns, practices

Stable — consistent pace

Neither improving nor degrading

Slowing — features take longer

More effort for same output

Crawling — getting worse rapidly

Most time spent fighting the codebase

💡

Slowing velocity is the clearest debt signal

If the same features take longer now than a year ago, debt is winning. Healthy codebases get easier to work with over time. If yours is getting harder, you're accumulating debt faster than paying it.

⚡ Velocity

What percentage of time is spent on "new value" vs "maintenance"?

70%+ on new features

Most time creates value

50-70% on new features

Significant maintenance burden

30-50% on new features

Fighting fires more than building

<30% on new features

Mostly keeping lights on

💡

Maintenance ratio reveals debt load

If most engineering time goes to maintenance, you're not building — you're surviving. This ratio is a key health indicator. The goal isn't zero maintenance, but sustainable balance.

🚀 Deployment

How often do you deploy to production?

Multiple times per day

Continuous deployment

Daily or multiple times per week

Regular, routine deployments

Weekly or bi-weekly

Planned deployment windows

Monthly or less frequently

Deployments are major events

💡

Deployment frequency indicates health

Teams that deploy frequently have lower-risk deployments. Infrequent deployments mean bigger changes, more risk, and more fear. Frequency builds confidence through repetition.

🚀 Deployment

What's your rollback/recovery capability?

Instant — automated rollback

Can revert in seconds

Fast — documented process

Can revert in minutes

Slow — manual and complex

Rollback is stressful event

Non-existent — forward only

If it breaks, we fix forward

💡

Easy rollback enables aggressive progress

If you can't easily undo changes, you'll be conservative. Conservatism feels safe but slows progress. Easy rollback lets you move fast because mistakes are cheap to fix.

Your Codebase Health

out of 100

Critical Moderate Healthy

Category Breakdown

Remediation Priority

Need help paying down technical debt?

Share your results with us. We\'ll help you prioritize and can execute debt reduction in focused two-week sprints.

Discuss Debt Reduction

Free 30-minute consultation

Stuck on your product?

Let’s get you moving again.

We’ll help you unblock, refocus, and deliver — with real developers on your side.

Get Started

Technical Debt Health Check

How long does it take a new developer to be productive?

Onboarding time reveals code health

When you make changes, how often do unexpected things break?

Tight coupling creates fragility

How would you describe your code's readability?

Code is read far more than written

What's your test coverage situation?

Tests enable refactoring

How reliable are your tests?

Flaky tests are worse than no tests

How fast is your test suite?

Slow tests kill productivity

How well-defined are your system boundaries?

Boundaries enable autonomy

How many layers of "temporary" fixes exist?

Temporary becomes permanent without intention

How current are your dependencies?

Dependency rot is silent killer

How well is your system documented?

Documentation prevents repeated mistakes

How accurate is your documentation?

Outdated docs are harmful

How has your development velocity changed over time?

Slowing velocity is the clearest debt signal

What percentage of time is spent on "new value" vs "maintenance"?

Maintenance ratio reveals debt load

How often do you deploy to production?

Deployment frequency indicates health

What's your rollback/recovery capability?

Easy rollback enables aggressive progress

Category Breakdown

Remediation Priority

Need help paying down technical debt?

Let’s get you moving again.

Technical Debt
Health Check