The Business Case for Refactoring (in Money)

TL;DR: "We need to refactor" loses to "we need to ship" every single quarter. And it should: as stated it isn't a business case, it's a mood. The version that wins states what the mess costs per month, what the fix costs once, and when the lines cross. That is the entire trick. Refactoring is a cost-reduction investment with a payback period, and the moment you present it in those terms it competes for budget like everything else. Here is how to build that case with numbers a budget owner can check, and the three ways engineers routinely sabotage it.

Why "the code is bad" never gets funded

Every failed refactoring pitch has the same shape: an engineer describes suffering, a manager asks "what do we get?", and the honest answer on the table is "better code." That answer loses not because leadership is philistine but because it is unpriceable. Budget owners fund comparisons - this spend versus that return - and a pitch with no number on either side cannot be compared against a feature that claims revenue.

Meanwhile the actual price of not refactoring is enormous and largely invisible. Stripe's Developer Coefficient survey (with Harris Poll; more than 1,000 developers and 1,000 C-level executives) found developers reporting 17.3 hours of a 41.1-hour average week going to maintenance work (bad code, debugging, refactoring, modifying), with 59 percent agreeing the time spent on bad code is excessive (Stripe, 2018). McKinsey's CIO survey found 10 to 20 percent of the new-product technology budget diverted to resolving tech-debt issues (McKinsey).

The money is already being spent - silently, as drag. A refactoring business case does not ask for new money; it asks to convert an unmanaged recurring cost into a one-time investment. Framed that way, you are the fiscally conservative one in the room.

The refactoring business case in four numbers

A fundable proposal fits on one page and carries four figures:

1. The interest. What the target area costs per month, today: hours actually sunk into working in and around it, multiplied by your fully loaded cost per engineer-hour. Use the same disclosed-share method as any honest technical-debt pricing: measured time share, stated assumptions, no drama.
2. The principal. The one-time cost of the fix, scoped like real work: an estimate with a range, named engineers, and an explicit definition of done. Not "clean up the billing module" but "extract these three responsibilities, delete the duplicated variant logic, get the change-lead-time for this area back under the team norm."
3. The payback period. Principal divided by monthly interest. Illustrative shape only: if a hotspot burns forty engineer-hours a month and the fix costs three hundred, the fix pays for itself in under a year and everything after is margin. If the payback period is longer than the code's remaining life, the case honestly fails. Knowing that is also a win, because not all debt is worth paying down.
4. The trend. Which way the interest is moving. This is where the argument gets urgent, because the industry-wide direction is wrong: GitClear's analysis of 623 million code changes found code-block duplication up 81 percent and refactoring-style moved code collapsing from 21 percent of changes to 3.8 percent in the AI-assisted era (GitClear, 2026). Teams are adding copies faster and consolidating less than at any point in recent history. The interest rate is rising while the discipline that pays it down atrophies. Your own rework rate tells you whether your codebase is on that curve.

Evidence to bring: receipts beat adjectives

The four figures get you a hearing. The receipts get you believed. Attach three concrete exhibits:

• The estimate graveyard. Two or three changes in the target area that blew their estimates, with the before/after numbers and a one-line reason each. This lands harder than any aggregate, because the audience remembers those tickets.
• The defect concentration. The share of recent bugs and rework tracing to the hotspot. Reviews are already telling you this, quietly: research classifying defects found in code review shows 75 percent are evolvability defects - understandability and maintainability, not broken functionality (Mäntylä & Lassenius, 2009). Your reviewers have been flagging the interest payments all along; the business case is where those flags finally get counted.
• The avoidance behavior. The features that were scoped around the mess, the small-PR discipline that dies in this one module, the one engineer everything in that area routes through. Avoidance is cost wearing a disguise.

One more framing card worth playing: substantial, scoped improvement work is investment in an asset, and depending on your accounting regime some of it may belong in the CapEx conversation rather than the period-cost bucket. Lead with payback, not with this. But finance audiences hear "investment with capitalizable characteristics" very differently than "cleanup."

How to package it: hotspot, not crusade

The proposals that get approved share a shape:

• Scoped to a hotspot, not a codebase. "Fix the worst module, measured by interest paid" is fundable. "A quality quarter" is not: it has no edges, so it has no price, so it has no payback date.
• Sequenced by return. Rank candidate hotspots by monthly interest and fix the top of the list. This also keeps you honest: cold code with ugly internals ranks low because it charges low interest, no matter how much it offends the senses.
• Instrumented before and after. Declare the success signals up front - hours in area, defect share, change lead time - and report them after. One refactoring with a measured payback buys credibility for the next five proposals. One vague "it feels better" spends it.
• Not a rewrite. A rewrite is a different instrument with a different risk profile: principal balloons, interest keeps accruing on the old system during the transition, and delivery risk spikes. If the honest scope is "replace the system," write that case instead, with those risks priced in. Do not smuggle a rewrite in a refactoring costume; budget owners have seen the movie.

The door

Pick the module your team already complains about - there is always exactly one obvious candidate. Spend one afternoon building the four numbers: last month's hours in and around it at loaded cost, a scoped estimate for the fix, the division, the trend. Attach two receipt tickets. That is the whole artifact: one page, checkable arithmetic, a payback date. Put it in the next planning cycle as a line item alongside the features, and let it compete on the same terms. The moment refactoring shows up with a number, it gets funded like anything else. Unlike the mess it fixes, that skill compounds in your favor.