“That is how design systems die: not abolished, just bypassed.”

One design system, thirty brands, and an app that could no longer be installed

A hundred components carrying more than thirty white labels — and three years later, the same client asked us back to rescue their Android app.

Get in touch

Returning client · 2022 — design system, one engineer, 2 months · 2025 — Android, team of 3, 6 months

~100

components, one engineer, 2 months

30+

white labels from the same code

years later — same client, other discipline

Summary

The client sells software that turns a photograph of a floor plan into a cost estimate and a phased work plan — and sells it under other companies' brands.

We built their central design system in two months, with one engineer. Three years later they brought us back for something entirely different: their Android app had stopped being installable on current devices.

This is the only client in our work who returned — and on a different discipline. That says more than any component.

2022 · The problem

The product is white-label. More than thirty construction companies each get their own colors, logos and imagery. That number is what makes tokenization not a good practice but a precondition — a hundred components across thirty labels, implemented naively, is three thousand variants nobody maintains.

2025 · The constraint

The app could no longer be installed on current Android. Libraries were abandoned, APIs deprecated. An app in that state does not fail loudly; it quietly stops existing for every new user, and existing users lose it the moment they change phones. But a large share of phones on a construction site are several years old — so the fix could not come at their expense.

What we did

The design system, 2022, one engineer
Design tokens exported from Figma into JSON and generated into SCSS, with about a hundred components built on top, organized by size, type and kind. Versioned, distributed as a package, with its own documentation.
~100 components in 2 months
No component knows its own color
Only a token name. A new client is a new set of values, not new code. That is the whole reason thirty labels are maintainable.
A new brand, no new code
Framework-agnostic on purpose
Two different products consume the library; tying it to a framework would mean every consumer outside that framework needs its own implementation of the same design, which is precisely the problem a design system exists to solve.
Two products, one library
At a hundred components, taxonomy is not tidiness
Without consistent organization a library that size becomes a search through filenames — a developer does not find what they need in thirty seconds, concludes it does not exist, and writes their own CSS. That is how design systems die: not abolished, just bypassed.
Thirty seconds to a component
The Android rescue, 2025, a team of three
We brought the app back so it runs on both current and older devices. Camera permission compliance after a store policy change, dependency upgrades for document viewing, and work moved off the main thread.
New and old devices

THREE DECISIONS THAT CARRY THIRTY LABELS

The token — nothing knows its color

Tokens exported from Figma into JSON and generated into SCSS. A component knows a token name, never a value — so a new brand is a new set of values, not new code. Without that, a hundred components across thirty labels is three thousand variants nobody maintains.

None of the three is about appearance. All three are about the library surviving its thirtieth brand and its hundredth component.

The result

~100 components carrying 30+ white labels, built by one engineer in two months
Versioned package with documentation, consumed by two products
An app that had become uninstallable, returned to both new and old devices
The same client, back after three years, on an unrelated discipline

What we’d do differently

The documentation was custom rather than a standard tool, which made it one more thing to maintain and one more thing a new developer had to learn. For a library with thirty consuming brands, we would take the boring standard option.

Five problems and the system that answers themWhere that fifth problem was paid for the first time.A construction ERP next to SAPAnother construction client, another kind of constraint.

All 18 case studies