> I'm also afraid of digging an inescapable hole of untestable spaghetti code and tech debt. How many engineers do you have and how fast are they likely to wri

> I'm also afraid of digging an inescapable hole of untestable spaghetti code and tech debt. How many engineers do you have and how fast are they likely to write code? It depends more on the product that you're building rather than the stack - if the tech is the product, spend more time on making sure it works as advertised. If the tech enables the product, spend less. Any competent engineer can pick up thousands of lines of technical debt/spaghetti code and spend a few afternoons swearing at it and figure out how to modify it. Technical debt is a problem, but more of a problem when you hit millions of lines, hundreds of engineers, and you need to be sure you can change stuff without breaking it. Debt is useful - as long as you can take it on in a calculated way, don't stress about it too much. You might need to pivot and rewrite everything anyway, or at least have your fundamental assumptions changed in such a way that requires a partial rewrite. Tests won't help you much in those scenarios.