Tech debt in plain money: stop saying architecture

Three times I explained refactoring by saying "architecture" — and three times I got a polite "sure, but let's ship features first." Then I changed one thing: instead of "architectural debt," I said "this component adds about 6 hours to every new delivery type we add. Last quarter that was 18 hours we didn't have to spend." The client said: "Okay, take a week."

I don't use the word "architecture" in client conversations anymore. It's not wrong. It just works against me.

Why "architecture" is the wrong word

When you say "architecture," a non-technical client hears roughly this: "You need to pay for something unclear, that broke for unclear reasons, and after we fix it you won't notice any difference."

That's not cynicism — it's just how the word lands. "Architecture" is technical, internal, non-product. It has no obvious financial consequence. So whoever's holding the budget moves it into a mental category labeled "developer housekeeping."

This holds even for technically literate clients — CTOs, product owners, founders who built their first product themselves. The word still puts them in a passive position. They have to trust you on faith, and that's uncomfortable for anyone who's accountable for a budget.

Engineers with an owner mindset translate differently. Not "this is poorly structured" but "this is costing us money." Not in the abstract — in hours, in release delays, in the last incident.

Three numbers non-technical people actually hear

Not all metrics land the same way. I've settled on three.

Time to next feature. The most direct. "Adding a new delivery type currently takes 6 hours because the list is hardcoded in four places. If we move it to config, that drops to under an hour." The client does the math: three delivery types a year, 18 hours of overhead. That's a number they can weigh against a sprint.

Incident frequency. Harder to sell, but works if there's a real example. "This module broke twice last quarter. Four hours to restore it each time, plus the client support load." That stops being abstract debt and becomes observable cost.

Recovery cost at critical failure. The hardest to hear, and sometimes the only thing that moves legacy debt. "If this component fails during peak season, we're looking at a minimum three days to restore. That's X in lost sales." Use this sparingly — it can feel alarmist — but for genuinely fragile systems it's the honest framing.

You don't need all three. One is enough, if the number is real and the client can verify it.

How to turn hours into a business case

Before any conversation about refactoring, I do one exercise: I pick a recent task that ran long or hit an unexpected wall, and I trace where the time actually went.

It's almost always one of three things:

logic that's hardcoded where a parameter should be
no tests on edge cases, so every change needs manual verification
two modules that know about each other directly, so touching one breaks the other in non-obvious ways

For each, you can estimate: "how many hours did this cost us this time" and "how many will it cost every time in the future if we don't fix it."

A real example: a Bitrix-based e-commerce project had a delivery management component where the list of delivery types was hardcoded directly into a PHP template. Adding a new type meant editing four separate places instead of one, with no tests anywhere in the path. Each addition took roughly 6 hours with verification. We rewrote the component over two days — subsequent additions took under an hour each.

When I brought that number to the client, the conversation took 10 minutes.

The script: symptom → number → proposal

The structure I've landed on is simple:

First: name a symptom the client already noticed. Not "we have architectural debt" — "remember when we redid the delivery form three times?" or "you asked why the last release took a week instead of two days?"

Second: give one number, in concrete units. "That component adds about 6 hours to every change of this type."

Third: make a specific proposal. Not "we need to refactor the architecture" — "in 16 hours we remove this. The next three tasks of this type will take 12 hours less combined. It pays back at the third task."

This isn't sales framing — it's just honest accounting. The client is already paying these costs. They just can't see where the bill is coming from. Your job is to make the line item visible.

One more thing: anchor to real tasks, not hypothetical ones. "Last time this type of work cost us 6 hours" lands harder than "typically this kind of thing takes around 6 hours."

When you shouldn't pitch refactoring at all

Sometimes the conversation isn't needed. If the fix is small enough to do inside a current task — just do it. Boy Scout Rule: leave it slightly better than you found it, without putting every cleanup on the backlog.

A refactoring pitch makes sense when: the work is bigger than half a sprint, it requires pausing other work, or it touches a critical path. Everything else is just normal engineering.

Also: if every conversation about tech debt turns into a negotiation, that's not a debt problem — it's a trust problem. In long-running projects, some decisions need to be made by the engineer without explanation. That's what ownership means. As I wrote in an earlier piece on closing risks, not tickets: the job isn't to close the ticket — it's to close the risk. Sometimes those are the same thing. Often they aren't.

Phrasings that got a yes

A few real constructions from conversations:

"This component adds roughly X hours to any related task. If we have 3 such tasks next quarter, we're paying approximately [3×X]. I can remove it in [Y] hours."

"Last month this module cost us [Z] hours during an incident. Want me to scope what would prevent a repeat?"

"We can ship it now, but the next two tasks in this area will take twice as long. Your call."

That last one works especially well — it doesn't put the client in the wrong, it just gives them the choice. And often they'll ask: "how long would it take to do it properly?"

Replace "architecture" with a number and half the objections disappear.