One Monorepo, Many Brands: How Shared Tokens Keep a Portfolio Coherent

Run more than one product and you meet two failure modes. In the first, every brand is built separately, and within a year the spacing, buttons, and error states no longer agree. In the second, everything is shared, and the brands turn into one brand in different colors.

Both come from the same mistake: no one decided where the line sits between what is common and what is personal. At Artasce, the ArtasceOne approach is our answer. It combines one repository with one token layer, and an explicit rule for what belongs in each place.

Why one repository

A monorepo does not make brands coherent. It makes drift visible. When the artasce.com navigation and a sister brand’s navigation live side by side, a change to one shows up in the same review as the other. Nobody has to remember to check.

It also changes the cost of fixing things. A contrast bug fixed once is fixed everywhere that inherits it. Iteration gets faster because the foundation is shared, which is the real advantage of the setup.

Tokens are the contract

Design tokens are named values: a color, a radius, a step on the spacing scale. Components read tokens instead of raw values. That one indirection is what lets a single component serve several brands.

Our Crystal Design System is built this way. A theme, such as Onyx for Artasce, supplies the values. The components never learn which brand they are rendering.

--ac-color-text-primary: #141414;
--ac-color-background: #F5F4F0;
--ac-radius-md: 8px;

The ac- prefix is the quiet hero here. It tells you whose token this is.

What prefixes actually do

A prefix is a namespace, and namespaces prevent two problems.

• Collisions. Two brands can each define a primary text color without overwriting each other.
• Ambiguity. When you read a stylesheet, you know at a glance whether a value is Artasce’s or belongs to another brand.

Each brand keeps the same token structure under its own prefix. The names line up, and the values are free to differ. That is how shared components stay shared without forcing shared looks.

What we share, and what we don’t

Shared things are structural. They shape how an interface behaves and holds together. Brand-specific things are expressive. They shape how it feels and who it sounds like.

Shared across the portfolio:

• The spacing scale, which follows Fibonacci steps: 4, 8, 16, 24, 40, 64, and so on
• The radius scale and the type scale ratio logic
• Token naming conventions and component behavior
• Accessibility baselines, such as contrast and focus states

Specific to each brand:

• Typeface. Artasce, Artasce Creative, and AC Models share Urbanist. Modolla, Voya, and caitoy.com each keep their own type identity on purpose.
• Color and logo
• Voice and copy
• Photography and imagery direction

Typography is the clearest example. A typeface does more to tell brands apart than almost anything else, so we do not share it across brands that need distinct identities. The spacing rhythm underneath can be identical, and no one notices, because rhythm reads as quality rather than as identity.

Deciding which side a new decision falls on

New decisions arrive constantly. A new card style, a new motion curve, a new form pattern. We run each one through three questions.

1. Would a customer use this brand’s identity to recognize it? If yes, it is brand-specific. Color, type, imagery, and tone all land here.
2. Would the same fix be right for every brand? If a bug in this decision would need the same patch everywhere, it is shared. Focus rings and tap target sizes are examples.
3. Is it a value or a rule? Rules, like “modal padding uses the 24 step,” tend to be shared. Values, like the exact shade behind that modal, tend to belong to the brand.

When the answers conflict, default to brand-specific and revisit later. Promoting something into the shared layer is cheap. Pulling it back out, after four products depend on it, is not.

Applying this to your own portfolio

You do not need a full system to start. A workable first pass looks like this:

1. Put your products in one repository, or at least one shared package.
2. Choose a prefix per brand and apply it to every token.
3. Extract spacing, radius, and type ratio first. They are structural and almost never contested.
4. Leave color and typeface in each brand’s own theme from day one.
5. Write down the three questions above and use them in reviews.

The written rule matters more than the tooling. Without it, every ambiguous call turns into an argument, and arguments tend to resolve toward whatever is fastest that week.

Coherence is a choice you keep making

A portfolio holds together because someone keeps asking where each decision belongs. Shared tokens make the answer cheap to apply, and prefixes make it easy to read. The rest is judgment, and that part does not automate.

If you are running several products and the seams are starting to show, we are glad to talk through where your line should sit.