Development
FundamentalsTechnical Debt: Why Quickly Built Websites Cost Twice as Much Later
Technical debt arises when shortcuts taken today cost interest tomorrow. Where the term comes from, what types exist, and how to tell when a rebuild is cheaper than repairs.
of Josef Kujawski5 min read
Short answer
Technical debt arises when websites are built quickly and provisionally: the shortcut is a loan, and every further change pays interest in the form of extra effort. Ward Cunningham coined the term in 1992; Steve McConnell later distinguished deliberate from accidental debt. For websites this means: plugin chaos, overgrown content, and undocumented systems are debts that get more expensive with every update. The solution is an inventory of the debts, a fixed repayment rate in the budget, and an honest calculation of when a rebuild is cheaper than repairs.
The Problem: The Website Was Finished Fast, and Now Everything Is Slow
The website was live within a few weeks, the budget was small, everyone was happy. Two years later, every small change takes days, nobody dares to touch the shop, and the service provider changes more often than the imprint. Eventually the question comes up: repair or rebuild?
What is hitting here has an established name in software development: technical debt.
The Principle: Shortcuts Are Loans
Developer Ward Cunningham coined the term in 1992: anyone who ships fast by building sloppily or provisionally takes out a loan. The delivered feature is the money, the messy solution is the debt, and every further work on that code pays interest in the form of extra effort. [1]
As with a real loan:
- Debt is not automatically bad. Anyone who consciously goes to market fast and plans the debt uses it as a tool.
- Interest always accrues. Every change to indebted code costs more than the same change to clean code.
- Anyone who never repays eventually pays only interest. Then maintenance eats the entire budget and nothing new gets built.
Steve McConnell later sharpened the metaphor and distinguished two types: deliberate debt (a conscious shortcut with a plan) and accidental debt (ignorance, time pressure, outdated technology). [2] The second kind is the more dangerous one, because nobody has it on their radar.
Origin and Context
Cunningham, one of the fathers of the Agile Manifesto and inventor of the wiki, used the debt metaphor to explain to non-developers why "quick and dirty" is sometimes right but never free. The term has been standard vocabulary in software development ever since and is now applied to websites, shops, and content systems as well.
Important: technical debt is not an accusation against developers. It is a management decision, conscious or unconscious. The question is never "do we have debt?" but "do we know where it sits and what it costs?".
Applying It to Websites and Digital Products
- Site builders and cheap setups: the fast start is the loan. Missing structure, content that cannot scale, and plugin chaos are the interest payments due at the first relaunch.
- Plugin collections: every plugin solves a problem today and creates dependencies, update conflicts, and security holes tomorrow.
- Overgrown content: pages without structure and an editorial plan are content debt. They slow down search engines and visitors alike.
- Provider changes without handover: knowledge that only lived in the last developer's head is a debt that comes due immediately when they leave.
Kernaussage
You do not repay technical debt with one big relaunch every few years, but with ongoing maintenance and deliberate decisions. The most expensive sentence in a web project is: "we will do it properly later".
The Solution: Make Debt Visible and Repay It on a Plan
Here is how to proceed:
- Inventory the debt. List outdated plugins, unused pages, provisional solutions, and undocumented workarounds. What nobody writes down, nobody can repay.
- Rate the interest. What does each debt cost per year in extra effort, outage risk, and lost inquiries? That turns "clean up someday" into a number.
- Plan fixed repayment. A fixed share of the budget, roughly ten to twenty percent, flows continuously into maintenance and cleanup instead of only into new things.
- Decide rebuild versus repair with numbers. When the annual interest exceeds the cost of a rebuild within two to three years, the rebuild is the cheaper option.
| Signal | Meaning | Consequence |
|---|---|---|
| Every change takes days | High interest in the code | Plan repayment or evaluate a rebuild |
| Updates are postponed out of fear | Plugin and dependency debt | Maintenance contract with a fixed rhythm |
| Nobody knows the system completely | Knowledge debt | Enforce documentation and handover |
| Relaunch every 3 years "because nothing works" | Repayment was never planned | Ongoing maintenance instead of patchwork |
The Maluure Approach
We build websites so they are not finished at launch but stay maintainable: clear structure, documented decisions, as few dependencies as possible. And we tell clients openly when a shortcut is a planned loan and when it is just a postponed problem. Both are legitimate, but only one of them is honest.
The question is never whether a website has debt, but whether anyone keeps books on it. Anyone who knows their technical debt can work with it. Anyone who does not know it pays it anyway, just without noticing.
Related Articles
- Website Maintenance: What It Costs and Why It Is Mandatory
- Technical SEO: The Invisible Foundation of Your Rankings
- Maluure Principle: Never Automate a Broken Process
Frequently asked questions
What is technical debt?+
Technical debt arises when shortcuts are taken during development, deliberately or accidentally. The fast delivery is the loan, the messy solution is the debt, and every later change costs interest in the form of extra effort.
Who coined the term technical debt?+
Software developer Ward Cunningham, co-author of the Agile Manifesto and inventor of the wiki, used the debt metaphor in 1992 to explain why fast, messy solutions are sometimes right but never free.
Is technical debt always bad?+
No. A deliberate shortcut with a plan can make sense, for example to reach the market quickly. Debt becomes problematic when nobody documents it and it is never repaid, because then the interest consumes the entire budget.
How do I recognize technical debt on my website?+
Typical signals: every small change takes days, updates are postponed out of fear, nobody knows the system completely, and every few years a complete rebuild is needed because nothing works anymore.
What does technical debt cost?+
The costs show up as running interest: extra effort on every change, outage and security risks, lost inquiries from slow pages, and eventually a forced rebuild instead of planned development.
When is a rebuild worth it instead of repairs?+
When the annual interest, meaning the extra effort caused by the debt, exceeds the cost of a rebuild within roughly two to three years, the rebuild is usually the cheaper and more plannable option.
How do I avoid technical debt in a new project?+
Through clear structure, few dependencies, documented decisions, and a maintenance budget of about ten to twenty percent that flows continuously into upkeep instead of only into new features.
Sources
#Development#Technical Debt#Maintenance#Relaunch
Author
Josef KujawskiManaging Director & Creative Director at Maluure
Josef leads the strategic and creative development of brands at Maluure. For over a decade, he has guided medium-sized businesses from brand positioning to digital delivery.
Managing Director of Maluure GmbH, Cologne. Specialising in corporate design, brand strategy and digital brand experiences.
