One thing I've never seen properly stated is the difference between technical debt as usually described (building code that is doing the job but might not be as flexible, easy to change or fix or might not account for all corner cases appropriately) and then the kind of debt I've experience more often which is "model debt". In the field of business applications, modeling a problem correctly is 80% of the solution, and new companies usually do that job very poorly. Over time as business experience accumulates, some of those mistakes become evident. For example, how to model the identity of the users of an application, that's where the most mindless decisions I've experienced do the most damage. Let's say you assume the only type of user you're gonna have belongs to "companies" and your customers are companies. Then you discover those companies make heavy use of consultants or contractors, and all of a sudden most of your management tools and UI doesn't quite fit. You can hack it, but you end up with a large slice of your users having to manage 20 different emails to interact with your system. Just an example.
"model debt" is the most expensive and potentially fatal type of debt a new piece of software can incur, and my suggestion is for every new project, focus on building a real good model of what reality looks like before too many other technical calls are made, or you're in for a world of hurt.