Shipping a design system into a live product

Migrating the Leasetic partner extranet onto a shared component library, phase by phase, on a green test suite, and building the Colibris product screens on its new App Shell.

Role: Design engineer and migration lead Tools: Claude Code, Next.js, Tailwind, ReUI and shadcn, Vitest, Vercel Year: 2026

A design system only matters once the product runs on it. In the Leasetic Extranet, the group's component library had been installed and then left on the shelf: 38 base components, 9 ReUI components and 18 ready made blocks, of which 17 had no importer at all. The interface was still hand built, with 611 inline style objects across 87 files, and 26 tests were failing before any work started.

I surveyed the whole codebase before touching it and ranked every shared file by real difficulty, from dead code to the six hardest components. Two findings shaped the plan:

Three legacy tokens carried 55% of all styling references. Mapping those three cleanly was the highest leverage move available.

114 tests checked class names rather than behavior, so they would break by design. Rewriting them around roles and behavior became its own workstream.

The work then ran in phases ordered by real dependencies: get to green, lock the token spine, migrate the primitives, replace the shell, then the lists and tables. Every phase had to land on a passing suite, a clean lint gate, a clean production build and a visual check in light and dark mode.

Halfway through, comparing the result with the library's reference changed the direction: the app would adopt the library's own design language and keep only three things from Leasetic, the logo, the green accent and the large 1rem radius. The accent went on primary actions, the sidebar and focus rings, deliberately not on the hover token, which would have turned every hover state green.

Instead of editing roughly 400 call sites, I pointed each legacy token at its new equivalent. The whole legacy interface took on the new look in one change, and old aliases can now be deleted file by file. One trap stayed visible on purpose: the old code used "muted" as a text color while the library uses it as a surface, and collapsing the two had once made labels invisible on white.

The plan first called for the library's data grid on every list. Checking the data layer showed why that was wrong: the lists use server side search and cursor pagination, which keeps paging stable while proposals are created and archived underneath. The grid would have meant either a cosmetic swap or a data rewrite that regressed correctness. The lists moved to the simpler table primitives instead.

On the Colibris side, the new App Shell components power product screens modelled on the live platform: an ESG overview dashboard, a fleet module with filters and expandable analytics panels, and a monthly steering report viewer of five A4 pages that prints straight to PDF, deployed on Vercel.

Automated tests: from 26 failing to 1,189 passing.

Hand built sidebar: 459 lines replaced by the library sidebar, with its collapse state read by the server and no flash on load.

Dead or superseded code: 1,262 lines deleted.

Bespoke CSS classes: all 13 retired.

Production bugs found in the survey: a broken logo on the login page and a theme toggle that did not apply, both fixed.

All seven phases are now complete: after the lists and tables came the proposal wizard and forms, the public pages, and the removal of the old styling system. The figures above were measured at the end of phase 4.