Why every OpCo rollout restarts from zero

Because there is no shared product underneath. When a brewer runs a separate e-commerce build per operating company, a "rollout" is not configuration — it is a re-implementation. Each market re-does integration, catalog, pricing, tax, payment and returnables logic against its own ERP instance. That is why one top-three global brewer took roughly six years to reach about half of thirty digital markets, and why a new launch at 35% of the original build cost counted as a win.

What does "rollout" hide when there is no shared core?

The word is borrowed from software that ships once and deploys many times. A brewer's route-to-market estate rarely behaves that way. An operating company in one country runs its own tax regime, its own payment rails, a distinct product hierarchy, a local returnable-deposit scheme, its own promotion rules, and — more often than anyone admits — its own ERP instance. If the commerce platform does not expose those as configuration, meaning data rather than code, then adding a market means writing code again. The build looks reusable in the demo and stops being reusable at the first integration boundary.

This is why the market count matters more than the feature list. Promotion logic alone diverges enough that one promotion can face thirty different legal regimes; deposit and returnable-asset accounting diverges again; tax and invoicing diverge a third time. A platform that hard-codes any of these has quietly signed up to re-implement them in every OpCo that follows.

How slow is "restart from zero," in public numbers?

Slow enough to measure in years. One top-three global brewer's per-market commerce platform reached about half of thirty planned digital markets in roughly six years, and a new-market launch delivered at 35% of the original implementation cost was, correctly, treated as a success. A top-five global brewer's single B2B shop reached eleven markets in about four years. For scale, the same top-three brewer eventually consolidated more than forty separate country e-commerce shops under a single B2B brand in 2024 — a strong signal that forty parallel builds had become the problem, not the plan.

Why does 35% of the original cost count as a win?

Because the honest baseline is a full bespoke build, and one third of a bespoke build, repeated per market, is genuinely better than a whole one. But invert the number: 35% reused-nothing means roughly a third of every launch is new engineering, not configuration. The 65% that does carry over is the cheap part — the storefront shell, the design system, the deployment pipeline. The 35% that does not carry over is the expensive part: the integration to a local ERP, the pricing and tax engine, the returnables and promotion rules. In other words, the reusable portion is the UI, and the re-implemented portion is the business. That ratio is the whole diagnosis.

It also compounds. Each per-market fork acquires its own defects, its own release cadence and its own backlog. Two years on you are not maintaining one platform in fifteen markets; you are maintaining fifteen platforms that share a colour palette. The cost of change — a new payment method, a promotion mechanic that stops losing money, a loyalty rule — is now multiplied by the number of forks, because there is no single place to make it.

What does the fastest counter-example actually prove?

The obvious rebuttal is the world's largest brewer, whose in-house B2B platform reached thirteen markets within about two years and twenty-nine by 2025. That looks like configuration beating re-implementation. It is not. The same disclosures put 1,200-plus in-house developers behind the platform. Speed came from staffing a product, not from a lighter build: a central platform team owns one codebase, markets consume it, and there is enough engineering capacity to absorb the per-market divergence internally instead of forking. The lesson is not "hire twelve hundred engineers." It is that the fast case is organised as one product with tenants, and the slow cases are organised as many projects with a shared vendor.

So where does the time actually go?

Into four places, in roughly this order. First, data-model divergence: without a shared catalog, pricing and customer model, every market negotiates its own schema, and integration work scales with the number of schemas, not the number of markets. Second, ERP surface area: N operating companies frequently means N financial-system instances to integrate, each with its own master data and its own idea of an order. Third, governance: each OpCo owns its P&L and therefore wants its own features on its own timeline, which is exactly how a shared platform becomes a set of forks. Fourth, the missing spine — no common event bus means order, stock, delivery and loyalty are re-wired point-to-point in every market, and point-to-point integration is where the years disappear. Loyalty is a good example: without a shared ledger, every market rebuilds the accrual logic, and every market rediscovers that unredeemed points are a balance-sheet liability after the fact.

None of this is a tooling failure. The platforms in question are competent. The failure is architectural: treating a multi-tenant problem as a sequence of single-tenant deliveries.

What would make it configuration instead?

One short version of the fix: a single multi-tenant core where a market is a set of configuration — tax rules, price lists, catalog scopes, payment and returnable schemes — running on a shared event bus, with the client's SAP financial core left in place and integrated once rather than per market. Get the abstractions right and a new OpCo is data entry plus testing, not a project. That is the design we argue for in our platform architecture, and it is the difference between a rollout and a re-build.

The interesting shift over the next year or two is not another storefront generation; it is who owns the model underneath. Brewers that quietly consolidated forty shops into one brand have already conceded the point — the estate was the liability. The open question is whether the layer beneath the brand becomes a genuine multi-tenant product with markets as configuration, or whether the consolidation stops at the logo and the forty re-implementations simply move behind a shared front door. The brewers that treat the core as the product, and the market as a config file, will be adding countries while everyone else is still costing the next one at 35%.