Product design & frontend engineering.

I start most projects by trying to find the smallest version of the problem — the one screen, one flow, or one fix that actually matters — and build that first, properly, before expanding outward.

That usually means fewer features than a kickoff deck promises, and more attention to the parts people interact with constantly: load times, empty states, error messages, the things that quietly decide whether software feels good to use.

Outside of client and product work, I maintain a couple of small open-source tools and write occasional notes on what I learn building them.