About
I design products
and ship the code that runs them. That's the job.
I'm a design engineer. I do the design and the front-end code, both layers in one head. Teams hire me when designed and built need to mean the same thing: one person on the brief, the screens, and the React that ships.
What I actually do
Here's what that looks like in practice
I sit in the overlap between design and front-end. On most teams, designers hand off to engineers, engineers rebuild what they got, and a stack of small translation losses lives in the gap. I do both jobs myself, so what ships is what was designed. Not the version a developer had to interpret from a Figma file at 5 p.m. on a Friday.
In practice that looks like research and IA, visual design and design system work, then the real React, Astro, or Liquid templates that render the screens. Every case study on this site shipped that way. One person, both layers, no handoff. And the case studies themselves are structured the same way: what the problem was, what was on the table, what I chose, and what I traded. The point is to show the thinking, not the polish.
The work I'm best at is AI-powered SaaS and brand-led product work. Those are the places where design is doing the real work, not just decorating. With AI especially, the hard problem isn't the UI itself. It's the handoff moments, the seconds where a user has to decide whether to trust the model and keep going. That's where I do my best work, and the kind of role I'm looking for next.
How I work
Four things I bring to every project
- 01
Build what you design.
No handoff. Production tells the truth. I work in systems, not one-off screens. What ships is what was designed, because the same person held both layers from the first sketch to the deployed page.
- 02
Make complex feel simple.
Calm, obvious interfaces for dense product work. I care about the details most teams skip: empty states, keyboard navigation, type rendering, the moments where a user is most likely to lose the thread.
- 03
High taste, high follow-through.
Strong opinions, backed by the discipline to finish. Plenty of designers have one without the other. I try to bring both, so the work has a clear point of view and still actually ships.
- 04
Show the thinking, easy to work with.
Visible process, named trade-offs, clear writing. Calm in the room. The case studies on this site show the format. Every decision states what was on the table, why I picked what I did, and what got traded by picking it.
Tools + stack
What I reach for, by layer
Design
- Figma
- Design systems + tokens
- Component libraries
- Interaction prototyping
- User research
- Design handoff specs
Front-end
- React + TypeScript
- Astro
- Shopify Liquid
- CSS architecture
- Responsive systems
- Accessibility (WCAG 2.1)
Systems + tooling
- Git + GitHub workflow
- Vite / build tooling
- Component-driven dev
- Design-token pipelines
- CMS + headless
AI + product
- LLM / API integration
- AI-powered SaaS UX
- Trust + handoff moments
- Prompt design + tool use
- Product discovery
Outside the work
Three things that shape the taste
Star Trek
The show has been my long-running design touchstone. LCARS, the asymmetric panels, function-first interfaces decades before the rest of UI caught up. It's where I first noticed that interface design is really a form of world-building. A lot of how I think about clarity and confidence in a UI traces back to that.
Always a student
Over ten years as a student, and I never quite stopped. New framework, new corner of design, new tool: I want to learn it, then ship something with it. Learning and building are the same impulse for me, and it's why I'd rather not pick a single lane.
Traveling with my family
Most of the best parts of my life happen with my wife and kids. New cities, new food, watching the world land on my kids the first time they see it. Photography happens by accident on those trips. There's no way not to.
Let's talk
Hiring for a design-engineer role, or a project that needs both layers?
I'm open to full-time roles and taking select freelance work. The fastest way to start is an email. Tell me the shape of the work and the timeline, and I'll come back with whether it's a fit.