When you’re the only person who will ever touch the system, the calculus shifts.
Here’s what I’ve ended up with after doing this for a while.
Boring is a feature
Every unusual technology has a hidden cost: you, alone, at 2am, with no one to ask. So the threshold to adopt something exotic is high. “It’s interesting” doesn’t clear it. “It solves a specific problem I have, and the alternative is worse” does.
Postgres, not a distributed K/V store. Systemd, not a custom supervisor. Boring is not the opposite of good — boring is what survives contact with production for years while you’re not looking.
Observability before scale
The first thing I set up on any new service is logs and alerting. Not metrics, not tracing, not dashboards — those come later. Just:
- Structured logs, shipped somewhere I can query.
- Uptime checks on the critical user paths.
- An alert that reaches me in under a minute.
Without this, you can’t tell if the system is healthy, and you’ll find out about incidents from users. With this, you find out before users do, which is the entire premise of being a one-person team.
Automate the things you’d skip when tired
There’s a class of operational chores that are fine to do manually on a good day and dangerous to do manually on a bad one. Deploys, rollbacks, database backups, certificate renewal.
If it’s something I’d skip when I’m tired, I automate it. Not because the automation is complicated — usually it’s ten lines of bash — but because a tired operator with a manual checklist is where incidents come from.
Two of everything that matters
Two RPC providers. Two DNS providers. Two backup destinations. Two places the alert can reach me.
Single points of failure are fine in a team; someone else covers. Single points of failure in a one-person setup mean I am the backup, and I’m not always reachable.
Write decisions down
The future version of me, six months from now, will not remember why I chose Redis over in-memory state for rate limiting. The future version of me will be annoyed at past me for not leaving a note.
I keep a decisions/ folder in every serious project. One file per decision. Date, context, options considered, what I picked, why. Five minutes to write, saves hours later.
Don’t build what you can rent (unless renting is too expensive)
The calculus isn’t “build vs. buy.” It’s “how much does this cost me over a year, and how much does my time cost.”
For core product work, my time is the most expensive thing. I’ll buy.
For infrastructure where the rented version costs $100/month and the self-hosted version costs $5/month and two hours of setup, I’ll self-host. That’s what the laptop-server setup is: the cloud version of what I run costs more per month than the hardware is worth.
The key is being honest about which side of the line each piece falls on. Most things are not core product.
The meta-rule
Solo doesn’t mean scrappy. It means the architecture must match the operator. A system a team can run and a system one person can run look different, and pretending otherwise is how solo shops burn out.
Build for the team you actually have.