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.
All you need to do is configure the Point In Time Recovery feature, write a little backup script (mine is 165 lines of Python), and then call it from cron.
With PITR as long as you have the last backup and the archived WAL files made since the last backup you can recover to the SECOND before your program puked all over the DB.
On the other hand, if I knew of a great tool for automated page tests I would use it. I don't think creation of such tests should be hard.