Scaling a design system from one app to eight

A design system is only useful if it is actually used. We built ours to save time on each template, but the harder problem is keeping it in sync as the product evolves.

The constraint

Eight apps, each published as a separate package. Customers should feel like they are using a family of related products, not eight independent forks. The baseline: colors, spacing, typography, and the core UI components must be identical everywhere.

This ruled out copying components. Copy is the first bug: it becomes stale, inconsistent, and harder to fix across eight places. Shared code was the only option.

The approach

Rather than publish the design system separately and expect every template to update, we embed it. The system is a private set of TypeScript files that each template can cherry-pick at build time.

finora/
├── components/ui/Button.tsx
├── components/ui/Input.tsx
└── constants/theme.ts

No NPM. No separate versioning. No deployment delays. A theme ships with the design system it was built against.

Managing evolution

The risk: what if we want to change Button and one template should keep the old version? In practice, we haven't needed to. Every change has been backward compatible or has upgraded all eight templates in a single publish. The advantage of owning the whole stack is that we can afford to be opinionated.

The cost: six new files or a color shift means checking eight templates for side effects. It is work. But it is much less work than supporting eight different design systems.

What we learned

A shared design system is only good infrastructure if the cost of using it is lower than the cost of diverging from it. We achieve that by keeping the number of shared components small—Button, Input, Card, Badge, and nothing else. Anything more specific lives inside the app.

Ask yourself before every new component: could this live in the product instead? If the answer is yes, it probably should.