
Development
Three live sites for one national brand: what we learned
The architecture is the easy part.
When people hear three sites for one brand, they want to talk architecture. Multisite or separate installs? Shared theme or three? They reach for the technical question because it has a clean answer.
But when you run several sites off a shared foundation, you've created a dependency that doesn't respect your org chart. The marketing person who owns Site A and the product person who owns Site B both lean on the shared header, but neither owns it, and often neither knows the other exists.
Not what the org chart assumes is shared, and not what looks shared because nobody's questioned it yet. A logo and a color system are genuinely shared. A header usually is too. The hero component often isn't: one site's audience wants a tall video hero, another needs a compact form. Force both onto one component and you haven't created consistency, you've created a standing argument.
The moment you force two different audiences onto one component to look tidy, the tidiness costs you more than the duplication would have.
Shared where it must be, autonomous where it should.
A logo and a color system are genuinely shared, and a header usually is too. Those are the pieces nobody should fork. Consistency there is real consistency, not a rule forced onto teams that don't need it. The skill is telling the two apart before you build, not after the argument starts.
One team owns the tokens, the global chrome, the pieces nobody should fork. There's a single answer to who owns this, so nothing global is everyone's job and no one's.
Inside clear guardrails, every site team ships without waiting on the others. Autonomy where it should be, so a compact form and a video hero can coexist without a meeting. Drawing the line, shared here, autonomous there, is the actual work. Get it right and the org chart stops fighting the codebase.
It looks technical. It's almost entirely organizational.
The tech is just where the org chart shows up. That line has to live in permissions, not a doc — editors of Site A see Site A, and global components are editable by a small group who knows what global means.
How one edit becomes three teams' problem.
The Site A editor tweaks the footer. To her it's her site, one small edit, done before lunch. She has no idea it was shared. There was no permission stopping her, so the change went everywhere at once. On a single site, the person who broke something finds out, it's their site. Here she's looking at her own site, fine, while two other teams stare at what changed.
The whole job is closing that gap. Put the line in permissions, not a doc, so just our footer can only ever mean her footer. It's the same governance work behind Threshold and behind how we scope any multi-site build before the first component ships.