Building a Component Library from Scratch

The problem

A product team I joined had four separate frontend codebases that had grown independently over two years. The same button existed in six variations. Forms had three different validation patterns. Every new feature started with “which version do we copy from?”

The inconsistency wasn’t just aesthetic — it was slowing down every sprint and making QA unpredictable.

Scoping the work

Before writing a line of code, I spent a week auditing the four codebases. I catalogued every UI pattern, flagged duplicates, and identified the 20 components that covered roughly 80% of all screen real estate. That became the v1 scope.

I pushed back on requests to include complex data visualisation components in v1 — those could come later once the foundation was stable.

Building it

The library was built with React and TypeScript, with Storybook as the documentation layer. Each component had a defined API, written prop types, and at least one story per variant.

The hardest part wasn’t the code — it was the migration plan. Replacing components in four active codebases without breaking anything required a deprecation strategy, clear changelogs, and a lot of async communication with the team.

The outcome

All four products migrated to the library within 6 weeks of v1 release. New feature UI now takes roughly half the time to build — developers reach for the library first rather than building from scratch. Storybook became the shared source of truth that product, design, and engineering reference in every sprint.