Expedia Group's filings describe moving its core retail brands onto one shared front-end technology stack from 2021, with the Hotels.com migration completed in 2022 and Vrbo following, and in July 2023 it launched One Key, a single loyalty programme spanning Brand Expedia, Hotels.com and Vrbo with more than 168 million combined members at launch. Three brands that compete for the same booking now share a platform. What forced that, what did it cost, and where would copying it be a mistake?

The situation they were in

Separate brands with separate front ends are doing the same work. Each one searches the same supply, prices it, takes a payment, services a change and handles a refund. The capability set is identical and only the presentation differs, so every supply feature, every payment method and every fraud rule was being built and operated more than once. Three stacks also mean three experiment surfaces, which is worse than it sounds: a result measured on one brand cannot be read across to another, so the organisation pays three times to learn the same thing.

What they chose

One shared platform underneath, brands above it. The filings describe the retail brands moving onto a common front-end stack and the transaction businesses drawing on shared infrastructure for servicing, search, payment processing and fraud.

The loyalty programme is the part that makes the consolidation unavoidable rather than merely efficient. A member who earns on one brand and spends on another requires one identity, one balance and one liability. You cannot assemble that from three independent ledgers with eventual reconciliation, because the balance is money: a double-spend across brands is a real loss, and the accrual has to be exactly-once against a transaction that may later be refunded.

Why it fit their constraints

Brand differentiation here lives in merchandising, inventory emphasis and audience, not in the mechanics of booking. When brands differ in presentation and agree on capability, shared platform plus brand configuration is the structure the business is already shaped like. The alternative, three teams independently building the same payment integration, loses the argument on cost and on consistency at the same time.

What it cost them

• Brand change rate becomes a queue. Three brands compete for one platform roadmap, and a brand that could once ship its own change now files a request. That is the dominant complaint in every consolidation of this kind.
• Blast radius triples. A platform incident is now a three-brand incident, so the availability target the shared stack must hold is strictly higher than any single brand needed.
• The loyalty ledger is permanent financial machinery. Points are a liability on the balance sheet. The architecture now owes idempotent accrual, reversal on refund, expiry, dispute handling and an audit trail, none of which existed when each brand ran its own rewards scheme.

When copying this is the wrong answer

When the brands differ in the capability rather than in the shop front. Different regulator, different supply contracts, different settlement currency, different recovery obligations: consolidating those produces one codebase with per-brand conditionals in the core, which is slower than two codebases and more fragile than either.

It is also wrong at small scale. A shared platform needs an owning team, a contract, a roadmap and a support model. For a company with two brands and thirty engineers, the platform team is more expensive than the duplication it removes, and the consolidation should wait until the third brand is real rather than planned.