Recognizing, managing, curating, and killing technical debt is something that only comes with experience.<p>It's all about trade offs, and trade offs are informed by the environment they are in. When it's early and getting an MVP and revenue is important, you need to go with what you're comfortable with and have significant experience in. To do otherwise is going to distract you from the area you still need to explore and become an expert in: the business logic.<p>Really, this is why you'll see startup job postings saying they are looking for specific languages or frameworks: when they start seriously hiring for the first time, they need more people to help grow what they already have, no matter what that is, not people who want to come in and replace it with their favorite whatever.<p>There is no one-size-fits-all solution, and few technical debts are exactly similar. All are multifaceted and look different from different perspectives. What may be technical debt for one company, group of engineers, or at a specific time, may not be for another company, group, or time.<p>Presumably, before writing a single line of code, you aren't approaching the task totally green: your very idea must have been influenced by your abilities and experience. You should know if your web app needs a frontend rendering framework, and you're comfortable with one already or are willing to learn one in the short term. If you know JSON and are familiar with libraries and language support for it, don't bother looking at protobuf or thrift or serialization format du jour.<p>There will be technical debt, or at least there will be things that you know/think are technical debt that you wish you could have done differently. But that's the trade off you make. It's not going to be perfect ("perfect is the enemy of finished", or whatever that line is). The thing to do is make sure you're making informed decisions, know the tradeoffs, and that you're comfortable with them <i>at that time</i>. This is the only way to make progress, and progress is the most important thing, especially early on. Later on, progress will take on a different definition, which may include evaluating past decisions and recognizing them as technical debt and fixing them up (aka creating new technical debt).