Three Design Systems in One Monorepo: Exaggerated Minimalism, Warm Amber, Claymorphism
One monorepo, seven apps, three audiences. A visitor evaluating our studio wants something different from a family member browsing photos, and both differ from a six-year-old playing a math game.
One token pipeline, three themes
Everything flows through CSS custom properties:
:root {
--color-background: #ffffff;
--color-text: #09090b;
--color-cta: #2563eb;
}
- Corporate (main, blog, work, product, dashboard): Exaggerated Minimalism — monochrome base, one blue accent, Archivo + Space Grotesk, oversized display type.
- Family (family portal): Warm Amber — the same structure with
--color-cta: #d97706, softer radii, warmer neutrals. - Kids (kids space): Claymorphism — indigo/orange palette, chunky shadows, rounded everything, Baloo 2 + Comic Neue.
The components are identical. The tokens are different. Button, Card, Modal from @vietprohub/ui render correctly in all three because they reference variables, never hex values.
Where it breaks down
Component-level hardcoding is the constant enemy. A text-gray-900 sneaking into a shared component looks fine on the corporate site and wrong everywhere else. Our rule: Tailwind utility classes for layout only; color and typography always through tokens.
What this buys us
- A fix to one component improves all seven apps
- Onboarding a new app means choosing a theme, not building a UI kit
- The design tokens file doubles as documentation — it is the design system
The cost is discipline. Every PR gets a quick scan for hardcoded colors in shared packages. It's a small rule that keeps three brands from becoming three codebases.