How I work.

Sitting with the people doing the actual work. Asking questions that probably seem obvious. Staying quiet longer than is comfortable, because the useful thing usually arrives after someone has finished the answer they had ready. I studied anthropology before I knew anything about software and the habit never left — you learn more from what people do than from what they tell you they do.

What I usually find is that the expensive problem is invisible to the people closest to it. Not through carelessness. Through adaptation. Someone built a workaround years ago, the workaround quietly became the process, and now nobody raises it because nobody sees it anymore. It rarely shows up in a kickoff meeting. It shows up on the third afternoon, when someone explains a step they've stopped thinking of as a step.

Once we know what to build, the specification carries the weight. Not as ceremony — as the thing that keeps everyone honest about what was actually decided. On the loyalty platform I built last year the requirements changed fourteen times before launch. Not because we kept getting it wrong, but because we kept learning, and each change updated the specification and the code together, in the same reviewed unit. What was running always matched what was written down.

That is most of what AI is genuinely good for, and it isn't typing speed. It's that the code can keep up with understanding as understanding changes.

I try not to build more than the situation needs. That same platform runs on deliberately ordinary infrastructure, because the elaborate version would have been architecture for its own sake — impressive to describe, expensive to run, and a burden on whoever came next.

I'm also wary of anyone who tells you there's one right way to do this. There are wrong ways, plenty of them. But on most of the decisions that actually matter — what to build with, where to run it, whether a given tool belongs in the picture at all — the answer depends on things specific to you. Anyone selling certainty is usually selling something else at the same time.

The goal is that it runs without me. I'd rather hand something over clean than make myself necessary. Some clients keep me on anyway, and a few have come back years later for something new. That's the version of this I like, and it only works if leaving was genuinely possible the whole time.

Mostly, the range.

In a single week I might be arguing about a business model on Monday, sitting inside a database schema on Wednesday, and watching someone use a prototype on Friday only to find the model was wrong. I like the strategy side of it — the arguing, the tradeoffs, being responsible for a call that might not work out. I also like opening something up to see how it actually runs. Most roles ask you to pick one altitude and stay there. This way of working doesn't, and that turns out to be the part I'd miss.

I've run departments and I'd do it again for the right problem. Some things only get solved with a team and a mandate, and that work has its own satisfactions — building the group, making the call, carrying it. What's changed is what's possible at small scale. The tooling got good enough that the person deciding what to build can stay close enough to actually build it, which opens up a kind of project that didn't previously pencil out.

I don't do all of it alone and I've never claimed to. When something needs expertise I don't have, I bring in people who work the way I do — which mostly means people who'd rather understand a problem before they start solving it.