Why I'm writing this in public

I've spent twelve-plus years getting software into production and keeping it there — across banks, telecom, and now environmental services. The way I work is the way a product owner does: decide what's worth building, set the brief and the guardrails, sequence by impact and risk, and steer the thing into existence. Most of that work lives behind enterprise firewalls, where the lessons are real but the audience is small. This site is where I do some of it in public.

The two halves of the job

I care about the whole lifecycle — not just shipping a feature, but owning it at 2 a.m. when something breaks. "Build" and "run" are usually treated as separate disciplines. I think the most interesting decisions happen at the seam between them: the choices in scope and design that decide whether the thing is calm to operate later. Those are product calls, and they're the ones I want to write about.

Building through Claude

The newer half of the story is how these get built. My job has never been to write every line — it's to decide what's worth building, set the brief and the guardrails, exercise judgment, and review what comes back. Increasingly that means building through Claude: I own the product direction and hold the line on what "good" and "done" have to mean, and the AI does a lot of the typing. The projects here are where I pressure-test how far that goes — and each one taught me something about the job itself when the building is no longer the bottleneck.

What's next

I'm filling this out over time. Expect project write-ups that lead with the decisions, not the implementation trivia, plus notes on delivery, reliability, and learning by building in the open. If a post here saves you a headache or sparks an idea, that's the whole point — more to come.