The Problem With Most Component Libraries
Most component libraries fail not because they're poorly engineered, but because they're built in isolation. A small team spends months crafting perfectly abstracted components, publishes the package, and then watches it quietly gather dust while every application continues building its own button components.
The graveyard of internal design systems is full of technically excellent work that nobody used.
At Guild Mortgage, we did it differently.
Why This One Worked
Before writing a single component, we spent time with the teams who would actually use the library. We sat in on their development cycles. We looked at the UI patterns being duplicated across applications. We asked what was painful to build, what got rebuilt from scratch on every new project, and what inconsistencies between apps created confusion for end users.
The library was designed around real answers to those questions — not around what a component library is theoretically supposed to contain.
What We Built
The library covered the full spectrum of UI primitives and composite components that appeared across Guild's 8+ single-page applications: form elements, data tables, notification patterns, layout scaffolding, modal and drawer systems, loading states. Built with React, TypeScript, and SCSS, with every component documented and demonstrated in Storybook.
TypeScript wasn't optional. Typed component APIs caught integration errors at compile time rather than runtime, which dramatically reduced the back-and-forth between the library team and consuming applications. Storybook served as both documentation and a living design reference — designers and developers could look at the same source of truth.
Accessibility was treated as a first-class requirement, not an afterthought. Every component shipped with ARIA attributes, keyboard navigation, and contrast ratios that met WCAG AA standards. When teams adopted the library, accessibility compliance came with it.
The Coding Standards Layer
Alongside the components, we established and documented coding standards and reusable patterns that governed how the library should be extended and how consuming teams should structure their own code. This was the work that had the longest tail — it shaped how engineers across the organization thought about componentization and reuse long after the initial library was shipped.
The Numbers
125+ developer hours saved monthly across teams that adopted the library. UI consistency improved measurably across all 8 applications — fewer one-off components, fewer divergent design patterns, fewer accessibility bugs making it to production.
But the number I was most proud of wasn't the hours. It was the adoption rate. Eight teams actually using a shared library is not the default outcome. It's what happens when you build something that solves real problems, document it thoroughly, and show up to help teams integrate it.
Build for adoption. Everything else follows.
