Technical debt

Technical debt is the cost a team takes on when it chooses a quick or easy technical solution instead of the best long-term one. This can happen in any part, or a mix, of the product’s technical stack, like code, infrastructure, or architecture. Over time, this debt slows development, increases bugs, and makes future changes harder.^[1] Like money, it “accumulates interest” in the form of extra work later: slower development, more bugs, and higher maintenance effort.

Not all technical debt is bad. Sometimes teams take on strategic debt to launch quickly. For example, a team might release a new signup flow using basic form validation to meet a marketing deadline, knowing they’ll need to improve error handling later.

Unmanaged debt grows fast and can block progress. Imagine a UI with inconsistent button styles from quick fixes. Adding new screens takes longer because developers must fix old inconsistencies first. Good teams dedicate 15–20% of development time to paying down debt. They focus on debt that slows future work or affects users. For instance, standardizing button styles and spacing before adding a new dashboard screen makes future updates smoother. Clear communication with stakeholders explains why some cycles focus on UI cleanup, for example, instead of new features.