Skip to main content
Mobius
Intermediate

What is technical debt

Also known as: tech debt, code debt

Definition

Technical debt is the future work created by choosing a quick code solution today over the right one. Unpaid, the interest builds and development slows.

Why it matters

Technical debt is how yesterday's shortcuts show up in today's budget, and an owner can see it without reading any code.

Common mistakes

Treating all technical debt as sloppiness, when some shortcuts are the right business call.

Related terms

Worked exampleIllustration

A price list kept in three places

Before the holiday season, a booking site's developer puts the price list in three places in the code to launch on time.

  1. The shortcut

    The site launches on time. The shortcut was deliberate and prudent.

  2. The interest

    Every later price change needs three edits instead of one.

  3. The cost

    One edit is missed, and a customer sees the old price at checkout.

  4. Repaying the principal

    The team spends one planned session moving the prices to one place.

  5. After

    From then on, a price change is one edit.

The shortcut was right for the launch. Leaving it in place for a year was the expensive part.

Shortcuts now, interest later

With no paydown, the shortcut line starts ahead, then every change costs more and the clean line passes it.Features deliveredTimeClean designShortcutsHere theinterest exceedsthe time saved

With no paydown, the shortcut line starts ahead, then every change costs more and the clean line passes it.

Shape after Martin Fowler, Design Stamina Hypothesis, 20 June 2007. No real data, and no rule for how much to repay.

Two ways to build the same product, drawn as a shape with no real data. The gold line takes shortcuts, the green line keeps the design clean.

Four kinds of technical debt

DeliberateInadvertent

Reckless

"We have no time for design"

Chosen, and the cost was never weighed.

"What is a layered design?"

Taken without knowing it, for lack of skill.

Prudent

"Ship now, pay it back later"

Chosen on purpose, the cost known and planned for. Like the price list in the example.

"Now we know how we should have built it"

Found only after building. It comes with learning.

Martin Fowler, Technical Debt Quadrant, 14 October 2009.

Martin Fowler's quadrant sorts debt by two questions: was it chosen, and was it wise. The worked example's shortcut is the gold one.

Definition

Ward Cunningham coined the metaphor in his 1992 OOPSLA experience report on the WyCash portfolio system: "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." The principal is the work needed to fix the shortcut. The interest is the extra effort paid on every later change to that code, until the principal is repaid. Cunningham later explained that he never meant it as permission to write code poorly: the point was to write code that reflects your current understanding of a problem, even a partial one, and to reshape it as that understanding grows. Martin Fowler's Technical Debt Quadrant (2009) sorts debt on two axes, reckless or prudent, and deliberate or inadvertent. "We have no time for design" is reckless and deliberate. Shipping now while knowing what the shortcut will cost later is prudent and deliberate. "Now we know how we should have built it" is prudent and inadvertent, and it happens to good teams too.

Why it matters

The symptoms are familiar: estimates for small changes keep growing, a fix in one place breaks another, only one developer dares to touch a certain part, and the team starts asking for a rewrite. Debt is not always a mistake. A shortcut that gets an MVP (a simple first version to test) to market on time can be the right call, and a prototype that will be thrown away never needs repaying. The danger is debt nobody decided to take and nobody tracks. Fowler's Design Stamina Hypothesis (2007) describes the pattern: effort put into good design lets a team keep delivering at speed for longer, while letting the design decay feels faster only at first. Code written by AI and never read, as in vibe coding, is debt from day one.

Directly related: Vibe Coding, Git, MVP.

Improvement tips

  • Keep a visible list of known debt in the backlog, next to the features, so it competes for time in the open.
  • Pay down debt in the area you are about to change anyway, where the interest is highest.
  • Reserve a fixed share of development time for the larger items, and let the team propose the share, since no research prescribes one.
  • Decide consciously which debt to leave alone, such as the debt in a prototype that will be thrown away.
  • Ask for automated tests before a cleanup, so refactoring does not break what already works.

Common mistakes

  • Ignoring debt until small changes take weeks and a rewrite looks like the only way out.
  • Seeing debt as a developer problem only, when it shows up as slower delivery and higher costs.
  • Taking a shortcut without writing it down, so nobody remembers to repay it.
  • Believing a fixed percentage of time for debt is a proven rule, when no research prescribes one.

Related terms

TechnologyBeginner

Vibe Coding

Vibe coding is building software by telling an AI what you want, running what it writes and never reading the code. Great for a prototype, risky with customers.

TechnologyIntermediate

Git

Git is free version control software: it saves a version of the code each time a developer commits, so you see who changed what and can go back.

StartupsBeginner

MVP

An MVP (minimum viable product) is the smallest version of a product real customers can use, built to learn whether they want it before you build all of it.

Project ManagementIntermediate

YAGNI

YAGNI (You Aren't Gonna Need It) is the rule from Extreme Programming of not building a feature until there is a real need for it, not a guess.

Project ManagementBeginner

Scrum

Scrum is a lightweight framework in which a small team works in sprints of one month or less, meets for 15 minutes a day and shows a working result each sprint.

ProductIntermediate

Prototype

A prototype is a cheap, early stand in for a product or service, built to show people and learn what to fix before paying to build the real thing.

Quick check

Which of these situations is technical debt?

Choose an answer

Frequently asked questions

Do I need to understand technical debt before I start my business?
The idea, yes: shortcuts in code are borrowed time, paid back later with interest. It explains why developers sometimes ask for time to clean up instead of building new features, and why that time is not waste.
When does technical debt first become relevant for a new business?
With the first prototype or MVP (a simple first version to test). Shortcuts are often right at that stage, as long as someone writes them down and plans when to repay them.
Is it bad to launch with technical debt?
No, a deliberate shortcut to test demand sooner is a normal trade off. What hurts is debt nobody chose, nobody listed and nobody plans to repay.
How do I balance code quality with a launch deadline?
Decide which parts must be built properly from the start, such as payments, logins and customer data, and where a temporary shortcut is acceptable, such as a manual step behind the scenes. List the shortcuts so the team comes back to them.
Why does technical debt matter for a business already running?
Because the interest grows with every change. Developers spend more time working around old shortcuts than building, and every new feature costs more than it should.
What goes wrong when a business ignores technical debt?
Small changes take longer and longer, fixes break other parts, and only one developer understands certain areas. In the end the team asks for a rewrite, which is the most expensive way to repay.
How do I pay down technical debt without stopping day to day work?
Pay it where you are working anyway: when a feature touches an area with debt, clean that area as part of the job. Set aside a fixed share of each cycle for the larger items, and let the team propose the share.
How do I explain technical debt to a partner who is not technical?
Like a loan. The shortcut bought speed today, and every change to that code pays interest in extra hours until the loan is repaid.
What does technical debt actually mean in plain words?
The extra work you will pay for later because of a quick solution you chose today. The quick solution is the loan, and the extra hours on each later change are the interest.
Is paying down technical debt risky?
It carries some risk, because changing working code can break it. Automated tests and small steps of refactoring, which reorganises the code without rewriting it from scratch, keep the risk low.
Do I need a separate developer to manage technical debt?
No, the team that works on the code manages it in its normal cycles. Your part is to give it the time and to ask to see the debt list.
How is technical debt different from a bug?
A bug is an error that breaks something now. Technical debt is code that works but is built in a way that makes every future change slower.

Sources: Ward Cunningham, The WyCash Portfolio Management System, OOPSLA 1992 experience report (c2.com/doc/oopsla92.html), Martin Fowler, Technical Debt Quadrant (martinfowler.com/bliki/TechnicalDebtQuadrant.html), 14 October 2009, Martin Fowler, Design Stamina Hypothesis (martinfowler.com/bliki/DesignStaminaHypothesis.html), 20 June 2007

Last reviewed: 2026-09-23

I have worked with

What Clients Say

From different fields, at different stages of business

Dan Manto

Eclipse Capital

Real Estate Investment and Finance, USA

Arty McLabin

GameReady

Game Development Education and Outsourcing, International

Anna, Beautician

Anna

Beautician

After I finished a cosmetology course at a leading company, I was confused. I didn't know how to open a business, what to sell from home, or how to bring in clients. Since I reached out to Mobius, everything has changed. We built an organized plan with clear steps and no unnecessary risks. Today I see results, and I'm growing and developing every month.

Mark, Massage therapist, Gan Yavne

Mark

Massage therapist, Gan Yavne

When I finished a massage course, I imagined a different world. I found out it's a hard field, and financial stability isn't easy to find. When I came to Mobius, something changed. We started an organized process and built a business plan. Without Mobius? I probably would have given up. Today I believe in myself and in my own path.

Tech decisions bigger than your team?

Alex helps Israeli businesses choose technology that fits the business, not the hype. The first call is free.

+972 055-248-6151. Better on WhatsApp: I am in meetings most of the day and answer as soon as I am free.