> ## Content Index
> Fetch the complete content index at: https://emrizki.my.id/llms.txt
> Use this file to discover other available public pages before exploring further.

# Technical debt has an interest rate
- URL: https://emrizki.my.id/writing/tech-debt-time-value-of-money/
- Published: 2025-12-12T13:04:00.000Z
- Updated: 2026-10-25T13:01:19.000Z
- Description: The time value of money explains why small shortcuts become expensive. Treat technical debt like a loan and the trade offs get clearer.
- Author: Muhammad Rizki
- Tags: Finance, Architecture, #Import 2026-10-25 12:59

Every shortcut I ever took in code came with an interest rate. Nobody told me the rate.

![Hand drawn sketch for "Technical debt has an interest rate", with a stick figure saying "just one tiny hack..."](https://emrizki.my.id/content/images/sketches/03-tech-debt-time-value-of-money.png)

Sketch by me. The stick figure says: "just one tiny hack..."

Everyone in tech uses the phrase "technical debt." Very few of us take the word "debt" seriously.

I did not, for a long time. Then I sat through finance lessons on the time value of money, and I realised the metaphor is closer to an accounting truth than most engineers admit.

## A rupiah today is worth more than a rupiah tomorrow

The core idea is simple. Money now is worth more than the same money later, because money now can be invested and grow. Run that backwards and you get compounding. A small amount owed today becomes a bigger amount owed later, if interest keeps adding up. (If your bank worked like this, you would close the account.)

Technical debt behaves exactly like this. A shortcut saves you time today. That saved time is real and sometimes very valuable. But every week that the shortcut stays in place, it charges interest. The interest is paid in slower changes, more bugs, longer onboarding, and nervous releases.

## A story from switching

In one banking integration job, we needed to add a new message type to a switching flow quickly. The proper way was to extend the message mapping layer. The fast way was to add a special case directly in the routing code. We chose fast. The launch went well.

A few months later there were three more special cases. Then six. Nobody wanted to touch the routing code anymore because nobody fully understood it. A change that should take one day took a week, plus a long weekend of testing.

That week was the interest payment. We had borrowed four days and were now paying back much more, every time.

## Not all debt is bad

Here is where finance helps again. Companies borrow on purpose. Debt is a tool. A business with no debt at all may be moving too slowly. The question is never "debt or no debt." It is "what rate am I paying, and is the return worth it?"

Technical debt is the same. Taking a shortcut to hit a regulatory deadline can be a great decision. Taking a shortcut because nobody wanted to write tests is a bad loan at a terrible rate.

## Ask three questions

When my teams consider a shortcut now, I ask three things.

1. What do we gain right now, in plain terms? A launch date, a customer, a demo?
2. What is the interest? Which future changes will this make slower, and how often do we expect them?
3. When do we pay it back, and who owns that?

If nobody can answer the third question, nobody decided anything. The debt was an accident.

## AI agents change the maths a little

AI agents can now refactor code much faster than before. That lowers the cost of paying debt back, which is good. But it also tempts teams to take more shortcuts, because "the agent can clean it up later." Later still compounds. An agent cleaning up a mess still needs a human who understands what the code is supposed to do.

The awkward part is that I have written plenty of these loans myself. Some of them are probably still running in production, quietly charging interest to someone who never met me.