Startups aren't magically different. But they are the same as anywhere else in a very different way than described here. At almost any place (other than a com

Startups aren't magically different. But they are the same as anywhere else in a very different way than described here. At almost any place (other than a company that only writes moon lander code, or similar) you will probably encounter many different situations over your career. Sometimes quality is crucial and it's better to be late than buggy or wrong. Sometimes timeline in crucial and your users are willing to be more in the "beta tester" role as long as they get that first version quickly. Sometimes the product shape isn't quite clear yet so timeline (to iterate with real users) and future extensiblity/adaptability are both super important. Sometimes you can only afford the 6 month effort, financially. Having less tech debt won't help you if you ship nothing and make no money. Sometimes you won't need to add many more features in the future, so certain kinds of "tech debt" are fine. But there's no one-size-fits-all approach to software engineering across all these situations. Heck, it's often hard to tell with full certainty which situation you're in - predicting the future is hard. However, any approach that doesn't start with "what do we need, and what do we think the right set of tradeoffs are" is likely to let you down. Since there's no freebies here - "discipline" in the "follow the checklist 100% every time every where" sense is not free. Funny thing about the harping on TDD is that one of the real tricks is that if you don't know the situation, you can't even write the right tests. If the features/functionality is gonna churn, you need to be careful how you write your tests so you aren't constantly rewriting them by testing volatile boundaries of functionality. But that's very different from "TDD good, slow good, fast bad."