Fluent UI v9 is genuinely great. The primitives are accessible, the API is sensible, the runtime cost (Griffel) is near-zero. But the default identity is unmistakable, and a personal site built with default Fluent looks like an enterprise dashboard wearing a costume.

The fix

You don't have to throw out the components. You just have to override the theme tokens.

• Build a custom BrandVariants ramp — your accent, not theirs
• Override the neutral surface tokens — slate or zinc, not the default grays
• Override the font family tokens — Inter / JetBrains Mono works well
• Use createDarkTheme(brand) / createLightTheme(brand) as a base, then spread your overrides

The result: Fluent's primitives, your identity. Best of both worlds.

This site is a single-page app. It runs on Azure Blob Storage with Front Door in front. Total monthly cost is somewhere between "free" and "rounding error".

The setup

1. Create a Storage Account with static website hosting enabled
2. Set the index document to index.html
3. Set the error document to index.html too — that's how SPA routing survives a refresh
4. Upload your build output to the $web container
5. Stick Azure Front Door in front for CDN, TLS, and WAF

Why bother?

Because the alternative is paying $20/month for a managed platform that runs the same five static files behind a fancier dashboard. The Azure setup is more clicks once, then forever cheap.

Strict mode catches an embarrassing fraction of the bugs you'd otherwise hit at runtime. The cost is some short-term pain — annotations you'd been getting away without, narrowing where you'd been hand-waving. The benefit is years of "wait, that should've been impossible" bugs that simply do not happen.

What you actually get

• strictNullChecks — no more "undefined is not a function"
• noImplicitAny — forces explicit types where the inference gives up
• strictFunctionTypes — catches variance bugs in callbacks
• noUncheckedIndexedAccess — array access returns T | undefined, which is what it actually is

Strict mode is not optional for production code. Enable it from day one. Migrating later is harder than you think.

Less hot takes, more boring choices that age well.

Hooks, not classes. Still.

Function components with hooks. There is no second answer. If you're writing a class component in 2026 it's either legacy or a render-prop holdout, and either way you should plan to migrate it.

Server state and client state are different things

Stop putting fetched data in useState. Use TanStack Query (or your team's pick) for anything that came from a server. Cache invalidation is hard, and a library that's spent five years on it has thought about it more than you have.

Custom hooks for logic, components for shape

If a component is more useEffect than JSX, the logic should live in a hook. The component is a shape — the hook is the brain.

"But it's only used in one place." Yes. Extract it anyway. Future-you will rename and reuse it within six months.

I had a blog. It died. I had another blog. It died too. The pattern was: spend a weekend setting up a CMS, write three posts, never log into the admin panel again.

So this time I built the simplest thing that could possibly work — a static React site, posts as data, deployed on Azure for the cost of a coffee per month. No CMS to maintain. No "did I update the plugin" anxiety.

What goes here

• Things I'm learning, in public
• Bugs I broke and how I un-broke them
• Weekend projects that escaped the weekend
• The occasional opinion that won't fit in a tweet

If something here helps you, great. If it makes you angry, also great — that means it's actually saying something. Either way, the RSS feed is at /rss.xml.