About

What I'm looking for

I'm looking for a senior or staff individual-contributor role with real ownership: end-to-end product work, full-stack, comfortable with ambiguity. Small team, low process, async-friendly, with tenured peers who take the craft seriously. Growth-stage B2B SaaS or a high-bar boutique agency is the right shape. I want control over the decisions that shape the product, and I want to make them alongside people whose seriousness matches mine.

After about fifteen years working mostly on my own, part of what I want from this move is what solo work can't give me: a larger engineering organization, peers to learn from, and data at a scale I haven't had to handle yet.

How I think

Handed a problem, I want to step back and ask what we're actually trying to do, and why. Most of the cost of bad software is paid upstream of the code, in assumptions no one questioned. I'd rather spend an extra hour clarifying the goal than ship something well-built that solves the wrong problem.

I pick words carefully, in code and in writing and in conversation. The name of a function shapes how everyone thinks about it, and the phrasing of a decision tends to stick, so I treat naming and framing as part of the work rather than a finishing touch. If I take a beat before answering, it's usually that I haven't found the phrasing I want yet, or that I don't yet know what I think.

I care about edge cases, error messages, what happens when the network drops mid-upload, what a page looks like on a slow connection. Details are usually where trust is won or lost, so that is where the attention goes. The part of the work I enjoy most comes earlier than any of that: exploring a new domain, talking through tradeoffs, finding the edges of a problem. I'd rather understand a problem thoroughly before I start solving it, and most of the time that is where the real difficulty turns out to be.

What I find good

When I look at code and think it's good, it usually comes down to a few things. One is that it composes simple pieces: small functions that each do one thing, combined to handle the complexity, rather than fat objects hiding state or clever inheritance lattices. Related to that, errors get dealt with at the boundaries, with edge cases handled up front through guard clauses and early returns, so the happy path stays uncluttered and it's clear where the system trusts its inputs and where it checks them.

And every abstraction has to earn its weight. Layers, interfaces, and frameworks all cost something, and if that cost isn't paid back by what they buy you, they shouldn't be there. The thing I'm most allergic to is cargo-cult complexity: something copied from a place it made sense and pasted into a place it doesn't.

What I'm uncommonly good at

A few things I'm distinctively good at. The one I'm most confident in is translating fuzzy needs into systems: sitting with a non-technical stakeholder, listening past what they're asking for to what they actually need, and shaping it into something concrete enough to build. I've done that for executives at small firms for years. I also tend to keep the whole stack live in my head at once, from database to backend to API to frontend to infrastructure, where most engineers specialize in a layer or two and treat the rest as dependencies; holding the whole graph lets me find the right seam for a problem instead of forcing it into whichever layer I happen to be working in.

Closely related is making dense things legible: taking a mechanism, a domain concept, or an architectural decision and explaining it to a smart non-expert without losing the substance. It's the same skill whether I'm writing a spec, reviewing code, or pitching an idea to leadership. The last one only shows up over time, which is building things that still work and still make sense years later, because I'm usually the person still maintaining them. A decade of living with my own code has taught me which choices age well and which don't.

On AI tooling

I've used Claude Code daily for about six months as the implementation engine for an AI-first rewrite of a legacy codebase. A few things have held up over that time. The model does the typing; I hold the spec, the design, and the quality bar, and the architectural judgment stays with me. It's a real multiplier on what's already there, in that one person can carry a lot more, but it doesn't supply the taste or the judgment, so those still have to come from me. It also needs more care around it than people expect: without tight specs and clear design contracts, the output is plausible-looking work that compounds into a mess fast.

I'm hands-on enough now to have specific opinions and concrete experience. I haven't yet run or hosted LLMs in production, done serious RAG or fine-tuning work, or deployed agents at scale. Those are areas I want to grow into.