Every client has one. A 400-line Python script, or a spreadsheet with a macro nobody remembers writing, or a single Lambda function named process2_final_REAL. It runs invoicing, or reconciles inventory, or emails the founder every morning with numbers nobody double-checks anymore. It has no tests, no owner, and it has not failed once in three years.
I found one last month at a logistics client: a 900-line script that calculated shipping rates across four carriers. It imported a library that stopped being maintained in 2019. It logged to a text file nobody read. And it was, without question, the most reliable piece of infrastructure in their stack — better uptime than their actual API.
The bug was never in the code
The instinct, mine included, is to call this technical debt and schedule a rewrite. That instinct is usually wrong, or at least aimed at the wrong target. The code itself is rarely the problem. Ugly code that's been running unattended for three years has survived every edge case reality could throw at it — that's not a liability, that's the most battle-tested code in the building. Rewriting it doesn't pay down debt, it resets the clock on a system that already finished paying it.
The actual problem is that nobody owns it. Ask who's responsible for that script and you get a shrug, or a name of someone who left in 2022. Nobody's on call for it. Nobody knows what happens if the carrier changes their rate API format. It works, which is exactly why it's terrifying — the day it breaks, the person debugging it will be seeing that code for the first time, under a deadline, with the CEO asking why shipments stopped calculating.
That's the actual definition of technical debt I've settled on after doing this for a while: not "code that's old" or "code that's ugly," but code that works and that nobody could safely change if they had to. Debt isn't a property of the code. It's a property of the org chart.
What I actually do about it
I stopped pitching rewrites for these and started pitching something cheaper and more honest: assign an owner, write down what it does and why in plain language, and add one thing — just one — that tells a human when it stops behaving the way it always has. Not a full observability stack. A single alert that fires when the output looks nothing like yesterday's.
That's it. No rewrite, no migration project, no six-week timeline that turns into six months. The script keeps running exactly as it has for three years, except now someone would find out within the hour if it stopped, instead of finding out three weeks later when a customer complains that their shipping quote is $4,000 for a package that should cost $40.
We ended up formalizing this into how we scope engineering work for clients — before touching a legacy system, we ask "who owns this and how would we know if it broke," not "how do we rewrite this properly." Half the time the honest answer to the first question fixes more risk than the rewrite would have.
The takeaway
If you're staring at a piece of code that scares you, resist the urge to schedule its replacement before you've asked who's accountable for it and whether anyone would notice if it went quiet. A feared, unowned system that works is still less risky than a freshly rewritten one that hasn't been tested by three years of real traffic yet. Fix the ownership gap first. The code has already proven itself — it's the org chart that never got updated.