The second quote
You did not go looking for a second website. It arrived with the acquisition, together with its own logo, its own tone of voice, a protective sales team, and a site built by someone else on something else. Your agency looked at the pair and quoted for a second build, because from the outside that is what two brands look like: two projects.
The instinct behind the quote is not wrong. The brands should stay distinct. The brand owner who rejected the subfolder was right, and so was the sales team that rejected the redirect. Where the quote goes wrong is in assuming that a distinct identity needs distinct infrastructure. It does not. The template site nobody maintains is what happens when you accept that assumption and then try to save money on it.
What is actually different between two brands
Put the two sites side by side and list what differs. Logo, colours, typefaces, photography. Tone of voice, and the words each brand uses for the same thing. The audience, and the sales process that audience expects. Sometimes the catalogue: one brand sells a subset, a different range, or the same range under different names.
Now list what is the same. A product has a name, a description, specifications, downloads and a contact route. A page has a headline, sections, calls to action and metadata. A news item has a date, an author and a body. The structure underneath the two sites is almost always the same, because both brands are doing the same job for the same kind of buyer.
Run this test on your own case before you sign anything. If the list of structural differences is short, a second build pays twice for one structure, and again every time that structure changes.
Brand as a dimension, not a project
The reason the second brand cannot fit inside your current site is rarely a technical limit. The content model was designed when there was only one brand, so brand was never written down as a thing. It is implied everywhere and declared nowhere.
The fix is to make brand a first class dimension of the content model. Every document that can differ between brands carries a brand field. Every query that fetches content filters on it. Content that is genuinely shared, such as a certification page or a corporate address, is marked as shared rather than copied. Navigation, footer, legal pages and design settings become per brand documents of the same type.
Once brand is a dimension, a third brand is closer to configuration than to a project. That is the change that makes everything else possible: one codebase, one content system, one set of components.
Routing in plain language
Domain routing gets filed as a hosting problem, so nobody designs it. A single deployment serves both domains: when a request arrives, the application reads the domain it came in on, decides which brand that is, and renders that brand's navigation, content and design tokens. The decision is made per request, inside the application, not by running two copies of everything.
We built this for a manufacturer serving a second brand from its own domain, with a commerce platform, a product information system and an ERP in the same landscape. The pattern held alongside all of them: one application, one content system, two brands.
For your IT lead: one release pipeline, one set of dependencies to patch, one security surface to watch. The second brand is configuration, not a second estate.
What editors see
The brand team's objection is usually not about technology. It is about control. They do not want to open a system and find the other brand's content mixed in with theirs, or their pages touched by someone who does not know the brand.
The content system scopes what each editor sees. An editor assigned to one brand sees that brand's documents, media and navigation, and nothing else. Brand specific design tokens mean the preview looks like their site, not a generic one.
In the engagement above, editors for each brand work in one system. Whether your brands run separate editorial teams or share one, the brand owner keeps a workspace that is visibly theirs, and the second backlog disappears with the second system.
When two builds is the right answer
One platform is not always the right call, and the cases where it is not are worth naming. If the brands sell in genuinely different ways, one through distributors at list prices, the other direct with configured quotes, a shared commerce model costs more than it saves. If they are separate legal entities with separate data obligations, customer data may not be allowed to share a system at all.
If a divestment is planned, one platform is still separable, but design the exit while you design the model. Brand as a field on every document, shared content marked as shared rather than copied: the line you would cut along is written down before due diligence asks where it is.
Your architect will point out that one system is a single point of failure. True. It is also the one system that actually gets patched, monitored and understood by the team running it, unlike the template site nobody maintains.
