There is a version of every project where the infrastructure is the interesting part. I try very hard not to build that version, because interesting infrastructure is infrastructure that needs you at two in the morning.
Spend complexity where the product is
Complexity is a budget. Every clever thing in the deployment pipeline is a clever thing that has to be understood by whoever inherits it — often the client's own team, months after I have handed over. I would rather spend that budget on the consultation flow or the payment reconciliation, where the user can actually feel it.
That usually means managed services over self-hosted ones, one region until there is a reason for two, and a deployment that is a single command with no folklore attached to it.
Make the handover the design constraint
I build assuming I will not be the one operating it in a year. Infrastructure as code, secrets in one place, a README that describes how to deploy and how to roll back. If a competent developer cannot get the system running from the repository alone, the system is not finished.
Uptime is mostly a function of how few surprising things you built.
Boring is not the same as careless. It takes real work to make a system dull enough that nothing about it needs explaining.