Technical Debt
Term 10 of 68 in the ERPStack technical glossary
What is Technical Debt?
Technical debt is the implied cost of future software refactoring and debugging caused by choosing a fast, temporary code solution now instead of a well-architected, flexible long-term approach.
Technical Debt at a glance
- Definition
- The gap between the design you have and the design the problem now needs
- Deliberate vs accidental
- 2 kinds — a conscious shortcut with a repayment plan, or drift nobody chose
- Measurable signals
- Change lead time, test coverage on hot paths, and count of dependencies more than 2 majors behind
- Interest
- Paid on every future change, which is why 1 untouched module can carry debt cheaply for years
- Built with
- TypeScript 5.9 typed contracts, Vitest 4, Playwright 1.59 and Storybook in GitHub Actions, Semgrep SAST and OWASP ZAP scanning, dependencies on Next.js 16 and React 19 updated continuously
- Numbers that matter
- Dependencies more than 2 majors behind are a signal; interest is paid on 100% of future changes; 4 proxies to track, none perfect on its own
- Where it accumulates
- Untested Node.js services, unpinned dependencies and forked SaaS customisations
- Countered by
- Vitest 4, Playwright 1.59, Storybook, Semgrep SAST, OWASP ZAP, GitHub Actions, TypeScript 5.9 contracts and Sentry regression alerts
- Currency as a measure
- The versions pinned in this repository are Next.js 16, React 19, Drizzle ORM 0.45, TypeScript 5.9 and Zod 4. Anything more than 2 majors behind is the first debt to price.
How Technical Debt works in production
The ERPStack approach to Technical Debt
We build codebases with strict TypeScript configurations, clean folders, and up-to-date dependencies. We run automated checks (linting, type checking, unit tests) in our CI/CD pipelines to prevent technical debt from entering your codebase.
Frequently asked questions about Technical Debt
What actually counts as Technical Debt?
The difference between the current design and the design the problem now requires. Technical Debt is not the same as bad code: a deliberate shortcut taken to hit a date, recorded and repaid later, is a reasonable trade. What makes it dangerous is invisibility — drift that nobody decided on, spread across modules, so the cost surfaces only as work taking progressively longer for no stated reason.
How do you measure it without guessing?
Through proxies that track the cost of change. Lead time from commit to production, the proportion of changes that cause a follow-up fix, test coverage on the paths that change most often, and how many dependencies are 2 or more major versions behind all correlate with Technical Debt. None is perfect, but a trend across them is far more useful than an opinion about which files are ugly.
Should all technical debt be repaid?
No. Technical Debt in a module nobody touches costs nothing, because interest is only paid when the code is changed. The debt worth repaying is in the areas with the highest change rate, where every future feature pays the surcharge. Prioritising by change frequency rather than by how uncomfortable the code looks is the difference between a cleanup that pays back and one that does not.
How does ERPStack prevent debt accumulating?
By keeping the cost of change visible. Typed contracts, Vitest 4 unit tests and Playwright 1.59 end-to-end runs in CI, dependency updates handled continuously rather than in a 2-year batch, and refactoring done as part of feature work rather than deferred to a cleanup phase that never gets scheduled. Technical Debt is unavoidable; letting it become invisible is a choice.