How I work
The same loop every time, whatever the environment. The case studies are this method applied; this page is the method stated.
Find the person who feels the pain.
Not the sponsor — the user. The sponsor can describe the problem; the user lives inside it, and the difference between those two descriptions is where most projects die. I start by finding the person whose day the system will actually change and building for their Tuesday afternoon, not the kickoff deck.
The code-review pipeline was built for the developers waiting on reviews, not for a management metric. That's why it survived contact with its skeptics.
Get to a working thing before I fully understand the domain.
Understanding arrives through the artifact, not before it. A working version — even a wrong one — extracts more domain truth in a week than interviews extract in a month, because people correct a concrete thing in front of them and merely nod at an abstract one.
The knowledge graph behind careerexplorer.ai was wrong in genuinely instructive ways only once real coaching conversations ran against it. The conversations taught me the domain; the graph was how I asked.
Ship narrow and ugly first.
One workflow, end to end, in production. Narrow-but-live beats broad-but-planned because production is where the real constraints introduce themselves — auth, data quality, the user who does the thing no one predicted.
The volunteer system went into production long before it was complete, running one slice of operations while the rest stayed where it already lived. It earned its place workflow by workflow.
Instrument what I'm going to be asked about later.
Every deployed system eventually faces the question "is this actually worth it?" — and the time to prepare the answer is week one, not the week the question lands. Even a crude counter beats a confident anecdote.
I learned this by omission: the honest weakness of the code-review pipeline is that its value is real but under-measured, because I decided too late which questions I'd be asked.
Hand the keys over.
Success is the thing surviving without me. That means operators who can run it, admin paths that don't require an engineer, and documentation aimed at the next person rather than at my own memory. A system that needs its author is a liability wearing a demo's clothes.
The volunteer system is run day to day by non-technical organisers. Making myself unnecessary was deliberate work — and the part I'd now start earlier.
Feed the pattern back.
What one user needed, three more will need. After each deployment I pull out the reusable shape — a guardrail model, an interface convention, a piece of tooling — so the next deployment starts further ahead.
The reads-are-broad, writes-are-proposals rule from the first of the MCP servers became the default shape of the next two, which shipped faster because the hard decision was already made.
Where I'm weak
Deep database internals — I tune queries and schemas competently, but I'm not the person who rewrites your storage engine. Large-scale SRE and Kubernetes — I run production systems, not thousand-node fleets. FinOps — I keep costs sane by keeping systems small, not by optimising cloud spend as a discipline.
If the core of the problem is one of these, I'll say so in the first conversation.