What is technical debt, and how much of it is acceptable?
Technical debt is the accumulated cost of past decisions that now slow down development, such as shortcuts taken to meet a deadline, designs based on earlier requirements or outdated dependencies. A controlled amount can help deliver faster, provided it is recorded and managed.
Deliberate technical debt is a documented trade-off, such as a simpler approach chosen to meet a launch date, with a plan to revisit it. Unrecorded debt is harder to manage because it is not tracked.
The clearest indicator is a rising cost of change: features taking longer to deliver, changes causing unrelated issues or deployments depending on specific individuals.
Technical debt is best managed continuously, with a consistent share of each sprint allocated to it.
Not all debt needs to be repaid. Stable code that rarely changes carries little ongoing cost, so we prioritise areas that are actively being developed.
Related service
Custom SaaS DevelopmentMulti-tenant platforms with billing, administration and access control built in.
Was this helpful?