I am a...
Learn more
How it worksPricingFAQ
Account
May 19, 2026 · 12 min read · Cadence Editorial

How to hire a developer to fix tech debt

hire developer to fix tech debt — How to hire a developer to fix tech debt
Photo by [Jakub Zerdzicki](https://www.pexels.com/@jakubzerdzicki) on [Pexels](https://www.pexels.com/photo/developer-reviewing-code-on-tablet-in-office-36598855/)

How to hire a developer to fix tech debt

To hire a developer to fix tech debt, hire a senior generalist with low ego and codebase-archaeology skills, not a junior with extra time. Pay $1,500 to $2,000 per week for a 4 to 8 week scoped engagement, require a week-1 tech-debt inventory before any code changes, and rank cleanup work by interest rate (cost of keeping the debt) not by how ugly the code looks.

Tech debt cleanup is the single hiring scope where founders make the most expensive mistake. They ask a junior to "clean up the codebase" because seniors are busy shipping features. Six weeks later, the codebase has the same debt plus a half-finished refactor nobody else can navigate. The right hire for this work looks nothing like your feature-velocity hire, and the scoping conversation matters more than the resume.

What a "tech debt" engineer actually looks like

The pattern that works is a senior generalist with five-plus years of production experience, low ego, and a measurable preference for reading code over writing it. They are excited by the phrase "git blame" the way most engineers are excited by greenfield projects. They ask "why does this exist?" before "how do I delete this?"

Concrete traits to screen for:

  • Codebase archaeology skills. They can read a 4-year-old PR thread and reconstruct the constraint that made the code look the way it does. They run git log --follow and git log -S "function_name" without thinking about it. They know that the weird if (env === 'staging-2') branch probably exists because of a customer migration in 2023, and they go find proof before deleting it.
  • Comfort with ambiguity. Debt cleanup rarely has clear acceptance criteria. The engineer needs to define "done" themselves and defend the definition. Juniors freeze without a Linear ticket; seniors write the ticket.
  • Low ego. They will not propose rewriting the codebase in week 1. They will not deride your prior contractors. They will treat the existing code as evidence, not embarrassment.
  • Refactor discipline. They make small, reversible, atomic commits. Each commit passes tests. They never mix "rename variable" with "extract function" with "fix bug" in the same PR. This sounds basic; most engineers do not actually do it.
  • AI-native instincts. They use Cursor or Claude Code to map dependency graphs across thousands of files in minutes, then verify the AI's claims by reading the actual call sites. Every engineer on Cadence is AI-native by default, vetted on Cursor / Claude / Copilot fluency before they unlock bookings, which matters disproportionately for debt work because the cleanup-to-feature ratio inverts: you spend 70% of your time understanding and 30% writing.
  • Kindness. They will be looking at code your team wrote in worse conditions. Engineers who say "lol who wrote this" in code reviews are the wrong hire. You want the engineer who says "this looks like it was load-bearing for the Stripe migration, let me check before I touch it."

The seniority floor matters. A mid-level engineer can do scoped debt work (Mid, $1,000/week) once a senior has produced the inventory and prioritization. They cannot do the inventory themselves, because the inventory is a judgment call.

Audit-first vs ship-while-cleaning

Two scoping models work. Most teams pick the wrong one.

Audit-first means the engineer spends week 1 producing a tech-debt inventory and a prioritized cleanup plan, ships nothing, then executes the plan in weeks 2 through N. This is right when: your team is below 8 engineers, you do not have a clear catalog of debt, you suspect debt is blocking velocity but cannot point at specific items, or you have been burned by previous "cleanup" engagements that produced nothing measurable.

Ship-while-cleaning means the engineer joins a feature team and pays down debt opportunistically inside the feature work they ship. This is right when: you already know exactly what the debt is (a senior wrote a doc last quarter), the debt is concentrated in a few files you actively touch, and you do not want the political cost of an engineer "not shipping" for a week.

The default failure mode is picking ship-while-cleaning when you should pick audit-first. Without an inventory, the engineer cleans whatever they happen to touch, which is usually feature-adjacent code, which is usually the cleanest part of the codebase already. The actual debt (the 2021 auth module nobody understands) goes untouched.

Here is the trade-off table founders typically need to see written down:

ModelWhen to useWeek-1 outputRisk
Audit-first<8 engineers, no debt catalog, velocity is droppingTech-debt inventory + ranked plan"Nothing shipped" optics in week 1
Ship-while-cleaningDebt is documented and localized, feature work is ongoing in the debt areaShipped feature + 2-3 cleanup PRsCleanup happens where it is easy, not where it matters
Hybrid (recommended for 4+ week engagements)Most casesInventory by Friday of week 1, ship from week 2Requires a senior who can context-switch

For most 4 to 8 week engagements, the hybrid model wins. The engineer produces a lightweight inventory in 3 to 4 days, you agree on the top 3 debts to pay, then they ship cleanup PRs from week 2.

Week-1 deliverable: the tech-debt inventory

The single artifact that makes or breaks a debt engagement is the week-1 tech-debt inventory. Without it, the engineer is guessing. With it, you have something to argue about.

A good inventory has 15 to 40 items, each with:

  • Location. File paths, modules, or system boundaries. Specific.
  • What the debt is. One sentence. "Auth middleware re-fetches the user object on every request because session cache was removed during the 2024 Redis migration and never restored."
  • Why it exists. The historical reason. "Stripe webhook signature verification was added in a hurry for the 2023 PCI audit; the verification function is duplicated in 4 places."
  • What it costs you per month. This is the interest rate. Engineer hours lost, customer incidents caused, features blocked, compute spend wasted, onboarding friction added. Estimate, do not hand-wave.
  • What it costs to fix. Engineer days, dependency on other work, risk of breakage.
  • Blast radius. What breaks if the fix goes wrong.
  • Confidence level. How sure the engineer is about the cost and the fix. Low-confidence items need a spike first.

Most inventories produced by mid-level engineers list 60 items with no costs attached. That is a list, not an inventory. The "what it costs you per month" column is where senior judgment lives.

A useful sibling read here is how to manage technical debt in a startup, which goes deeper on the rolling inventory discipline once you have one cleanup pass behind you.

Picking which debt to pay first

Engineers love to clean what offends them aesthetically. Founders love to clean what makes a demo look bad. Neither is the right ranking.

The ranking that works is interest rate: pay down the debt that is costing you the most per unit of time, weighted by how cheap the fix is. Borrow the framing from finance. A 27% APR credit card gets paid before a 4% mortgage even though the mortgage balance is larger.

The formula in practice:

Priority = (monthly cost of keeping the debt) / (engineer-days to fix it)

Rank the inventory by this score. Pay the top 3 to 5 items first. Re-rank after each one ships because fixing one debt often changes the cost of the others.

Concrete examples of high-interest debt:

  • Flaky test suite that everyone re-runs. If 12 engineers each re-run CI twice a day at 4 minutes per re-run, that is 96 wasted minutes per day, plus the morale tax. Often fixable in 2 to 5 days. Extreme interest rate.
  • Build that takes 18 minutes. Same math. A senior who knows webpack or turbopack can usually cut this in half in a week.
  • Manual deploys that block Friday releases. The cost is invisible until you count the features that did not ship.
  • Auth or billing code nobody understands. The cost shows up the next time you need to change either. Worth paying down before you have to.

Examples of low-interest debt that founders over-prioritize:

  • Code that is ugly but stable. It offends the engineer. It does not cost the business anything. Leave it.
  • Dependency upgrades that have no security or feature payoff. Upgrading React 18.2 to 18.3 because it is "current." Cost: 3 days. Benefit: zero. Skip.
  • Folder structure refactors. Renaming /utils to /lib does not pay down debt. It generates merge conflicts for everyone else for two weeks.

Where to find the right engineer

The market for "fix my tech debt" engineers is thinner than the market for feature engineers because the work is unglamorous and the resumes do not write themselves. Here is the realistic channel breakdown:

  • Your existing senior network. The best debt engineers are usually people who have already shipped at one of your friends' companies. Ask for warm intros to engineers who like cleanup work. About 1 in 8 senior engineers actively prefer it. They are easy to keep on a 6-week engagement because nobody competes for them.
  • GitHub. Look for engineers whose recent commits are refactors, dependency updates, and bug fixes, not greenfield features. Their PR descriptions matter more than their starred repos.
  • Toptal, Lemon.io, Arc. These curated freelance networks have senior engineers, but the matching is usually optimized for feature velocity. You will need to filter hard during the intro call.
  • Cadence. Booking, not recruiting. Spec the work as "8-week tech-debt cleanup on a Next.js + Postgres codebase, senior tier, expect a week-1 inventory before any merges." Match arrives in about 2 minutes from a 12,800-engineer pool. The 48-hour free trial means you can have the engineer produce a one-page inventory sketch before you commit to week 1. Every engineer is AI-native, which matters here because mapping a 50,000-line codebase in a day is now possible.
  • Full-time hiring. Wrong instrument for this scope. Hiring a full-timer for a 6-week cleanup means 90 days to source, 30 days to ramp, and then you have a full-timer with nothing to do.

Adjacent reads on hiring shape: hiring a senior staff engineer when the debt is architectural and crosses systems, and hiring on Toptal in 2026 when you want a curated freelance route with longer onboarding.

What it costs

Honest market rates for a senior generalist doing 4 to 8 weeks of tech-debt work:

ChannelWeekly costTime to startNotes
Senior network referral$2,000 to $4,000/wk1-3 weeksHighest signal, slowest start
Toptal$4,000 to $7,000/wk equivalent (hourly)1-2 weeksStrong vetting, premium pricing
Lemon.io / Arc$2,500 to $4,500/wk1-2 weeksDecent vetting, mid pricing
Upwork senior contractor$1,500 to $5,000/wk3-7 daysWide quality range, you screen
Cadence (Senior, $1,500/week)$1,500/wk~2 minutes match, 48hr trialWeekly billing, AI-native baseline, replace any week
Cadence (Lead, $2,000/week)$2,000/wk~2 minutes matchFor debt that requires architectural judgment
Full-time hire$150k-$220k base + equity60-120 daysWrong instrument for scoped cleanup

For most 4 to 8 week debt engagements, the right tier is Senior, $1,500/week. Drop to Mid, $1,000/week only after the senior has produced and prioritized the inventory and the remaining items are well-defined.

If you have not validated whether the cleanup is a one-time pass or an ongoing concern, the weekly-billing model wins on optionality. If you have validated and the answer is "ongoing," consider a full-timer.

Red flags during the interview

These get the engineer eliminated:

  • "I would rewrite this in [framework]." Almost always wrong, and the kind of answer that destroys 6 months of company time. The right answer is "I would understand it first, then propose targeted changes."
  • "How long until I can refactor the database schema?" They have not earned that permission yet. Engineers who reach for the schema in week 1 are dangerous.
  • No questions about your test coverage, your deploy process, or how rollbacks work. Debt engineers who do not ask about safety nets do not understand how cleanup goes wrong.
  • Cannot describe a debt cleanup they previously shipped, with numbers. "I reduced our CI time from 14 minutes to 6 by moving 80% of unit tests off the main runner" is the answer you want. Vague answers about "improving code quality" are disqualifying.
  • Talks more than they listen in the intro call. Debt work is 70% listening to context. If they cannot listen to a founder describe a codebase for 20 minutes, they cannot listen to the codebase.
  • Dismissive about the existing team. Even if your team is junior, an engineer who signals contempt will burn down your trust faster than the debt will burn down your velocity.

Green flags:

  • They ask to see the codebase before quoting a timeline.
  • They propose a 48-hour or 1-week paid trial themselves.
  • They mention "reversibility" or "atomic commits" without prompting.
  • They want to write the inventory before they want to write code.

What to do next

If you have a debt list and a clear sense of priority, post a scoped 4-week senior contract and reference our debt-management framework for how to keep the cleanup from re-accruing.

If you do not have a debt list, do not skip the inventory step. The fastest path is to spec a 1-week audit (or use Cadence's 48-hour trial to have a senior produce a sketch inventory) before committing to the full engagement. The audit costs one week. Skipping it usually costs four.

Cadence matches founders to senior engineers in about 2 minutes, with a 48-hour free trial and weekly billing. If you want a senior to produce a tech-debt inventory by Friday, tell us the scope and the match is auto-generated against your spec.

Adjacent reads if the debt is concentrated in a specific surface: how to hire a design engineer for frontend debt that has accumulated as UI inconsistency, and how to hire a Flutter developer for mobile codebases that have outgrown their original architecture.

FAQ

How long does it take to clean up tech debt?

A reasonable scope is 4 to 8 weeks for a single cleanup pass on a startup codebase (under 200k lines, fewer than 12 engineers). Larger codebases or distributed systems can take 12 weeks. If someone quotes "2 weeks" for "all the debt," they have not looked at the codebase yet.

Should I hire full-time or contract for tech debt work?

Contract for the first pass, almost always. Tech debt cleanup is a finite scope with a defined endpoint. Hiring a full-timer commits you to 12 months of salary for 8 weeks of work, plus you spend 60 days hiring them before the cleanup starts. Hire a senior contractor on weekly billing, ship the cleanup, then evaluate whether the rate of new debt justifies a full-time platform engineer.

Can a junior or mid-level engineer fix tech debt?

A mid-level engineer (Mid, $1,000/week on Cadence) can execute cleanup once a senior has produced the inventory and ranked the priorities. They cannot produce the inventory themselves because that requires judgment about cost-per-month and blast radius. Juniors should not own debt work at all; the failure mode (half-finished refactor nobody else understands) is worse than the debt they were hired to fix.

What's a fair rate for a tech-debt engineer in 2026?

For a senior generalist, $1,500 to $4,000 per week depending on channel. Toptal and direct senior referrals sit at the high end ($3k to $4k). Curated marketplaces like Cadence sit at $1,500 for Senior tier and $2,000 for Lead tier with weekly billing. Hourly rates of $80 to $180 are common for the same engineers; the weekly model usually nets out cheaper because the engineer is not padding hours.

How do I know if my codebase actually has tech debt or if engineers are just complaining?

Three measurable signals: (1) median PR time has grown more than 50% over 12 months, (2) onboarding a new engineer to first shipped PR takes more than 10 days, (3) a customer-facing incident in the last 90 days had a root cause of "we did not understand the existing code." If two of three apply, you have debt worth paying. If zero apply, the engineers are venting about style.

All posts