If your development team has started answering every new request with "this takes longer than it used to," if a small change breaks something in a far corner of the system, or if nobody wants to touch one particular module, you are probably dealing with technical debt. The short answer to "what is technical debt?" is this: the sum of software decisions, some made on purpose to ship faster and some accumulated without anyone noticing, that make every later change slower.
In this guide we cover what technical debt is, its deliberate and accidental forms, its types, how to measure it in business terms, what to repay first, the payback of repaying it, the difference between rewriting and improving, and how to explain it to management. The example figures are illustrative; they are not an industry average or real project data.
What Is Technical Debt?
Technical debt is a metaphor for the extra work you take on later when you choose an easier or faster solution now. The financial language fits: the principal is the shortcut that created the debt, the interest is the extra time paid on every change because of that shortcut, and repayment is replacing the shortcut with a proper solution.
The useful part of the metaphor is that debt is not always bad. Taking a deliberate shortcut to reach the market two months earlier can be defensible if the interest is estimated and repayment is planned. The real problem is debt that stays invisible and interest that is never calculated. We explained what software is made of, layer by layer, in our guide to what custom software is; debt can build up in any of those layers.
We recommend reading: Our custom software service
What Is the Difference Between Deliberate and Accidental Technical Debt?
Deliberate debt is a decision; accidental debt is a result. Both charge the same interest, but they are managed differently.
- Deliberate debt: A postponement whose reason is known and whose limit and repayment date have been discussed, such as "let us ship this release without tests and add them next sprint." If it is written down, the debt is manageable.
- Accidental debt: A buildup nobody decided on, caused by a misunderstood requirement, inexperience, a copy-and-paste habit, or a structure that strains as the project grows. It is usually noticed in the middle of the project.
Much accidental debt is born because the need was never written down clearly at the start. We explained how to put requirements on paper and fix the scope in our requirements analysis guide. There is one more kind of debt that appears over time: a decision that was right when it was made becomes inadequate as the business grows. That is not a mistake, but it charges interest in the same way.
What Are the Types of Technical Debt?
Classifying debt makes repayment planning easier, because the interest of each type shows up in a different place.
| Type | Example | Where the interest shows |
|---|---|---|
| Code debt | The same price calculation copied into three places | Changing one rule means three edits and three chances for error |
| Test debt | No automated tests in the order module | Every change is checked by hand; defects are caught in production |
| Architecture debt | Everything tangled together in one block | A small request affects a wide area; scaling gets harder |
| Documentation debt | Setup and business-rule knowledge held by one person | Newcomers start slowly; knowledge leaves when the person does |
| Dependency debt | Libraries and infrastructure versions not updated for years | Security exposure and incompatibility; updating gets more expensive over time |
Our software testing guide covers how to close test debt, and our microservices architecture article looks at splitting a system, which is one face of architecture debt.
How Do You Measure Technical Debt?
There is no single correct measure of technical debt. What works is tracking a few simple indicators that make the interest visible in business language. Lines of code or a "quality score" alone mean little to management.
- Capacity share: How much of the sprint capacity goes to work created by debt? Formula: debt-driven work ÷ total capacity. In the example, 12 ÷ 40 = 30%, which leaves 28 points for new work.
- Lead time for change: How many days a small request takes from ask to release. In the example, a request of the same size took 2 days a year ago and takes 6 days today.
- Failed release rate: The share of releases that caused a problem. In the example, 6 of 30 releases caused trouble: 6 ÷ 30 = 20%.
- Avoided work: The number of modules the team says "let us not touch." It is countable, and it maps where the fear is.
Expressing points in money needs a conversion. The illustrative team has five people and the sprint is two weeks: 5 × 10 working days = 50 person-days for a capacity of 40 points. So 1 point = 50 ÷ 40 = 1.25 person-days. 12 points = 15 person-days; at ₺9,000 per day, the interest each sprint is 15 × ₺9,000 = ₺135,000.
Which Technical Debt Should You Repay First?
Repay the debt that charges the most interest first, not the largest item and not the ugliest code. A practical measure is impact multiplied by frequency. Both are scored from 1 (low) to 3 (high).
| Debt item | Impact | Frequency | Score | Decision |
|---|---|---|---|---|
| Price calculation copied into three places | 3 | 3 | 9 | Repay in the next two sprints |
| No tests in the order module | 3 | 2 | 6 | Repay in the next two sprints |
| Missing setup documentation | 1 | 2 | 2 | Watch, repay when convenient |
| Old library version | 2 | 1 | 2 | Watch; repay at once if a security flaw is reported |
The thresholds are illustrative too: 6 and above are planned immediately, 3–5 are handled in a planned sprint, and 2 or below are watched. Items whose impact can jump suddenly, such as a security flaw, sit outside this table and are handled first. When scoring impact, keep items that touch business-critical flows, like a dealer portal, at the high end.
How Do You Calculate the Payback of Repaying Technical Debt?
Payback is the cost of the repayment divided by the interest saved each sprint. First estimate the cost of repaying, then the interest that will disappear afterwards.
In the example, consolidating the price calculation in one place and covering it with tests takes 12 person-days: 12 × ₺9,000 = ₺108,000. The work lowers the debt-driven load from 12 points to 9, so 3 points are freed per sprint: 3 × 1.25 = 3.75 person-days × ₺9,000 = ₺33,750.
- Payback period: ₺108,000 ÷ ₺33,750 = 3.2 sprints, so about 4 sprints (8 weeks).
- Over six months (13 sprints): 13 × ₺33,750 = ₺438,750 is saved; after subtracting the repayment cost, the net gain is ₺438,750 − ₺108,000 = ₺330,750.
- Capacity effect: The debt share drops to 9 ÷ 40 = 22.5%, and capacity for new work rises from 28 to 31 points, an increase of 3 ÷ 28 ≈ 10.7%.
This calculation resembles how a software project cost is built; we explained effort, contingency and day-rate logic in detail in our software development cost guide. In your own calculation, use measured capacity and your real day rate. There is a risk of estimating the freed points too optimistically, so measure the real value after the first repayment.
How Do You Repay Technical Debt?
The safest way is to repay it continuously, in small pieces. Setting aside 15–20% of each sprint's capacity for planned debt work is a common starting point; it is a suggested start, not a universal rule. With a capacity of 40 points, 20% is 8 points. The 12-person-day job above equals 12 ÷ 1.25 = 9.6 points, so with an 8-point share it takes 1.2 sprints, and in practice two sprints.
The advantage of continuous repayment is that the work moves alongside new features and you can see the interest fall at each step. A big "debt cleanup" sprint or a rewrite project, by contrast, stops new work and carries its own risk.
- Record: Keep the debt in a single list: what it is, where it is, why it arose and what interest it charges.
- Measure: Track the capacity share, lead time for change and failed release rate.
- Prioritize: Rank by impact × frequency.
- Plan: Put the chosen item into a sprint alongside new work, within the capacity share.
- Repay: Work in small steps, and keep the system working at every step.
- Verify: Check with the same indicators that the interest really dropped.
How Do You Prevent New Technical Debt?
You cannot bring debt to zero, but you can stop it from piling up unchecked. Four habits help most.
- A definition of done: "Done" should not mean only "it works"; it should include that tests were written, the change was reviewed and the necessary documentation was updated.
- Code review: Every change is read by someone other than its author. Copied code and unexplained shortcuts are caught here.
- Automated tests: Tests that run on every change lower the failed release rate and give the team confidence.
- A debt log: When a deliberate shortcut is taken, write it down with a repayment date. A shortcut without a record turns into accidental debt.
Our software development life cycle guide walks through at which stage each of these habits comes into play.
Should You Rewrite or Improve the Software?
In most cases improving piece by piece (refactoring) is safer; a rewrite is considered only when the current structure is truly unsustainable. This comparison helps with the decision.
| Topic | Piece-by-piece improvement | Rewrite from scratch |
|---|---|---|
| Risk | Low; each step is verified separately | High; hidden rules of the old system can be missed |
| New work | Continues | A double load appears, old system and new |
| When the benefit arrives | From the first step | Mostly at the end |
| When suitable? | The structure works but is hard to maintain | The technology is unsupported, or the structure cannot carry security or scale needs |
An illustrative comparison: in an application with five modules, if improving each module takes 12 person-days, the total is 5 × 12 = 60 person-days = ₺540,000. If rewriting the same application is estimated at 150 person-days, that is 150 × ₺9,000 = ₺1,350,000. In a rewrite, the hidden rules of the old system can inflate the estimate, so before deciding, the reason the structure is truly unsustainable should be written down. The decision should come from the measured interest, not from taste in code.
How Do You Explain Technical Debt to Management?
Instead of saying "we want to clean up the code," describe the interest in money and time. A three-sentence pitch works: how much are we losing, how long does repaying take, and when does it pay back.
- Loss: "30% of our capacity, about ₺135,000 per sprint, goes to fixes and workarounds."
- Cost: "Consolidating the price calculation takes 12 person-days, which is ₺108,000."
- Payback: "It pays for itself in about 8 weeks, and by month six it has produced a net gain of more than ₺330,000."
These figures are illustrative; your presentation should use measured values. A steady maintenance routine also slows the rate at which debt builds up; for scope and service levels, see our guide to software maintenance agreements.
What Are Common Mistakes with Technical Debt?
- Never recording the debt: Invisible debt cannot get priority and cannot be explained to management.
- Prioritizing by size: The item that charges the most interest goes first, not the largest or ugliest one.
- Trying to clean up everything at once: Stopping new work for a big cleanup is usually postponed or left half done.
- Not measuring repayment: If the indicators did not change after repayment, the wrong item may have been repaid.
- Blaming every shortcut: A deliberate, recorded shortcut with a repayment plan is legitimate.
- Treating a rewrite as the first answer: If the structure works, piece-by-piece improvement is often less risky.
We recommend reading: What is an MVP? How to Define a Minimum Viable Product and Score Its Scope
Sustainable Custom Software with İnovabil
At İnovabil, our focus is building company-specific software from scratch: custom software, ERP, CRM, e-commerce, web, mobile and integration. The recorded steps on our process page are analysis, design, development, testing, release, and maintenance and support; debt usually builds up where these steps are skipped or squeezed. If maintaining your existing software has become hard, we suggest first measuring together which item charges how much interest.
We built CRM, purchasing and mobile for Avcılar İnşaat; a purchasing system for İZBAN; logistics and shipment planning plus wholesale order management for Karyak; and warehouse management plus a complaint and support management system for Sleepy. Send a short summary of the state of your software; we will produce a written assessment based on lead time for change and capacity share.
We recommend reading: Our software development process: step by step from analysis to launch
Frequently Asked Questions
What is technical debt, in short?
It is the sum of software decisions, made to ship faster or accumulated without notice, that slow down every later change. The interest is the extra time spent in the future; repayment is replacing the shortcut with a proper solution.
Is technical debt always bad?
No. A shortcut taken to reach the market early, recorded, and backed by a repayment plan can be defensible. What is bad is debt that stays invisible and whose interest is never calculated.
How is technical debt measured?
With indicators read in business language: the share of capacity taken by debt-driven work, lead time for change and failed release rate. In the example, a 12 ÷ 40 = 30% capacity share means about ₺135,000 of interest per sprint.
How long does it take to repay technical debt?
It depends on the size of the item. For continuous repayment you can set aside 15–20% of capacity; the 12-person-day item in the example finishes in about two sprints and pays for itself in about 8 weeks. Recalculate with your own measurements.
Does rewriting the software solve technical debt?
Not always. It may be necessary when the structure is unsustainable, but without discipline the debt builds up again in the new system. In most cases piece-by-piece improvement carries less risk; the decision should come from the measured interest.