A feature request that used to take two days now takes two weeks, and nobody can tell you exactly why. The honest answer is usually some version of "it's complicated in there." That complication has a name: technical debt. It isn't a developer complaint. It's a real cost sitting on your books, you just haven't seen it itemized.
Technical debt is what builds up when software gets built with shortcuts, under deadline pressure, with the plan to clean it up later. The analogy is a loan: you borrow time now by skipping a proper fix, a test, a bit of cleanup, and pay it back later with interest, in the form of slower work and more bugs. Taking the loan isn't always a mistake. Shipping a working version two weeks early so you can start getting paying customers is often the right call. The problem is almost nobody comes back to repay it, because there's always a next deadline.
It shows up in ordinary ways. The same piece of logic copied into three different places because nobody had time to build it once, properly, and reuse it. A library three major versions out of date because upgrading might break something and nobody wants to be the one who finds out. A workaround for a bug that was supposed to be temporary, written two years ago, that half the codebase now quietly depends on. None of it looks dramatic on its own. It accumulates.
The cost is what it does to everything that comes after it. Changes that should be simple require someone to first understand a tangle of code nobody fully remembers writing. Bugs get harder to track down because a fix in one place has side effects three files away that nobody predicted. Estimates stop meaning anything, because "how long will this take" quietly becomes "how long will this take, plus however long it takes to untangle the part we're touching." And every outdated dependency sitting there is also a security exposure nobody's actively managing.
-
It's not the same thing as bad code. A well-built system taking on debt deliberately, to hit a real deadline, with a plan to revisit it, is a normal and often smart business decision. The debt that actually hurts is the kind nobody decided to take on, it just accumulated because nobody was looking.
-
It compounds. A shortcut that costs you an extra hour today costs more the longer it sits, because more code gets built on top of it, and untangling it later means untangling everything that now depends on it too. The same fix is always cheaper now than in a year.
-
There are tells. If estimates for simple-sounding changes keep coming back high, if there are files or features your team is visibly reluctant to touch, if "quick fix" requests keep turning into multi-day investigations, you're carrying more debt than you think, whether or not anyone's called it that out loud.
-
Paying it down doesn't mean stopping everything to rewrite the system. The businesses that manage this well treat cleanup as a normal part of the work, not a separate project: when you're already touching a messy piece of code to add a feature, you fix the mess while you're in there, instead of adding one more shortcut on top of it. A little, consistently, beats a big rewrite that gets deprioritized the moment something urgent comes up.
-
A full rewrite is rarely the answer, and be skeptical of anyone who suggests it as the first move. Rewrites are expensive, slow, and routinely underestimated, and they put the whole system at risk at once instead of improving it gradually. Targeted cleanup of the parts that are actually causing pain almost always beats starting over.
If your team keeps saying a simple-sounding request "isn't that simple," that's worth taking seriously, not as a complaint about the code but as information about where your money is actually going. We look at what's really slowing things down before recommending anything, cleanup, a partial rewrite, or just leaving a working part of the system alone, and you get a straight answer from the person who looked at the code, not a sales pitch for a bigger project than you need.
Technical debt and the off-the-shelf-vs-custom decision are two sides of the same coin: both are about how much you're willing to pay later for what's convenient now. Off-the-shelf or custom software? Here's how to actually decide if you're facing that choice from scratch. And if the symptom you're actually seeing is a slow site rather than slow development, here's a real diagnostic checklist. Either way, it's exactly what our Support & Maintenance work is for.
Have a project in mind?
Start a project