Why This Blog Exists

I have spent a long time at the seam between design and engineering — close enough to the build to be accountable for it, close enough to the user to be accountable for them too. This is where I'm going to write about what I find there.

What this is for

Most of my work lives behind NDAs, login screens, and enterprise walls. The thinking behind it usually doesn't have to. So this is a place for the portable parts — the ideas, patterns, and arguments that outlast any single project:

• How to design systems instead of screens.
• Where AI actually earns its place in a real workflow, and where it just adds ceremony.
• The unglamorous architecture decisions that decide whether a product ages well.

If you build software, lead product, or care about the craft of either, that's who I'm writing for.

A bias toward leverage

I tend to ask one question before most others:

Is this a one-off fix, or the mechanism that prevents the whole class of problem?

The answer reshapes the work. A point solution closes a ticket; a good abstraction closes a category. Most of what I'll write here is some version of that question applied to design, to engineering, and increasingly to how the two collapse together when you build with AI in the loop.

Built the boring way

This site has no CMS. Posts live in a Git repository, the pages are built ahead of time, and Vercel serves the result. It runs on Next.js, but nothing sits between the repo and what you're reading except a build I can run on my own machine.

That's not nostalgia. Same instinct as everything above: keep the mechanism legible, and don't add a moving part the problem doesn't need.

More soon.