Multiple Brands, One Backend

Brand comes from the host, never from the browser

The correctness question in a multi-brand system is: where does the brand come from? If it is anything the browser can send — a form field, a query parameter, a stored preference — then an order can be recorded against the wrong brand, and it will eventually happen.

We resolve it from the request hostname and pass it to the order routine directly. The client is never asked which brand it is on, so it cannot answer incorrectly. Order numbering derives from the same source, which means the order number itself is evidence of which brand took the sale.

Preview and staging hosts are the one place an override is allowed, and real domains ignore it entirely. That keeps testing convenient without opening a path that matters in production.

Same name does not mean same product

This is the trap that catches teams migrating two brands onto one platform: the instinct to deduplicate. Two brands sell something with the same name, so surely it is one product with two prices.

Usually it is not. Blends in particular differ in composition between brands even when the name matches, and reconciling them destroys real information. We treat them as separate products that happen to share a name, and we only record composition where a source actually spells it out rather than inferring it.

The discipline is the same one that governs certificates: where two things merely look alike, keep them apart and let the data say so.

What you actually save

One codebase, one database, one deployment pipeline, one set of infrastructure bills. A fix or feature ships to every brand at once instead of being ported by hand and drifting.

The operational saving is larger than the hosting saving. Your team learns one admin, works one fulfillment queue, and reads one set of reports with a brand filter. Adding a third brand becomes a configuration exercise rather than a project.