Guide · Tech for owners
Technical debt: why small changes suddenly take weeks
Technical debt is the extra time and risk you pay on every change because the code was once built faster or cheaper than it should have been. It shows up as slow development, more bugs and suppliers who hesitate to touch the system. This guide gives you the warning signs, a worked example of what the debt costs, and a plan to pay it down without rebuilding everything.
11 min read · Updated 1 October 2026
You ask for something that sounds simple: an extra field on the invoice, a new discount type in the webshop, an export to accounting. The developer comes back with three weeks and a warning that something else might break along the way. Last year that kind of change took an afternoon. It is the most common sign of technical debt, and almost every company with software older than a couple of years knows it. The good news is that the debt can be measured, prioritised and paid down, just like the financial kind.
What is technical debt? A plain-language explanation
The term was coined by software developer Ward Cunningham in the early 1990s, and the metaphor still holds. When a system is built with shortcuts to hit a deadline, you borrow time. The loan is the principal: the work that should have been done properly. The interest is the extra time you pay on every change afterwards, because the developer has to work around the shortcut. As long as nobody touches the system, you feel nothing. As soon as you want to develop it further, the interest starts running, and it grows with every new shortcut stacked on top of the old one.
Technical debt arises in two ways. Deliberate debt is a choice: you launch a simple first version to test the market and know parts will be rebuilt later. It is healthy when it is written down and has a plan. Accidental debt arises on its own: inexperienced developers, changing suppliers, requirements that shifted along the way, or technology that went out of date while the system stood still. The most dangerous debt is the kind nobody knows they have, because it is discovered when something is urgent.
What types of technical debt are there?
The six types of debt we meet most often when we take over an existing system. Most systems have several at once.
| Type | What it looks like | Typical cause | Risk |
|---|---|---|---|
| Code debt | Duplicated code, huge files, unclear names | Time pressure and no code review | Medium: slower changes |
| Architecture debt | Everything depends on everything, one change hits five places | The system outgrew its original purpose | High: expensive to fix |
| Dependency debt | Outdated frameworks, plugins and libraries | No regular update routine | High: security holes |
| Test debt | No automated tests, everything tested by hand | Tests were cut to save money | Medium to high: bugs after releases |
| Knowledge debt | Only one person understands the system | No documentation, changing developers | High: vulnerable when suppliers change |
| Data debt | Duplicates, fields used for other things than intended | Missing validation and quick fixes | Medium: wrong reports and integrations |
Dependency debt deserves extra attention, because it grows even when nobody touches the code. A framework that was new four years ago may lack security updates today, and the longer you wait, the bigger the jump to the latest version becomes. We have a separate software security checklist that shows what to watch for.
How can you tell your software has technical debt?
You do not need to read code to see the signs. They show up in daily work, in the supplier’s estimates and in the mood of the people who work with the system. Go through the list and tick every point you recognise. Three or more ticks means it is time for a review.
- Small changes are estimated in weeks, and the estimates rarely hold.
- New bugs appear after almost every release, often in places nobody touched.
- Developers say "we don’t dare touch that" about parts of the system.
- Only one person, in-house or at the supplier, can explain how it fits together.
- You have postponed updates to the framework, server or plugins for more than a year.
- The system gets slower as you add more data and users.
- New developers need weeks to understand the code before they can contribute.
- There are no automated tests, so everything has to be clicked through by hand.
- Staff have invented manual workarounds, such as spreadsheets next to the system.
- The supplier proposes a new solution every time you ask for a change.
What we see in practice is that points four and five usually go together. When one developer has built and looked after a system alone for years, updates get postponed because something more urgent always comes up. Then the developer leaves, and the next one inherits both the code and five years of postponed maintenance. It is common for the first month with a new supplier to be spent bringing the system up to a version that can be updated safely at all.
What does technical debt cost? A worked example
Imagine an internal web app for orders and stock, built five years ago. You spend about 300 developer hours a year on small and medium changes, at DKK 1,100 an hour. Because the code is tangled and has no tests, every task takes on average one and a half times as long as it would in a healthy system. That is the interest. The table shows what it costs, and you can run the same sum with your own numbers.
Illustrative example. The factor of 1.5 is an example; in heavily indebted systems we often see more.
| Item | Healthy system | System with debt |
|---|---|---|
| Planned work per year | 300 hours | 300 hours |
| Actual time spent | 300 hours | 450 hours |
| Cost at DKK 1,100/hour | DKK 330,000 | DKK 495,000 |
| Interest per year | DKK 0 | DKK 165,000 |
| Interest over three years | DKK 0 | DKK 495,000 plus what never got built |
The DKK 165,000 is only the visible part. On top come the features you dropped because they were too expensive, bugs that hit customers, staff spending time on workarounds, and the risk of a security breach in an outdated component. If a targeted clean-up costs DKK 150,000–250,000 and halves the interest, it pays for itself within a few years. That full bill is what you should weigh against the price of acting. See also how we calculate the running cost of a website or app, because maintenance is what keeps the interest low.
Is all technical debt bad? When debt is a sensible choice
No. Debt is a tool, and as in finance, a loan can be smart. A startup that wants to test whether customers will pay is right to build a simple MVP with shortcuts and wait with the perfect architecture until the market has said yes. The same goes for a campaign page that only needs to live for three months. Debt becomes a problem when it is forgotten, when it grows without a plan, or when a temporary system ends up running the business for five years.
A newer example is prototypes made with AI tools such as Lovable, Bolt or Cursor. They are brilliant for showing an idea within days, but the code is rarely built for thousands of users, personal data and payments. That is deliberate debt on a large scale, and it has to be dealt with before the product goes live. We have written a guide on going from AI prototype to production.
How do you pay down technical debt? A five-step plan
1. Map it
An experienced developer reviews code, dependencies, tests and hosting and lists the debt with a rough estimate per item.
2. Prioritise by interest
Fix first what you touch most often and what is a security risk. Debt in a part of the system nobody changes can wait.
3. Set a fixed budget
Reserve a fixed share of development time for clean-up, for example a fifth of each month, so the debt falls steadily.
4. Clean up where you work anyway
When a developer changes a feature, it is left a little tidier: one more test, a clearer name, an outdated package updated.
5. Measure the effect
Track time per change and the number of bugs after releases. If the numbers fall, the plan is working.
Refactor, modernise or replace?
Decision table: choose the smallest intervention that solves the problem.
| If … | Then choose | Typical scope |
|---|---|---|
| The technology is sound but the code is messy | Ongoing refactoring | A fixed share of each month |
| The framework is outdated but the logic holds | Upgrade or modernisation | Weeks to a few months |
| One part of the system causes most problems | Replace that part alone | A scoped project at a fixed price |
| The technology is unmaintained and security cannot be fixed | A new system, built in stages | Months, with the old one running meanwhile |
The last row is the most expensive and the most tempting. A new system promises a clean start but carries a hidden risk: everything the old system does that nobody wrote down. That is why we build new systems in stages, moving one part at a time and testing it against the old one. Read more about how we do it under legacy system modernisation.
How do you avoid new technical debt from the start?
The cheapest debt is the debt you never take on. Most of it comes down to the agreements you make with your supplier before the project starts. Copy the questions below into an email to your current or future supplier and see how concrete the answers are.
- Do you write automated tests, and for which parts of the system?
- Is all code reviewed by another developer before it goes live?
- How often do you update the framework, packages and server, and is it in the fixed price?
- How do you document the system so another developer can take it over?
- Do you write it down when we choose a shortcut to hit a deadline?
- Do we own the code, and is it in a repository we can access?
- Which technology do you build in, and how widely used will it be in five years?
Question six matters more than it looks. If you do not own the code, you cannot get someone else to assess the debt, and you depend entirely on the supplier’s own judgement. We have collected everything on rights, repositories and accounts in the guide who owns the code.
Which myths about technical debt should you watch out for?
The myth
- "A new system solves every problem"
- "Debt is the developers’ problem"
- "It works, so there is no debt"
- "We will clean up when we have time"
The reality
- A new system built with the same habits gets the same debt
- The debt hits budget, customers and time to market
- Debt can hide for years until you want to change something
- Clean-up only happens with a fixed budget and a plan
How does Ceptiv keep technical debt low?
We build in React, Next.js and TypeScript, which are widely used and well-maintained technologies, and we build from scratch, so there is no stack of plugins to keep track of. Our fixed monthly plan covers hosting, maintenance, updates, support, security and backups, so dependency debt is not allowed to pile up in a quiet year. You own the code and data, and you can follow the project in our client panel. When we take over an existing system, we start with a review and a prioritised list, so you can see the debt in kroner before you decide anything.
If you have a system that has become heavy to work with, describe it briefly and get a fixed price for a review or a scoped clean-up. You get a written proposal within 24 hours.
