Case Study·Client project·Design system
In productionA SaaS company's products had each grown their own buttons, tables and forms. We built a shared Vue 3 component library on design tokens: 100+ accessible components, per-product theming, Storybook docs and versioned releases teams could adopt without a feature freeze.
Vue 3
TypeScript
Vite library mode
Storybook
Design tokens
Vitest
Playwright
Context
The client sells several products to the same customers. Each one was built by its own team, and over time each grew its own components. A customer moving between products saw different buttons, tables and error states, and every UI fix had to be made several times.
They wanted one design system: shared components that look the same, behave the same and meet accessibility requirements, without stopping feature work to adopt it.
We built the tokens, the component library, the documentation and the release process, and helped each product team adopt it. It's a client project, so this page describes our engineering without publishing the client's name or code.
The Journey
We started from what already existed, put the visual decisions into tokens, built components in order of how much they were used, and moved products over screen by screen.
Each product had grown its own buttons, tables, modals and form fields. We screenshotted and catalogued every variant across the apps, grouped the duplicates, and agreed with the designers which patterns the system would keep.
Colours, type, spacing, radii, shadows and motion became named design tokens, generated into CSS custom properties. Components only use tokens, so a product can be re-themed by changing tokens rather than overriding component styles.
We built the most-used components first: buttons, inputs, selects, date pickers, tables, tabs, modals, toasts and navigation. Each one ships with typed props, slots for the cases props can't cover, keyboard support and a Storybook page.
Nobody stopped shipping features for a big-bang rewrite. Each product moved screen by screen, starting with the pages it touched most often, and old components were deprecated with clear replacements.
Every release is versioned with a changelog and upgrade notes. Breaking changes are rare, announced a release ahead with deprecation warnings in development, and come with a codemod where one is practical.
Hard Problems, Solved
Building components is the easy part. Getting several teams to use them, and keep using them, is the work. These are the problems we solved, described without exposing the client's code.
Where this applies to you Companies whose products grew separately and now need to look and behave like one family.
Where this applies to you Teams building component libraries that several products will depend on.
Where this applies to you Products with accessibility requirements from customers, procurement or regulation.
Where this applies to you White-label products or companies with several brands on one codebase.
Where this applies to you Any team publishing a package that other teams depend on.
Where this applies to you Libraries that need adoption across teams, not just a package on a registry.
Vue Depth
Props, emits and slots are fully typed, so editors autocomplete and misuse fails the build.
Vite library mode with tree-shakeable exports, so apps only ship the components they use.
Tokens compiled into CSS custom properties and typed constants from one source file.
Shared behaviour like focus trapping, floating positioning and keyboard lists lives in composables the components reuse.
Inputs work with v-model and expose validation states, so they fit whichever validation library a product uses.
Sorting, selection, pagination and empty states, built from small exported parts.
Behaviour and accessibility of each component tested in isolation.
Every story is screenshotted in a real browser and compared on each pull request.
Is This You?
Bringing apps that grew separately into one consistent family.
Designing and building a Vue 3 library other teams will depend on.
Meeting WCAG targets without asking every team to become an expert.
Several brands or customer themes on one codebase.
FAQ
Yes. We built the design system for a SaaS company with several customer-facing products. The client's name and code aren't published, so this page describes the engineering and the outcome.
Not always. If an existing library fits your design closely, theming it is cheaper. A custom system pays off when you have several products, a distinct design, or accessibility and theming needs a general library doesn't meet.
No. On this project each product moved screen by screen alongside normal feature work, starting with its most-used pages.
Yes. Tokens and component variants map directly from Figma, and designers review each component in Storybook before it's released.
Yes. The library is plain Vue 3 and renders on the server, so it works in Nuxt apps as well as Vite single-page apps.
Send us a short note on the contact page about your products and where the UI is drifting apart. We'll set up a call to look at your apps and designs.
Get started
Talk to the engineers who built this Vue 3 design system. Tell us about your products and where they've grown apart.
Matched in 24 hours·48 hours free on every plan·No long-term contract
