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 and no server. Posts are plain Markdown in a Git repository, rendered to static HTML by a small generator I own end to end, and served as flat files. You can view-source on this page and read exactly what shipped — nothing is hidden behind a build I can't inspect.
That's not nostalgia. It's the same instinct as everything above: own the mechanism, keep it legible, and don't reach for a platform when a tool will do.
More soon.