Write your software as modular as possible, that way when you make changes, you only affect one part of the system. So if you need to be able to have users log in, have an Account module handling password resets, authentication, authorisation, etc. If you need Email, build an email module that handles all email in the system, etc.

Further, build APIs for everything and do everything via APIs - I usually build RESTful JSON APIs with Create, Read, Update, Delete, List and Search.

I think it's totally valid to be in a stage where you have to move fast, as long as you understand the size of the technical debt that you are incurring. Don't ignore tests blindingly though - there are definitely pieces of code where writing tests will actually help you write faster (TDD or not).

Writing code that is easy to test will improve reliability even without actually writing tests, as the principles that make code testable are the same for writing good code (very modular, declare dependencies, single responsibility etc.). So I would suggest doing that.

You can also invest time in monitoring. If your mean time to fix is good, it balances out the time you put in testing... though this method won't save you time probably.

The key thing is focusing on keeping testing simple. I have experienced times where I have wasted more time writing tests than the actual implementation code. That taught me that my code was really complex and forced me to break it down in smaller modular components that were easier to test.

2 red flags I have learned to identify are: - The context to run the module is to complex (DOM emulation, protocol dependency) Leave that to End-2-End testing - Too much time invested on the test framework (Karma, Jasmine, Mocha, Jest) .Keep it simple

I recently wrote an article about this topic :

medium.com/@MarcFly1103/buckle-up-with-tape-1bd5e…

Also you could read:

medium.com/javascript-scene/what-every-unit-test-…