We try hard not to create debt on purpose. But that is never easy. We have a low volume/high ticket price product so for every feature/task/goal we discuss as

We try hard not to create debt on purpose. But that is never easy. We have a low volume/high ticket price product so for every feature/task/goal we discuss as a team “will this create more customers or just make current customers happy”. This helps us control debt because we stay focused. Often (but not always) debt is inversely proportional to focus (at least for us). When we do incur debt, we try to document inline: why and what. And add a todo how to fix. We also discuss each debt as a team so everyone understands. Usually we let it sit for one or two dev cycles. Sometimes we find we didn’t need it in the first place and rip it out. Other times, we’d d we did need it so we try to clean up sooner rather than later. This is pretty common for major new features. Ship and MVP quick, then clean it up. Because we have a long dales cycle, we often have time between demoing a new feature (mvp) and shipping a lower sent version. This is our more recent strategy. Obviously we have debt from long ago. We try to clean as we go with the general trend of reducing debt (even if we have short blips of increasing). I realize this approach won't work for everyone and every project but it does for us.