My strategy: get really clear on business needs/objectives/internal SLAs for infrastructure. In my experience a lot of time-consuming stuff revolves around upti

My strategy: get really clear on business needs/objectives/internal SLAs for infrastructure. In my experience a lot of time-consuming stuff revolves around uptime, data recovery (RTO, RPO), security, compliance, and scaling. Depending on your business and the stage you’re in, a lot of that may not matter, so don’t build anything you don’t need now. I’m a solo-founder, with many years working in IT, and I focused on DevOps for part of it; I know what best practice looks like and it would be easy to fall down that rabbit hole doing an unnecessarily complex buildout. Currently I’m doing a small private beta, I’m avoiding 99% of standard practice. I’ve got a single EC2 node running Redis as the only datastore and NodeJS + Nginx + certbot, a cron to do backups to S3. No CI (there are no other devs to integrate code with) I run all tests locally and push/rollback with rsync. All code, assets, and server config (except creds) are in a monorepo. If the server goes offline, I will have a little downtime, that’s fine. If I run out of memory for Redis (not likely to happen soon), I’ll change to a different datastore or scale up the node. If I lose data, I can restore from S3, and additionally the architecture is such that clients will re-push their latest changes. Do the bare minimum to support the business, stick with what you know, outsource what you can, and properly value your time.