Fortunately database warm standbys are WAY easier than true multi-master.
Depending on one's business, HA/performance may not matter that much, but personally my startup is having a 'proper' design from day 1 - downtime is not acceptable for my business model.
Personally I'm pretty confident about market-fit and expected growth even before the launch day of my startup.
But that's not the case, most times!
Less servers and components mean less things to break.
Grab a dedicated server and host your shit on it (have a DB replica because losing data sucks, but that is easy). You will be able to run like that for much longer than you probably suspect and the chance of downtime will be massively reduced.
Why? Because a single server has a very low chance of having anything going wrong.
Not only that, but there is a lot of overhead in performance when you split everything up into components. You will be surprised how many requests you can handle on a single inexpensive dedicated server when you haven't put too much effort into "architecture".
When you actually find yourself running out of headroom on that setup you will know much more about your application and it's requirements then you did at the start, so you will have a better idea of what to split out, and a better understanding of what parts of your app need more performance anyway.
Similarly, if the work you are performing has any value for your business, it must be retryable, and the queued items must be safely stored (i.e. don't use a single Redis server - use something distributed like SQS instead).
All of that calls for a 'proper' architecture. I'm not talking microservices or anything fancy - just a webapp/worker/db separation and the like. Which is exactly what dedicated server (or DigitalOcean) users tend to lack at early stages.