Tech debt.
aka technical debt, code debt, legacy code
Shortcuts in software you take today and pay for, with interest, later.
What it actually means
Tech debt, short for technical debt, is the future cost of choosing a quick or limited solution in software instead of a better one that would take longer. Like financial debt, it can be useful in the short term, but it builds interest: every later change becomes slower, riskier and more expensive until someone pays it down.
Tech debt shows up whenever a team says "we'll fix it properly later". Maybe they skipped tests to hit a launch date, copied the same code into five places, or kept an old system running because replacing it felt too big. None of this is visible to customers at first. The product works. But the next feature takes twice as long, a small change breaks something unrelated, and new engineers need weeks to understand how anything fits together. That slowdown is the interest payment.
The nuance is that tech debt is not always a mistake. Like a loan, it can be a smart choice: shipping fast to test an idea can be worth more than perfect code nobody uses. The problem is debt nobody tracks or plans to repay. Some debt is deliberate, some comes from rushed work, and some simply appears as tools and needs change over time. Good teams name it, write it down and set aside time to reduce it, often a share of every sprint, before it quietly eats most of their capacity.
Where you'll hear it
We can ship the new checkout in two weeks, but only by adding more tech debt. If we want the next three features on time, we need a sprint to clean up first.
Translation: the fast option will slow us down later, so let's budget time now to fix the shortcuts we already took.
Also in budget talks, where leaders weigh new features against refactoring; in due diligence, where buyers of a software company ask how much tech debt they are inheriting; and in incident reviews, where an outage gets traced back to a shortcut nobody ever went back to fix.
The pop-culture version
You are in a rush, so you throw clothes on the chair instead of putting them away. It saves five minutes. Tomorrow you do it again. Nothing terrible happens. The room still works. You can still find most things if you dig.
A few weeks later, finding a clean shirt takes ten minutes. You trip over a bag every morning. A friend is coming over and now cleaning takes a whole afternoon instead of the five minutes a day you skipped. That growing cost is the interest.
Software works the same way. Each shortcut feels small. Together they make every change slower and riskier. Tech debt is the gap between the room you have and the room you would have if you had tidied as you went.
The practical rule: taking on tech debt is fine when it is a conscious choice with a plan to repay it. Write it down, estimate its cost, and schedule time to fix it before it becomes the whole job.
Say it like you mean it
“We took on some tech debt to hit the launch date, so let's plan a cleanup sprint next quarter.”
It treats tech debt as a deliberate trade-off with a clear plan to pay it back.“Tech debt is the money we still owe the software vendor.”
Tech debt is about the hidden cost of shortcuts in code, not an unpaid invoice.You will also hear "refactoring", which means improving how code is built without changing what it does, and "legacy system", an older system that still works but has become expensive and risky to change.
An in-depth look at how technical debt builds up as a hidden liability and how it can be measured before it damages enterprise value.
Decoded next
Decoded by the Kurums editorial team. Kurums Decoded translates the language of business for people who are new to it. Definitions are kept short on purpose; the serious version above goes deep. Nothing here is financial, legal or career advice.
Discover more from Kurums | Business Intelligence
Subscribe to get the latest posts sent to your email.
