You cannot just shoehorn this expression. It is overloaded and depends on context: - fixed price was paid, software delivered, nobody else cares == it is not a

You cannot just shoehorn this expression. It is overloaded and depends on context: - fixed price was paid, software delivered, nobody else cares == it is not a debt; - fixed price was paid, software delivered, but more potential buyers == tech is most likely in a debt as you'll need to accommodate more changes; - subscription based income, software needs constant improvements == tech is most likely in a debt; - VC based income, software needs constant improvements == tech is most likely in a debt as you do not know what you're building; - no income, software delivered, people want more == dunno; - no income, software delivered, devs say it is crap == no tech debt; I think debt should be tightly linked to the potential financial gains. But not only it is hard to quantify it, developers are not usually participating in the financial projections. Because of that you get a speculation on the importance of various refactoring exercises that do not yield any income improvements. Besides developers are usually biased towards improvements because otherwise they (devs) are not necessary anymore. An outrageous example. Imagine you are painting a naturmort. If you're not careful enough and do not do it right from the beginning it might end up being shit and beyond repair. But who cares if nobody buys it.