Inbound · Design Engineer
Inbound is an early-stage product, and early-stage products share a familiar problem: the interface grows faster than the decisions behind it. New screens appear every week. Each one is styled in the moment. It works, until it doesn't.
I joined to help with design, and stayed involved through implementation. That combination shaped everything I did there.
The first job was to slow the visual drift. I helped build and improve the design system: the colors, type, spacing, and components that every screen draws from.
The goal was never a perfect component library. The goal was that two people building two different screens would arrive at interfaces that look like they belong to the same product. Once the system covered the common cases, most screens stopped needing design decisions at all. They just needed assembly.
On top of the system, I designed for both sides of the product: the dashboard, where people do the actual work, and the marketing pages, where the product has to explain itself.
These pull in opposite directions. Dashboard design is about density, hierarchy, and staying out of the way. Marketing design is about clarity and a first impression. Working on both, with one shared system underneath, kept the product feeling like one thing instead of two.
A design system only counts if it survives implementation. So I didn't stop at handoff. I turned my own designs into production-ready code: real components, real states, real edge cases.
This closed the loop that usually breaks. When the person who designed the screen also builds it, nothing gets lost in translation. Spacing stays intentional. Hover and loading states actually get built. And when a design decision turns out to be awkward in code, it gets fixed in the system, not patched in one file.
By the end, Inbound had a shared visual language, dashboard and marketing surfaces that matched it, and components in production that the team could keep building on without re-deciding the basics every time.