How I work
A short user manual.
The stuff a résumé leaves out — how I think, where I'm strongest, how I like to collaborate, and what I'm still working on. If we might build something together, this is the fastest way to know what you'd be getting.
01How I operate
I'm a product engineer who ships cross-platform software end to end. My instinct is to collapse a problem into shared, typed domain logic — state machines, schemas, contracts — then let a single codebase reach web, mobile, and desktop at once instead of rebuilding it three times.
Recently that's looked like PairSync (P2P file sharing, no cloud), a fintech savings platform with an idempotent transaction ledger, and Notemark (notes everywhere, end-to-end type-safe). I reach for tools like Drizzle, Zod, and XState because I want behavior that's legible and hard to break.
I invest in the boring infrastructure early — tests, CI, typed boundaries — because that's what keeps shipping fast from turning into shipping regressions. I care about the small things, since that's usually where a product feels considered instead of assembled.
02Where I add the most value
Turning a fuzzy problem into a typed domain model — the state machines, schemas, and contracts a product can be built on without constant rework.
Shipping one codebase to web, mobile, and desktop instead of maintaining three that quietly drift apart.
Owning a product end to end — schema, services, and interface — so there are fewer handoffs and less lost context.
The unglamorous reliability work: tests, CI, and typed boundaries that keep a fast pace from turning into a fragile one.
03Working with me
I like a clear problem statement over a prescribed solution — give me the outcome and the constraints, and I'll come back with options and tradeoffs.
I default to written, async context — short docs and tight PRs — so decisions stay legible long after the conversation.
I ask “why” before “how,” and I'll push back respectfully when something feels wrong — then commit fully once we've decided.
I prefer small, reviewable changes that keep the app working at every step over big-bang rewrites.
I treat design as a partnership; the products I'm proudest of came from engineers and designers arguing, in good faith, over the details.
04What I'm still sharpening
Knowing when “good enough” is genuinely enough — left alone, I'll invest in architecture before the problem has earned it.
Delegating the polish I enjoy doing myself, so the work scales past my own hours.
Writing more, and earlier — shipping the thinking, not only the code.
05A few principles
- 01
Make it work, make it legible, then make it fast.
- 02
Boring infrastructure is a feature.
- 03
The small things are the product.
- 04
Optimize for whoever maintains this next — usually me.
- 05
Ship in slices; keep it working the whole way.