About
I work upstream, before the screens exist.
I work on the boundary between what a system can do on its own and what still needs human judgment.
How I work
What I do.
I frame product direction, map operational workflows, define permissions and decision boundaries, and build enough of the system to test whether the idea holds up.
Four practices, same shape: a high-stakes workflow, an AI system ready to act inside it, and no shared language for how the two should cooperate. My job is to make that cooperation legible through briefs, diagrams, prototypes, and working software.
The work I'm proudest of is upstream. Problem framing. Structural decisions. The diagrams that turn months of debate into one decision.
Where I've done it.
- Compass Healthcare Digital
- ServiceNow
- Charles Schwab
- Wells Fargo
- Full experience
Toolset
The tools I reach for.
A working kit, not a fixed stack. I use what gets the idea tested properly and into someone's hands.
Design
Figma · Framer
Build
Claude Code · Cursor · TypeScript · Next.js · Tailwind · shadcn/ui
AI + agents
Claude API · OpenAI API · MCP
Evaluate
Behavioral evals · regression checks · screenshot diffs · citation checks
Ship
Vercel · Playwright · Linear
Off the clock
Elsewhere, usually.
Off the clock, I'm usually somewhere between a long drive, a camera, a kitchen, and an animal I've stopped to watch for too long. I notice buildings, old signs, odd interfaces, and the way people improvise around systems. I like cooking when there's time to make a project of it, photographing places that feel lived in, and taking the scenic route even when it's objectively inefficient. Dogs generally improve the plan.
FAQ
Questions I get asked.
A role where the upstream call is open. I am most useful early, before those decisions are made.
I take ideas far enough to become working systems: this site, prototypes, integrations, and product experiments. I partner with engineers where architecture, scale, security, and production performance require deeper specialization.
I bring the problem early, with the reasoning and constraints visible. Because I build, I can usually distinguish an implementation constraint from a design preference, which makes the conversation shorter and more useful.
Say so once, clearly, with the reasoning written down. Then commit to whatever gets decided and make it work.
I read the product, watch people use it, and look for the decision everyone has quietly built around. By the end of the first month, I want the assumptions, constraints, and unresolved product questions visible enough that the team can act on them.
Compare notes
System acts
Where errors are bounded and recoverable.
Pauses for approval
Where a person sees the evidence before the system commits.
Hands control back
With a clear record of what changed, what triggered it, and why.
Send a note. I reply within two business days.