We built a multi-tenant headless web app on Vue Storefront using a core + theme architecture, cutting new employer onboarding from weeks to days. We delivered the main implementation in 2022, then supported platform development through a maintenance phase in 2023–2024. Sodexo came away with a stable growth engine, empowered to independently continue the technical work of onboarding new tenants.

The Sodexo Ecosystem: Days Instead of Weeks, Predictable Scale

With the core + theme architecture, every bugfix and new feature in the core rolls out automatically to all tenants, with no extra per-employer work required.

Sodexo Benefits and Rewards Services — today Pluxee — is the number one player in the Polish employee benefits market.

For decades, the company has helped employers keep their teams motivated: its cards, vouchers, and benefits platforms are used in Poland by more than 2 million users and 50,000 companies. In 2023, the company was spun off from the Sodexo group and underwent a global rebrand to Pluxee — a brand building digital solutions for HR, marketing, and sales. As their technology partner, we were tasked with translating their business model into a working system: a multi-tenant loyalty and benefits platform in which every employer gets its own employee portal.

We built the platform in 2022, still under the Sodexo brand. A year later, independently of our project, the company was spun off from the Sodexo group and underwent a global rebrand — today it operates in the Polish market as Pluxee, a brand building digital solutions for HR, marketing, and sales.

The Business Challenge

Sodexo's employee portals are functionally similar to one another: an employee logs in, sees the available tasks — declarations, wellbeing programs, loyalty campaigns — browses the rewards catalog, and manages their points and funds. But beneath that similarity lies a different reality: every portal belongs to a different employer, with different access permissions, different CMS content, different icons, different layout.

In a traditional approach, every new employer means a separate frontend project: a new repository, its own configuration, its own deployment, and weeks of onboarding work.

Vue Storefront expects data in a specific format, while Sodexo's backend, built earlier around its own internal processes, delivered it its own way. For the frontend to work, a middle layer was needed: a custom REST API in Node.js translating the VSF contract into Sodexo's backend language. This wasn't a single task but a separate deliverable, priced and delivered on its own.

Technical Challenges

Behind Sodexo's simple portal interface stood a complex technical spec: dozens of tenants running on a single codebase, 10 modules outside the Vue Storefront standard, more than 40 REST API endpoints, and a rewards catalog requiring a search engine. Below are the five decisions and challenges that determined whether the platform could scale — or just launch.

Project kicked off right as Vue Storefront was in the middle of a version transition. VSF 1.12 with the Capybara theme was stable and proven, while VSF 2.4 was architecturally more modern but still maturing, with a new data structure that would need its own separate analysis for the duration of the project. We ran the numbers before pricing it out: moving to v2 meant an extra 100 to 200 hours of work, but it clearly cut down technical debt over a three-year horizon.

The central problem was scaling. We split the repository into two layers: a core repo holding the shared business logic (modules, API integrations, general translations), identical across every deployment, and a theme repo as a git submodule — the per-tenant layer (module extensions, branding, icons, additional translations, specific form fields). The result: adding a new client just means plugging a new theme submodule into the core, with no code duplication, and a bugfix in the core rolls out automatically to every tenant.

Vue Storefront ships with the standard stuff: cart, user, catalog, orders. Sodexo needed 10 modules that weren't part of it: Challenge (task zone), WallOfFame (recognition and rankings), ACL (per-tenant and per-role access), Points (points and conversion to funds), Declaration (declaration forms), Layout (dynamic page layout from the API), Consent (consent management), CMS (backend-driven URL pages), Contact (contact form), and Wall (content feed). Each one required designing the data structure, endpoints, and implementation both in the VSF API layer (Node.js) and on the frontend.

The rewards section is more than a simple product listing. It runs on ElasticSearch: multi-attribute filtering, full-text search, sorting, categories and brands as filters, and lazy loading. At this catalog scale, with rewards spanning different price categories and brands, an engine-based approach to search was a prerequisite for acceptable listing page performance.

Before a single line of production code was written, we delivered two documents: pre-implementation Vue documentation (a description of every view, the API data behind it, interactions, and any inconsistencies we'd spotted) and a list of VSF API endpoints (more than 40 REST interfaces, split into standard and custom modules, each with its HTTP method and contract description). This was a deliberate process choice: when integrating with an external backend, nailing down the API contract before implementation let us catch inconsistencies before they became more expensive to fix.

Solutions and Implementation

A multi-tenant PWA environment is a complex spec: individual icons per tenant, descriptions, different homepage layouts. Partway through the project, questions arose on Sodexo's side about the scope of this spec — some multi-tenant elements ultimately ended up being handled on the client's side. Sodexo extended the timeline to devote more attention, post-implementation, to manual and automated testing.

That's an honest look at what an integration project with a large organization actually looks like: the timeline can be sensitive to decisions made on the other side of the table, and the spec shifts as understanding of the problem grows. Our role isn't just writing code — it's holding the line on direction and technical quality no matter what those variables do.

Key Takeways