Designing for Simplicity in a Complex Cloud
There’s a strange irony to working in the cloud: the more tools we have, the easier it is to overcomplicate what should be simple.
Every week, I see this tension play out—both in my own projects and in helping others launch theirs. Someone comes to me wanting a full-blown website with user accounts, databases, and analytics dashboards… when all they really need is a clean landing page that converts visitors into leads. It’s easy to forget that a static HTML page on Vercel with a touch of CSS and a simple form can do that job beautifully.
Cloud architecture gives us enormous power, but power isn’t the same as purpose.
The Temptation of Complexity
A few years ago, I learned this lesson the hard way. I built a highly automated email-cleaning system to manage my inbox across multiple accounts. It used SQS queues, Lambda functions, SES, DynamoDB, and a Next.js interface. I wanted it to run continuously, automatically cleaning, sorting, and tagging messages.
It worked—technically. But it was exhausting to maintain. The orchestration alone became its own problem. What I thought would simplify my life ended up creating more infrastructure debt than I’d ever had before. I developed a new respect for the humble email client and realized: just because you can build something with cloud services doesn’t mean you should.
The Payoff of Boring
These days, I find myself advocating for what I call “boring architecture.”
When I host sites for small and mid-sized businesses, I’ll often use WordPress on a single EC2 instance. No autoscaling, no RDS cluster, no multi-AZ replication—just one clean box with automated backups and plugin updates. If the site gets a few hundred visitors a day, that’s fine. It’s fast, it’s reliable, and it’s simple to hand off to non-technical people.
And that last part matters more than anything: if the system isn’t maintainable by someone else, it isn’t really finished.
The Simplicity Rule
My rule is this:
If you can’t hand off your work to someone else to maintain, then you need to simplify.
I enjoy building and launching systems far more than maintaining them. That’s part of what makes me an architect—I want to design things that last beyond me.
The cloud gives us endless options, but simplicity is still the most underrated architecture pattern there is. It’s what makes systems stable, transferable, and humane.
Reflection
Designing for simplicity doesn’t mean rejecting sophistication; it means respecting context. Some projects need distributed systems. Others just need a static site. The wisdom lies in knowing which is which.
In a world obsessed with scaling, there’s quiet mastery in restraint.
💬 Enjoyed this post?
Let’s connect — you can reach out through my contact page,
or find me on 💼 LinkedIn and 🐙 GitHub.