You built the site. It works. The team knows where the buttons are.
Then someone mentions the second brand launches in March, and it needs its own domain, its own colours, and a header that does not look like the one you just shipped. Same portal. Same team. Same you.
This is the moment a HubSpot build stops being a website and starts being an estate. The decision you make in the next hour will either cost you an afternoon or cost you every afternoon for the next two years.
HubSpot handles the account side of this well. Brands — the feature formerly called Business Units — lets you run separate domains, email templates, subscription settings and reporting from one portal, with the CRM shared underneath. If you are a portfolio company, a regional group, or a franchise, that part is solved.
The theme side is where it gets thin.
Theme settings are theme-wide. Change a colour and it lands on every page and template using that theme — which is the whole point inside one brand, and the whole problem across two.
One set of settings. One look. So the second brand has to live somewhere else.
HubSpot's answer here is the child theme, and it is a real feature rather than a workaround. A child theme points at a parent and inherits from it, so you get the parent's structure without copying it.
Then you read the line that decides everything:
“A file in the same relative path of a child theme will overwrite the equivalent file from the parent theme.”
By default the child inherits fields.json, so you stay connected and every brand wears the same settings. Drop your own fields.json in to get your brand colours and it overwrites the parent's. Connected in name. Separate in practice.
Same for everything else. A child theme does not copy the parent's templates, modules, stylesheets or scripts — you clone each one by hand when you need to change it. So the split is never one decision made on day one. It accumulates, a file at a time, every time somebody needs something slightly different.
The problem is not the copy. The problem is what happens after it. Every fix you make to a copied module has to be made again in each child that copied it, by hand, forever. Miss one and the brands drift apart — never obviously, just enough that a card has slightly different padding on one site and nobody can say when that happened.
It gets worse in a specific way that is easy to miss. The clones do not fail loudly. They fail by omission. A buyer of your own work opens the third brand's site a year later, finds a spacing bug you fixed on brand one, and there is no error anywhere to explain it. You just never carried the fix across.
If you have ever inherited a portal with four themes named theme, theme-new, theme-v2 and theme-final, you have met the end state.
The other route keeps one theme and makes the brand a configuration of it. No child, no copied files, no second place for a bug to live.
That only works if the theme was built for it, and most were not. The test is blunt: open theme settings, change your brand colour, and look at the page. If a single value in that panel fails to move the site, the theme is not a design system — it is a design with a settings panel bolted on, and you will be back to cloning within a month.
What you need underneath is boring and specific:
Get those four right and a second brand is an afternoon. Get them wrong and a second brand is a second codebase.
Say the theme holds up. The rest is short.
Start from a preset, not from scratch. Pick the one closest to the new brand and adjust from there. Building a brand by setting every field individually is how you end up with values that agree with nothing.
Change the tokens, not the modules. If you find yourself opening a module to make a brand look right, stop. That is the theme telling you a value is missing from settings, and the fix belongs there. Patch it in the module and you have just started a clone by another name.
Keep the structure, vary the composition. Two brands can share a header module and still look unrelated if one runs a wide hero with a photograph and the other opens on type. Layout variety does more for brand separation than colour does, and it costs nothing to maintain.
Give each brand its own demo page before you launch it. One page carrying every section type, built with that brand's settings. It takes an hour and it surfaces the thing you will otherwise find in week three.
Two honest limits, because the approach is not universal.
If your brands genuinely need different structures — one is a documentation site, one is an e-commerce catalogue — you are not looking at a theming problem. Shared tokens will not save you, and separate themes are the right answer.
And if the brands are owned by different teams with different release cycles, a shared theme means a shared blast radius. One team's change reaches everyone. That is usually a feature, but it needs someone to own the theme, and if nobody does, cloning is the less painful failure.
The approach fits the common case: several brands, one team, one look-and-feel language spoken with different accents.
Studio Nope Official is built on this model. Colour, type size, spacing, radius and shadow resolve from a field in theme settings through a CSS custom property, and a preset is a set of those values the theme ships with. Change a setting and it applies on top of whichever preset you have selected.
With one exception we argued about for a while. A handful of component colours are held back to the Custom preset: input text and its background, checkbox and radio fills, card surfaces, code and quote blocks. Those are colours whose correctness is a relationship rather than a value. An input's text colour means nothing on its own — it means something against the input's background, and a dark preset owns that background. Carry a saved light-grey text colour onto a dark preset and you get invisible text. So the preset keeps both halves of those pairs, and everything else follows your settings.
That trade is the one worth checking in any theme you are evaluating, ours included. Pick a preset, change a colour, and watch whether the page moves. Then ask what happens to the values the preset had to keep. It is a two minute test and it tells you most of what you need to know about what the next two years will cost.
When the second brand lands, the instinct is to ask which theme it should use.
The more useful question is what will happen the third time you fix a bug. If the answer involves opening more than one file, you already know which way this goes.
Related reading: how to pick a HubSpot theme without regretting it later, marketplace theme or custom theme, and the Studio Nope themes.