In serverless architecture (as in every non-trivial piece of software), complexity creeps in quietly. A clever pattern here, a nuanced tradeoff there — until your team’s mental model is a maze.
Here’s a rule I use to stay sane:
If a decision takes more than 5 minutes to explain to a teammate, it’s probably too complex for our current stage.
This isn’t about dumbing things down. It’s about protecting clarity, trust, and speed — especially in early-stage products.
Why it matters:
Serverless is already abstract. Adding layers of cleverness makes it harder to debug, onboard, or pivot.
Cognitive load is real. Every extra concept costs brainpower — and brainpower is your most expensive resource.
You’ll revisit it anyway. Most decisions aren’t final. Clarity now beats perfection later.
Would I still choose it if I had to maintain it solo?
This is my favorite sanity check.
Serverless promises scale, speed, and delegation — but those benefits vanish if your architecture demands a team of specialists to understand it.
DHH once called Rails “the one person framework,” designed so a single developer could build and ship a full product without begging ops or frontend experts for help. I’ve had a taste of what that feels like by (re)discovering simple frameworks and libraries like HTMX, honojs, and even Kamal for non-serverless workloads.
That spirit matters more than ever.
Serverless should feel like that — not because you’ll always work alone, but because clarity scales. If your system makes sense to one person, it’ll make sense to ten. If it doesn’t, no amount of documentation will save you.
So when I’m tempted to reach for a clever pattern, I ask:
Would I still choose this if I were the only one maintaining it six months from now?
If the answer is no, I probably shouldn’t choose it now.