Anvil Design System
Built and scaled an enterprise design system from scratch, leading a team that served 385 users across 32 product teams and delivered $5.3M in annual efficiency gains.
ServiceTitan builds software for tradespeople. Plumbers, electricians, HVAC technicians. When I joined, engineering had three competing UI frameworks and design had loose guidelines but no shared component language. Every handoff was a negotiation. The technical problem was solvable. The harder problem was cultural: getting two disciplines to trust the same system.
My Role
I applied for a Product Design role. During my interview I walked through design system work from a previous job, and the Director of Product Design called me afterward with a different pitch. They’d been trying to get a design system going but kept hitting walls between design and engineering. He asked if I’d come in to focus on that problem instead.
I built the initial system solo in the first six months. Architecture, components, documentation, and the process infrastructure around it. Over four years I grew the team, hiring Design Technologists who could build production React components and have the design conversation at the same time. By the end I led a team of four serving 32 product teams, mostly through a contribution model, office hours, and pairing directly with teams that had the hardest time adopting.
The Core Challenge
The instinct was to build a component library and call it a system. The actual challenge was trust. Designers wanted flexibility. Engineers wanted stability. Neither wanted to give up autonomy to a team they weren’t sure would understand their constraints.
The design decision that mattered most wasn’t which button style to ship first. It was making code the source of truth, which meant designers had to accept that Figma files followed code, not led it. That was a hard sell. Early on, a senior designer pushed back hard. Their team had spent weeks on a custom pattern and didn’t want to wait for the system team to rebuild it. Instead of blocking them, we shipped their pattern as a contributed component with guardrails. They got speed. We got adoption. And the next time, they came to us first.
Three UI frameworks, no shared language. This audit mapped every unique pattern across products and made the inconsistency impossible to ignore. It’s what got the project funded.
The documentation site lived in the same codebase as the components. One source of truth for designers, engineers, and PMs. If it wasn’t documented here, it wasn’t part of the system.
We debated whether dropdowns should support async data loading for months. Specs like this forced those decisions into the open before code was written, not after three teams had already implemented it differently.
Not just what we built, but why. Documenting hypotheses meant new team members could understand the reasoning behind decisions instead of just inheriting them.
Release notes, migration guides, adoption training. A design system that ships components without a communication layer is just a repo.
The System in Product
I didn’t design these screens. Product teams across ServiceTitan did. That’s the point. These products were built entirely with Anvil components.
What I’d Do Differently
I underestimated adoption friction. We tracked component usage but not migration pain. Teams stayed on old versions for months because updating was a project in itself. I’d have invested earlier in automated migration tooling, and pushed harder on mobile parity from day one instead of treating iOS and Android as a second phase.
Outcomes
The moment I’m most proud of: a company all-hands where leadership launched a new product. People in the chat called out how polished it looked, how much better it felt than anything before. That product was built entirely with design system components. Nobody mentioned the design system by name. They didn’t need to. That’s what winning looks like for infrastructure work.