Most of the systems I'm proud of are built from boring parts. The technology choices were the easy bit. The engineering I'd actually defend went into failure handling.
The parts list
Postgres. A queue. A cache with an invalidation rule someone actually wrote down. Services small enough that one person can hold any one of them in their head.
None of that would impress anyone on a slide. All of it is well understood and well documented, and other people have already found its failure modes for you, which frees up your effort for the parts that are specific to your system.
Where the real work is
What made those systems good was how they behaved when things went wrong. Retries didn't duplicate work. Timeouts were actually set. Shutdowns drained cleanly. And someone had decided up front when data was allowed to be stale.
Nobody puts that on a slide either, which is a shame, because it's the part I'd want to see before trusting a design.
Building something like this?
I'm Ahmed Mamdouh, a senior full-stack & AI engineer. I reply within one working day.
MCP went stateless, and that matters
The July MCP revision went stateless with OAuth 2.0 and OpenID Connect, so MCP servers can now run behind load balancers and serverless.
Claude output is now watermarked
Claude output now carries watermarks and signed provenance by default. Tell your users, and never treat a missing watermark as proof.
Green flags that someone is genuinely senior
Two signals I trust: the candidate brings up a decision they got wrong without being asked, and asks about on-call before the tech stack.