I prefer the definition of technical debt being an uncovered call option: at some point the debt will come due and you don’t have anything in place to mitigate

I prefer the definition of technical debt being an uncovered call option: at some point the debt will come due and you don’t have anything in place to mitigate the issues it will cause and may not know when it will come due. This debt might look like a manual deploy process, a lack of automated testing, insufficient alerting, no rate limiting on public endpoints, etc. These are things that are fine and then when they’re not, they interrupt the schedule and require urgent and immediate attention. Bad architecture can cause urgent issues and it can also impact new feature development. The debt is a barrier that makes new features either take much longer than they should or make them just infeasible from a business standpoint. This can exist in both technical architecture or information architecture (i.e. you chose the wrong model and now it’s too engrained across everything to change).