[throwaway2016a]

I would say a related point to that is: don't skimp on unit and integration tests. It's easy to rush code out but tests will force you to think through it and give you a way to quickly test if a change is a breaking one.

But as a counter point, early in a product lifecycle you don't even know if the product you are building is what you are going to find a market fit for. So spending a lot of time getting the tech perfect is sometimes a waste. It's a constant calculation of balancing the risk of not scaling with the risk of taking so long you never get to the point where you can scale.

[TruthWillHurt]

Tests are for teams of contractors that don't know how the product works.

The talented person that built the thing knows exactly what a change will require, and how to test it before pushing his code.

Don't be an enterprise too soon.

[throwaway2016a]

> Tests are for teams of contractors that don't know how the product works.

The opposite. Tests are for people who know exactly how the product works. It's very hard to write good tests if you don't understand the product (or at least your piece).

I really hope you are being sarcastic. Tests when done properly speed up development and make your product more robust and resistant to breaking changes.

For a proof of concept that will never see production, sure, by all means don't write tests. But in my 15+ years in CTO and Principal role at smaller companies, the most expensive projects with the most downtime are always the ones without tests.

Tests make software cheaper not more expensive. And the ROI isn't even that long... all it takes is for two to three iteration / release cycles.

[andreisbc]

In my case, I haven't really considered integrations tests, as I didn't have the time. Only the bare minimum unit tests "it('should render or shouldnt fail')"