Most parent retail groups run two to six grocery brands. Most catering platforms quietly assume you only run one. Here is what that mismatch costs — and what real multi-tenancy looks like.
Walk through the brand portfolios of the largest European grocery groups and a pattern jumps out. Schwarz Group runs Lidl and Kaufland. REWE Group runs REWE, Penny, Billa, and several regional banners. Coop Italia runs three consumer-facing fascias. Ahold Delhaize runs Albert Heijn, Delhaize, Mega Image, Profi, and a long tail of country-specific names. Carrefour runs hyper, super, market, and express formats with deliberately different brands and price architectures.
The reason the portfolio looks like this is straightforward. Different shopper missions need different stores. A discount banner and a premium banner share buying power and back-office, but the customer experience must not share. If a customer notices that the discounter and the premium chain are run from the same office, the premium price stops working.
Now overlay catering on that picture. Every brand wants its own domain (lidl.de/catering, not group-platform.de/lidl). Its own visual identity. Its own assortment. Its own pricing rules. Its own customer accounts. Often its own data residency, depending on which country the brand operates in.
What every parent group also wants is one team running it. One platform contract. One rule engine. One set of integrations to ERP, identity, and payments. One operational dashboard.
Those two requirements — brand-isolated experience and group-shared operation — are exactly what a real multi-tenant architecture is for. Most catering platforms do not have one.
The naive answer is to run one installation per brand. Six brands? Buy six contracts, deploy six instances, configure six admin teams, train six sets of users, integrate six times, upgrade six times. Each brand gets its own domain, its own design, its own assortment, because each is literally a separate system.
This works. It is also expensive in ways that compound over years rather than showing up in the first invoice.
Most chain steering committees discover the cost only after they have lived with the model for two budget cycles. By then the license fees, the staffing, and the integration layer have all settled into the run-rate, and re-architecting feels like opening up a wound to fix a scar. Many groups simply absorb it.
The line items that turn one-install-per-brand into a quiet drag on the catering P&L:
None of these line items kill a programme. Together they make catering feel three times harder than it should be, and the steering committee starts to wonder whether catering is even a real opportunity. It is. The architecture is the problem, not the category.
The architecture that solves this is not a configuration setting. It is a set of decisions taken at the level of the data model, the routing layer, and the admin tooling. A platform either has them or it does not.
Separate domains per brand. Brand A runs on brandA.com/catering, brand B runs on brandB.com/catering. Same install, same database, different domains terminating at the same edge. The customer never knows the brands share a platform. DNS, SSL, cookies, and brand-specific OG/SEO metadata all flow through the per-brand surface.
Separate design tokens per brand. Logo, colours, typography, component variants — all per-brand, applied at runtime by tenant context. Not a theme switcher; a ground-up brand surface that sales and marketing can iterate on without touching the platform.
Separate assortments and pricing. Each brand has its own product catalogue, its own price book, its own modifier rules, its own capacity and lead-time rules. Some products may be shared (a group-wide centerpiece sold under both banners), but sharing is the exception, controlled by the operator, not the default forced by the platform.
Separate customer bases. A user account at brand A is not a user account at brand B. Login, session, history, preferences, marketing consent — all isolated. If the group later wants to offer cross-brand identity (one login, opt-in, federated history) that is a feature built on top of the isolation, not a workaround for its absence.
Separate data residency, optionally. For groups operating across jurisdictions, the platform should be able to host brand A's data in one region and brand B's in another. This becomes meaningful for German-Swiss-Austrian setups, UK-EU splits post-Brexit, and any future post-GDPR regional divergence.
One operational layer above the brands. Group head office gets one console: cross-brand reporting, shared integration management, shared user-administration roles where useful, group-wide audit trails. The operator runs the platform once; the brands consume the surface independently.
The reason this architecture is rare is that it is hard to add after the fact. A platform whose initial schema reads tenant_id on every row, where tenant means “the chain”, can do per-store and per-region differently. It cannot, without a multi-quarter rebuild, do per-branddifferently — because per-brand requires the data model to treat brand as a first-class entity that owns customers, orders, prices, products, and rules.
Concretely: a customer record needs a brand foreign key, not a chain foreign key. An order does too. A product catalogue does too. A price book does too. Authentication has to read the brand context from the request domain and scope the session to that brand. The admin tool has to render different UIs depending on whether you are viewing a brand or the group above it. None of this is impossible to bolt on. All of it is invasive enough that vendors who didn't build it on day one quietly steer customers toward the one-install-per-brand model instead.
The result is a market in which most catering platforms can claim “multi-store” truthfully and “multi-brand” only with footnotes. The footnotes usually translate to: separate installs, separate licenses, separate ops.
DeliChain runs three retail brands inside one parent group on a single installation. Each brand has its own domain, its own design language, its own product assortment, its own price book, its own customer base. The brands do not share carts, accounts, or order history. The group ops team works from one admin console with a brand-switcher and group-wide reports.
The point of the reference is not that we are unique. It is that we built brand as a first-class entity from the first commit, which is the only way to get this architecture without ripping the platform open later. Any group evaluating a catering platform should ask the vendor exactly two questions:
If the answer to (1) is no and the answer to (2) is vague, the platform is a single-brand platform with a multi-brand sales pitch. That is fine for chains that will only ever run one fascia. For parent groups that already run several — or that are considering a second fascia in the next five years — it is a decision being deferred until it gets expensive.
The catering opportunity in European grocery is real. The architecture you choose to capture it is the part most steering committees underestimate. This is the one to get right.
This article draws on the architecture of the DeliChain platform and direct operational experience running three retail brands across 100+ stores from a single installation. Brand portfolio examples are public; we are not affiliated with the named groups.
We will walk you through the live three-brand setup — same install, separate domains and customer bases — and discuss what a portfolio rollout would look like for your group.
Book a Demo