Technical debt comes down to the ideology of "make it work, then make it right". Every time I make a technical decision, I ask myself how much debt am I taking

Technical debt comes down to the ideology of "make it work, then make it right". Every time I make a technical decision, I ask myself how much debt am I taking on if I skip the "make it right" part. And what am I gaining from skipping that step? I think the CEO's, CTO's, product managers, mid managers and lead devs all know they are taking on debt (if it has been communicated to them properly), they simply make what looks like the best decision at the time as far as the business goals are concerned. - The debt can be hidden until, its to late. How many times have you thought, this code is duck tapped from top to bottom and on release its fine? On the other hand how many times do you think code is bullet proof only for it to fail once it hits real world use cases? Technical debt is a risk vs reward equilibrium and everyone uses their best judgement to decide how much they want to borrow (unless they are ignorant to the the fact that they are taking on debt). As the author mentions, in the context of a startup taking on technical debt. Its much less risky. On one side of the equilibrium we have, "build a polished product that no one wants" then on the other side we have "release a buggy MVP, that will drive early adopters away forever". I would rather save time and get a MVP out ASAP, after that deciding if its beneficial to pay off the MVP debt or to keep iterating faster and release a 2.0.