Surely there are situations in which it's only useful to cover one's ass, but often it's a great way of explicitly understanding specific tradeoffs being made.
Now you have two choices:
1) You select and articulate your assumptions. You select and articulate your requirements. You also may try to capture and articulate your Black Swan list of unknowns and risks. The key thing is that you are clear. Clear what you know and clear about your concerns and risks. You then articulate your solution, holding it accountable to your assumptions, requirements. And then you move forward.
- or -
2) You come up with some solution sketch. You have a general vague notion that it isn't ideal. You're not sure why but it just doesn't feel right. You need a way to psychologically contend with this vagueness. So you give the vagueness a name. The first thought that comes to your head is: "Vague Notion That This Design is Not Very Good". This is not very flattering to your ego. So you think a little bit more and come up with: "Tech Debt". And you like this, because it sounds quite nice. It sounds like you're back in control, that you know what you're doing. You proceed to blame the design deficiencies over time to "Tech Debt". Everyone nods their heads.
What you’re describing with your product is the fruit of unskilled (amateur) labor.
I like the Go concept of aji [1] but that's too obscure, nobody will get it. Maybe something like "unfinished business" would work? A nebulous term for a nebulous concept.
You will find yourself squirming a little. It will be uncomfortable at first. But if you hold to your guns, you will find that you're forced to speak in much more clear terms about your process and decision-making.
And you will certainly find yourself saying humble things like "I have a sense that this isn't the best solution, but it's all I got right now."
But over time you'll find yourself improving. You'll find yourself saying "I have a sense that this isn't the best solution -- oh, you know what I just realized, this design choice is going make this other requirement over here nearly impossible to implement."
And with this kind of clarity you'll be in a much much better position to navigate the territory ahead and make clear, conscious decisions based on what you know and don't know.
"Tech Debt" is simply a way to dodge -- e.g., dodge the discomfort of not knowing stuff, of holding yourself to clear thinking, of admitting the need to improve...
Financial debt has a clear quantitative measure.
Tech Debt is an incredibly fuzzy concept, even as a qualitative measure, to the point of being useless for anything other than covering one's ass. We can do better as engineers than resting on such fuzzy thinking.