React frontend & UI systems
Design systems, component APIs, and the hard interface problems — forms, tables, data-dense views — built to scale with your team.
Overview
A design system is only worth building if it makes the next screen faster to build and harder to get wrong. I focus on the parts that decide whether that happens: a token layer that survives a rebrand, component APIs that are obvious to call, and documentation that lives next to the code.
Beyond the system itself, I take on the interface problems teams tend to avoid — multi-step forms with real validation, tables with filtering and virtualization, editors, dashboards, and anything with a lot of state on screen at once.
What ships
- Token architecture: colour, type, spacing, radius and motion as CSS variables, themeable and dark-mode ready
- Component library with a consistent API surface, sensible composition, and accessible primitives (Radix or headless equivalents)
- Complex forms: schema-driven validation, error and pending states, keyboard flows, and autosave where it helps
- Data-heavy UIs: sortable and filterable tables, virtualization, optimistic updates, and empty and error states that are actually designed
- Living documentation — usage, props, do and don't, and accessibility notes — kept in the repo
- A contribution guide so the system does not rot the moment I hand it over
A good fit when
- Every new screen is rebuilt from scratch and they never quite match
- You have a component library that people work around instead of with
- A specific interface — an editor, a builder, a console — has stalled
- Design and engineering are describing the same component differently
FAQ
- Do we need to adopt shadcn/ui?
- No. shadcn is a good default because it keeps the components in your repo, but I have worked inside MUI, Chakra, Mantine and fully bespoke systems. I match the approach to what your team already knows.
- Can you work from Figma?
- Yes. I am comfortable reading a Figma file, spotting where the design and the token set disagree, and flagging the components that will be expensive before they are built.
- Is accessibility included?
- It is not a separate line item. Focus management, semantics, contrast and keyboard support are part of building the component correctly, and I test with a screen reader as I go.
Tell me about your product
Share a short brief — problem, timeline, and stack — and I'll reply with a candid view on fit, effort, and the fastest path to a shippable milestone.