Some tests save you time. Some tests don't. It's perfectly possible to write a huge, fragile, heavily coupled test suite which takes days or weeks to modify when you make even a tiny change to the code it's testing.

Just as code falls on a spectrum between clean and completely unmaintainable, so do tests.

Test save you time (maybe) in the long run. But in the search for product market fit, you may conceptualize, design, build, release and then scrap a feature within the course of a month. That's not a long enough lifespan for the tests ROI (better code, fewer bugs, better architecture) to be positive.

The regression test [1] for our legacy application takes five hours to run. It takes five hours to run because it also needs to check every log message (via syslog) to ensure every transaction happened.

I can't say it saves any time, and it certainly does not have a negative cost.

[1] There are no unit tests, as there are no real "units" to test. It's a legacy code base of C and C++, using a proprietary library that no one left in the company has much experience with. Said proprietary library is considered "legacy" by the company that owns it. I've seen the code. No wonder they consider it "legacy" (it started life in the mid-80s and god does it show).