Not all problems really count as technical debt, IMO.<p>To figure out which ones do, I sometimes think about the correctness vs. completeness spectrum.<p>Correctness is how well the architecture fits the problem, how well edge cases are handled, if it's a service then whether it's built to scale horizontally, etc.<p>Completeness is how shippable the thing is. Are the important features there, are the bugs not too severe, could the thing live in production without causing severe harm, etc.<p>Some problem domains live only at the far end of the correctness spectrum, like software that life depends on, flight control, nuclear reactors, etc.<p>Other domains might be all the way on the completeness side, like the throw-away prototypes, temporary stand-alone marketing sites, etc. If it works at all, you can ship it. Problems there don't count as technical debt.<p>Obviously most projects are somewhere in the middle.<p>Most high-growth companies can get away with erring a bit toward the completeness side, and ignoring correctness for many things, because a lot of stuff will be re-written every year or so to handle the changes in the business brought on by customer growth. Since it will be re-written anyway, it might not be useful to think about the lack of correctness as technical debt because you won't ever pay the debt. The real trick is figuring out which things must be perfect now and which can be improved later.<p>Getting that wrong either way could lead to the failure of your startup. Settle for nothing but perfectly correct architecture for everything, and it might take too long to ship. On the other hand, ignoring severe problems in a critical system might somehow limit growth, cause a legal problem, etc., and eventually sink the company.