from the drafting table —
Building a custom design system for a growing direct-to-consumer insurance platform, from stakeholder alignment through component library, documentation, and cross-team adoption.
Berxi is a direct-to-consumer insurance platform built inside Berkshire Hathaway Specialty Insurance. The product was expanding quickly, and the frontend was expanding with it, but not in a coordinated way. Engineers were making design decisions independently across the codebase. Marketing wanted campaign flexibility they couldn't get. Engineering was burning cycles on visual work that should have been standardized. The job was to pull all of that together into a design system that the platform could actually grow on.
Step one
Color values, spacing, and typography were defined locally inside individual components. Every new feature made another quiet decision about how things should look. With no shared token architecture, those decisions never rolled back up into a system — they just accumulated as subtle differences between pages.
The consequences showed up on two sides. Marketing couldn't run campaigns or build landing-page variations quickly because the existing surface wasn't flexible enough to extend without engineering. And engineers kept rebuilding visual primitives slightly differently each time, which is how a growing codebase starts paying a drift tax on every new feature.
Before writing any components, the work was alignment. Getting product, design, marketing, and engineering to agree on a single source of truth so the system we built would actually be the system the platform used.
Color, spacing, and type defined inside components. Every new feature quietly disagreed with the last one.
Campaigns and landing-page variations needed developer time that engineering didn't have to give.
Step two
Tailwind gave us a utility-first model, expressive but constrained, and Vue's component model cleanly separated accessibility behavior from styling. On top of that, I built a token system in two layers so brand changes could propagate automatically without rewriting components.
The raw palette: colors, spacing steps, type sizes. No meaning attached, just values. This is what brand owns.
Role-based values: interactive element color, label-to-input spacing, body copy size. Components only ever referenced these, never the primitives directly.
A brand update changes a primitive. Every semantic token resolves to the new value. Every component using that semantic updates automatically. Nothing to hunt down.
color.navy.700 → resolves to → color.interactive.primary → consumed by → <Button variant="primary" /> Components never reach for primitives. They ask for a role. The system decides what that role looks like today.
The clearest signal that a design system is working is that it stops generating the friction that prompted building it.
Step three
Accessibility requirements were built into each component from the start: keyboard navigation, ARIA attributes, focus management in overlays, color contrast against the token palette. These were properties the components already had, not a checklist feature teams ran afterward.
This matters more as a system grows. An accessibility gap in a shared component isn't one gap. It's the same gap across every feature that uses the component. Building accessibility in at the system level meant every feature team shipped accessible UI without having to implement it.
Step four
Once the system was in place, the friction that had originally prompted the project stopped showing up. Marketing could run campaigns and build landing-page variations without waiting on engineering. Brand updates propagated automatically. Late-cycle visual inconsistency, the kind that used to get caught in review and ship anyway, stopped appearing, because the components no longer let you drift.
New engineers came up to speed faster because the library's API was consistent and documented, and because you could learn the system by reading it. The component library stopped being a source of ongoing debate and became part of the platform's quiet infrastructure.
Campaigns and landing pages shipped without an engineering dependency in the critical path.
Change a primitive and every component using that semantic token follows. No manual sweep required.
New engineers learn the system by reading it, because the documented component API is the system.
signed & filed —
Josh joined when our frontend was making the same decision in a hundred different places. He brought stakeholders into one room, set the token architecture, and shipped a design system the platform actually uses. Marketing got the campaign flexibility they'd been asking for, and engineering stopped reinventing the same components.
Adam Yasan
Managing Director · Berxi
A production-ready foundation: tokens, core components, accessibility baked in, and documentation your team can actually find. Start with a free scorecard, or grab 30 minutes.