Skip to main content
Background Image
  1. Services/

Technical Debt Triage

3 mins·
Author
Glen Baker
Building tech startups and open source tooling
Table of Contents

Your team knows there is technical debt. The expensive question is what to fix first.

I help engineering teams turn vague refactoring concerns into a ranked, reviewed, low-risk improvement plan. The work starts with evidence, filters out noise, and ends with focused pull requests your team can safely review and merge.

What You Get
#

  • A risk-ranked technical debt report
  • Clear explanation of why each item matters
  • Before/after Debtmap analysis
  • Focused refactor recommendations
  • Senior engineer review before anything reaches your team
  • Optional pull requests for the highest-leverage fixes

This is not a generic lint report. The goal is to find debt that is likely to slow delivery, increase bug risk, or make future changes harder than they need to be.

How It Works
#

1. Baseline Analysis
#

I run Debtmap against your codebase and, where available, combine static analysis with coverage and git history. The result is a prioritized view of technical debt by risk rather than a flat list of code smells.

2. Engineering Review
#

Tool output is only a starting point. I review the highest-ranked findings, remove false positives, and identify which issues are worth acting on now.

3. Refactor Plan
#

You receive a short plan that explains the highest-impact debt items, expected risk reduction, tradeoffs, and recommended sequence of work.

4. Assisted Fixes
#

For selected items, I produce small, scoped changes that are designed for review rather than a sweeping rewrite. The emphasis is on reducing risk without disrupting the team.

5. Verification
#

I rerun Debtmap and relevant tests to show whether the change improved the targeted risk area. When a change is not worth merging, I say so.

Best Fit
#

This is designed for:

  • Startup engineering teams with 5-50 engineers
  • Codebases where technical debt is slowing feature work
  • Rust or backend-heavy projects
  • Teams preparing for a migration, rewrite, audit, or major feature push
  • CTOs who need a concrete refactoring plan instead of another abstract quality discussion

Not A Fit
#

This is probably not the right fit if you want:

  • A generic static-analysis dashboard
  • Large rewrite projects with no incremental path
  • Procurement-heavy enterprise SAST implementation
  • A report that nobody intends to act on

Engagement Options
#

Technical Debt Audit
#

A focused audit of your codebase with a ranked report and recommended refactoring sequence.

Good for teams that need clarity before committing engineering time.

Audit + Pull Requests
#

The audit plus a small number of reviewed pull requests addressing the highest-leverage issues.

Good for teams that want help turning analysis into mergeable work.

Monthly Debt Management
#

Ongoing technical debt review, refactor planning, and periodic pull requests.

Good for teams that want a steady improvement loop without pausing product work.

Why Me
#

I am a Staff Software Engineer with 14+ years of startup engineering experience, including developer tooling, CI/CD, infrastructure, static analysis, and production engineering. I built Debtmap to answer the practical refactoring question teams actually face:

If everything has debt, what should we fix first?

Start With A Small Scope
#

The first step is a short conversation about your codebase, team size, language stack, and the kind of technical debt that is creating drag.

Email me at [email protected].

Related

About Glen Baker
2 mins
Contact
1 min