Every Stack Has a Story

I like sharing what I build. When I finished this site, I sent it around to friends and colleagues — not for architecture reviews, just first impressions. What I got back, more often than not, were questions about my stack. Not the content, not the design — the tooling.

One friend — more than a decade of frontend experience — shared his thoughts on the stack. I enjoyed it. Being forced to re-articulate why you made every decision is a genuinely useful exercise. But even he had walked in with strong assumptions about what I was trying to do. The starting point wasn't "help me understand your intent." It was "here's what I think you got wrong."

He was experienced and well-intentioned. And he was still wrong about the premise — because intent is the one thing you can't read from source code.

The Framework That "Doesn't Fit"

"Why Next.js for a static site?" — fair question. When I started building, I had very limited web experience. I picked Nextra — a layer on top of Next.js with beautiful theming, built-in MDX, and content-first authoring ready to go. It let me focus on writing instead of configuring. The ecosystem stuck, the project grew, and Next.js came with it. It's not a framework choice — it's legacy carried over from a decision driven by experience and priorities at the time.

The Boring Truth About Infrastructure

"Why Cloudflare instead of AWS?" I've spent the last ten years on AWS at work. But for this, I had a promotional deal on Cloudflare DNS. Once the domain was there, it made sense to keep everything under one roof — CDN, DNS, deployments, one dashboard. It's free for what I need.

That's it. No grand architectural vision. No hot take on edge computing. A promo code and a preference for fewer invoices.

"Just Use an S3 Bucket"

This one reveals the assumption most clearly. If you think the site is purely static, then yes — an S3 bucket is the textbook answer. Clean, cheap, boring in the best way.

But there's an AI chat on the site that requires server-side rendering and proxying requests. The moment you need that, "just use a bucket" stops being a complete answer. The suggestion wasn't wrong in principle. It was wrong in premise.

The Step That Gets Skipped

What struck me about the conversation with my friend is that even the good version of this — two engineers, plenty of experience, casually talking through it — still started from assumptions about what I was building and why. Experience doesn't fix that. Seniority doesn't fix that. Only asking does.

And if that's the default in a casual conversation between friends, it's worse in professional settings. In meetings, code reviews, architecture discussions — the reevaluation step gets skipped entirely. Someone sees a choice, fills in the intent themselves, and jumps straight to the verdict.

Technical decisions are compressed artifacts. They encode constraints, history, cost, familiarity, and goals that aren't visible from the outside. Before telling someone their stack is wrong, try asking why they chose it. The answer is almost always more reasonable than the assumption.