HN user
When you've got 30,000 lines of code, you don't always have time to go back through and read all the code to make sure that the particular change you're making doesn't have drastic effects somewhere.
Writing good tests means you don't have to find and read the 200 relevant lines of code.
If you've got good coverage, you'll have a great chance that they will. You've got to actively monitor your coverage though.
As far as backups go, a backup is only as good as it's age. If a startup is struggling to decide if they've got the resources for writing tests, they probably don't have the resources for maintaining a real-time database mirror either. You can argue that you should always back up before you roll out a code update, but the real world's not always like that.
If you have humans writing code for you, tests are an imperative. Without tests, one seemingly small code error can wipe out a smatter of user-created data accidentally. Sure, it's worse case, but it could also mean lights out for your startup. You have to decide if it's worth the risk.