Technical Debt Is a Loan: What Cheap Software Really Costs You

Technical debt is the extra effort you pay every time you change software that was built quickly or carelessly. It works like a loan: you get something sooner, then you pay interest on it until you repay the principal. Cheap software is not always bad software, but when a low price comes from cutting quality, you are the one who repays.

This guide explains the term in plain language, shows how it appears in a business, and gives you a repayment plan and a list of questions to ask your developer or agency.

What is technical debt?

Martin Fowler, a well-known software author, describes technical debt as a metaphor coined by Ward Cunningham. It treats "cruft", meaning flaws inside the code that make it harder to change, like a financial debt. In Fowler's words, the extra effort it takes to add new features is the interest paid on the debt (Martin Fowler).

Cunningham first wrote about it in a 1992 report on a financial software product: "Shipping first time code is like going into debt. A little debt speeds development so long as it is paid back promptly with a rewrite." He added that every minute spent on not-quite-right code counts as interest (Ward Cunningham, 1992).

Here is the loan in business terms:

Fowler gives a simple example. A feature that would take four days in a clean code base takes six in a messy one. The two extra days are the interest. Cleaning up first takes five days, so it only pays off if more changes are coming (Martin Fowler). Those numbers are an illustration, not measured data. Fowler is open that none of these costs can be measured exactly and that estimates are rough.

Deliberate and accidental debt

Not all debt is the same. Fowler splits it two ways: deliberate or inadvertent, and prudent or reckless (Martin Fowler).

• Deliberate and prudent. The team knows it is cutting a corner to reach a release, and has weighed whether the earlier launch is worth the cost of repairing it later.

• Deliberate and reckless. The team knows better practice but goes "quick and dirty" because it thinks it has no time. Fowler calls this usually reckless, because people underestimate how soon the shortcut starts to slow them down.

• Inadvertent and reckless. A team that does not know good design practice takes on debt without realising how much it owes.

• Inadvertent and prudent. A good team builds well, then learns what the design should have been. Fowler says this kind is inevitable, even on strong projects.

Cunningham himself rejected the idea that debt means writing bad code on purpose. In a 2009 talk he said he is never in favour of writing code poorly. What he supports is writing code that reflects your current understanding, so that it can be improved as you learn (Ward Cunningham, YouTube).

For a buyer, the split gives you a useful question: was this shortcut a decision, or a surprise?

How technical debt shows up for a founder

You will not see the code. You will see symptoms:

• Releases slow down. Features that used to take days now take weeks, with no change in scope.

• Every change breaks something else. A fix to the checkout page affects the invoice emails.

• "We can't touch that part." Developers avoid one area, or quote far more time for it.

• One person holds the knowledge. Only one developer understands how deployment, payments or the database works. If they leave, you are stuck. That is key-person risk.

• Good people leave. Fowler's page points to writing on the human cost of debt: team infighting, atrophied skills and attrition (Martin Fowler).

None of these proves debt on its own. Together, they are the interest showing up on your invoices.

How the interest compounds

Debt hurts most where you change things most. Fowler notes that cruft only costs you when you work in that area of the code. A messy part nobody touches is not a problem. A messy part you change every week has "cripplingly high" interest (Martin Fowler).

Two things make it grow:

1. New work lands on top of old shortcuts. Each change made without care adds more cruft, so the next change is slower again.

2. The world around the product moves. Fowler points out that the metaphor breaks down here: financial interest runs with time, while code interest is mostly triggered by changes. In practice, software also ages from the outside. Platforms, libraries and payment providers change, so even untouched code needs updating. Our maintenance cost guide covers two current store rules, and What Happens After Launch explains why dependencies age even when your product does not change.

Cunningham describes the worst case: if you only ever add features and never reorganise the code to match what you have learned, the interest becomes total, and you make no progress (Ward Cunningham, YouTube).

Why cheap software often carries more debt

A low quote is not proof of bad code. Some teams work efficiently and charge fairly. But when a price is squeezed, the work you cannot see is the easiest to cut: tests, structure, documentation and review. Ask what is included.

Fowler's "design stamina hypothesis" describes the trade. A project that skips design delivers features faster at first, then slows as the code gets harder to change. Good design overtakes it at a point he calls the design payoff line. He is candid that this is a conjecture with no objective proof, though he treats it as an axiom from his own career. He also takes the view that the line is "much lower than most people think", usually weeks, not months (Martin Fowler).

So compare quotes by what stays in your hands after delivery, not just by the number.

When taking on debt on purpose is smart

Debt can be a good tool. Cunningham borrowed deliberately: he thought rushing software out to get experience with it was a good idea, as long as you went back and repaid the loan by improving the code as you learned (Ward Cunningham, YouTube).

A minimum viable product is the clearest case. You are testing whether anyone wants the product, so you accept rougher edges in return for learning sooner. Fowler's conditions are strict:

• The shortcut must buy something real, such as an earlier release.

• You must know you took it, and why.

• The first release must be small enough to sit below the design payoff line.

• You must plan to repay it (Martin Fowler).

An MVP with no repayment plan is just an unfinished product, which we wrote about in The 'MVP' You Were Sold.

A simple repayment plan

Fowler's advice is to pay the principal off gradually rather than stop everything for a big cleanup (Martin Fowler). A practical sequence:

1. Audit. Ask an independent developer, or your own team, to list the shortcuts and mark where they hurt: which areas change often, which break often, which only one person understands. Rank by pain, not by ugliness.

2. Put tests around the risky parts. Before changing fragile code, add automated checks for the behaviour you depend on, such as payments, sign-up and orders. Fowler warns that the details of existing behaviour are often hard to work out (Martin Fowler), and tests capture it.

3. Upgrade dependencies. Move outdated frameworks and libraries to supported versions, in small steps, with tests running after each.

4. Document. Write down how to run, deploy and recover the system, and where the accounts and keys live. This removes key-person risk.

5. Retire. Remove unused features and dead code. For parts too damaged to repair, Fowler's Strangler Fig approach replaces them gradually: build new pieces alongside the old, move behaviour across, and avoid a risky all-at-once rewrite (Martin Fowler).

Start with the areas you change most. Leave stable, rarely touched code alone until you need it.

Questions to ask a developer or agency

Use these before you sign, and again at handover:

1. What shortcuts did you take, and where are they written down?

2. What automated tests exist, and which business-critical flows do they cover?

3. How does a change go from a developer's laptop to live, and how do you undo a bad release?

4. Which frameworks and libraries are in use, and what is your policy for updating them?

5. Can a new developer run the project from your written instructions?

6. Who else on your team understands this system?

7. Does every change get reviewed by a second person?

8. Who owns the code repository, hosting and domain accounts? Are they in my name?

9. What do I receive at handover: source code, documentation, deployment steps?

A good answer is specific. If the reply to question 1 is "none", ask again. Fowler says even the best teams carry some debt, so a team that claims to carry none deserves a follow-up. Our guide on choosing a software development company has a wider checklist.

How ongoing product care keeps debt down

Debt grows when nobody is looking after the product. Product Care is the work that pays small instalments before they become a crisis: monitoring, dependency updates, fixes and small cleanups alongside each change. Fowler's guidance points the same way: spend extra time cleaning the areas you modify most, each time you modify them (Martin Fowler).

Busyexpand builds that into the work. Product Care is one of our four services, and every project we ship includes a year of post-launch support, covering monitoring, dependency updates and routine maintenance. After 20+ digital products, our rule is simple: if a shortcut is worth taking, write it down, and schedule the repayment.

Have software you are scared to touch?

If you have an app or site that has become slow to change, or you are about to buy one and want a build that stays easy to change, we can look at it with you. Bring what you have: the code access, the quotes, or just the symptoms. Start a project or book a strategy call.

FAQ

What is technical debt in simple terms?

It is the extra cost of changing software that was built quickly or carelessly. Like a loan, you gain speed now and pay interest later as slower, riskier changes.

Is technical debt always bad?

No. Fowler distinguishes prudent debt, taken on knowingly for a real benefit such as an earlier release, from reckless debt. Debt becomes a problem when it is hidden or never repaid.

Can technical debt be avoided completely?

No. Fowler says even excellent teams meet debt as they learn what the design should have been. Keep it visible and small.

Does cheap software always have more technical debt?

Not always. But a low price can come from skipping tests, structure or documentation. Ask the questions above and compare what you receive at handover.

Sources

All pages were opened and read on 27 October 2026.

• Martin Fowler, Technical Debt (21 May 2019, rewrite of a 2003 post)

• Martin Fowler, Technical Debt Quadrant (14 October 2009)

• Martin Fowler, Design Stamina Hypothesis (20 June 2007)

• Martin Fowler, Strangler Fig (22 August 2024)

• Ward Cunningham, The WyCash Portfolio Management System (26 March 1992)

• Ward Cunningham, The debt metaphor (2009 video, read via transcript)