Onboarding nowego systemu lojalnościowego z tygodni do dni
Multi-tenant platforma benefitowa Pluxee na Vue Storefront. Zobacz, jak architektura core + theme przyspieszyła wdrażanie nowych pracodawców.
Odwiedź stronę Pluxee
O projekcie
Sodexo Benefits and Rewards Services Polska to jeden z liderów rynku benefitów pracowniczych w Polsce. Ich model biznesowy opiera się na prostej zasadzie: każda firma korzystająca z ich platformy dostaje własny portal dla pracowników, z logo pracodawcy, dedykowanymi zestawami nagród i zadań, swoim układem strony, nierzadko własnym brandingiem kolorystycznym.
Problem pojawia się przy skali. Dziesiątki klientów korporacyjnych, każdy z własnym portalem, a każde nowe wdrożenie to potencjalnie tygodnie pracy frontendowej. Sodexo potrzebowało architektury, która odwróci tę zależność, tak aby koszt obsługi kolejnego pracodawcy nie rósł liniowo z liczbą pracodawców.
Zbudowaliśmy multi-tenant headless web app na Vue Storefront w core + theme, dzięki której onboarding nowego pracodawcy skrócił się z tygodni do dni. Główne wdrożenie zrealizowaliśmy w 2022 roku, a w latach 2023–2024 wspieraliśmy rozwój platformy w fazie utrzymaniowej. Sodexo otrzymało stabilny silnik wzrostu pozwalający na samodzielną kontynuację prac technicznych związanych z onboardingiem nowych tenantów.
Ekosystem Sodexo: dni zamiast tygodni, przewidywalna skala
przy architekturze core + theme każdy bugfix i nowa funkcja w core trafiają automatycznie do wszystkich tenantów, bez dodatkowej pracy per pracodawca.
8 msc
całkowity czas wdrożenia nowej platformy: dokumentacja, implementacja, testowanie.
40+
endpointów REST API, zintegrowanych, udokumentowanych i przetestowanych osobno dla środowiska multi-tenant.
6+
modułów custom zbudowanych od zera poza standardem Vue Storefront, m.in. Challenge, Points, ACL, Declaration.
1 → N
jedno core repo obsługuje wszystkich tenantów. Nowy pracodawca to submoduł motywu, nie nowy projekt.
Skalowanie kosztuje Cię coraz więcej?
Umów rozmowę i sprawdź, czy podejście multi-tenant sprawdzi się w Twoim modelu.
Sodexo Benefits and Rewards Services – dziś Pluxee – to numer 1 na polskim rynku benefitów pracowniczych.
Firma od dekad wspiera pracodawców w motywowaniu zespołów: z jej kart, kuponów i platform benefitowych korzysta w Polsce ponad 2 miliony użytkowników i 50 tysięcy firm. W 2023 roku spółka została wydzielona z grupy Sodexo i przeszła globalny rebranding na Pluxee – markę rozwijającą cyfrowe rozwiązania dla HR, marketingu i sprzedaży. Jako partner technologiczny otrzymaliśmy zadanie przełożenia ich modelu biznesowego na działający system: multi-tenant platformę lojalnościowo-benefitową, w której każdy pracodawca otrzymuje własny portal dla pracowników.
Platformę budowaliśmy w 2022 roku, jeszcze pod marką Sodexo. Rok później, niezależnie od naszego projektu, spółka została wydzielona z grupy Sodexo i przeszła globalny rebranding, dziś działa na polskim rynku jako Pluxee, marka rozwijająca cyfrowe rozwiązania dla HR, marketingu i sprzedaży.
Dopasowujemy technologię do biznesu. Nigdy na odwrót.
"Specjaliści z Beecommerce od pierwszego dnia prezentowali najwyższy standard pracy, koncentrując się na precyzyjnym dopracowaniu każdego elementu platformy, co było kluczowe przy migracji naszego serwisu!"
Wyzwanie biznesowe
Portale pracownicze Sodexo są funkcjonalnie podobne do siebie: pracownik loguje się, widzi dostępne zadania: deklaracje, programy wellbeing, akcje lojalnościowe, przegląda katalog nagród, zarządza swoimi punktami i środkami. Ale pod tą podobnością kryje się inna rzeczywistość: każdy portal to inny pracodawca, inne uprawnienia dostępu, inne treści CMS, inne ikony, inny layout.
Skalowanie bez mnożenia pracy frontendowej
W tradycyjnym podejściu każdy nowy pracodawca to osobny projekt frontendowy: nowe repozytorium, osobna konfiguracja, osobny deployment, tygodnie pracy przy onboardingu.
Integracja dwóch różnych kontraktów API
Vue Storefront oczekuje danych w określonym formacie, a backend Sodexo, zbudowany wcześniej pod ich własne procesy, dostarczał je po swojemu. Aby frontend mógł komunikować się z backendem Sodexo, w Vue Storefront została zaimplementowana warstwa pośrednia (proxy), odpowiedzialna za mapowanie danych pomiędzy VSF a API backendu. To nie był pojedynczy task, lecz osobny deliverable, wyceniany i dostarczany oddzielnie.
Wyzwania techniczne
Za prostym interfejsem portali Sodexo stała złożona specyfikacja techniczna: dziesiątki tenantów na jednym kodzie, 6+ modułów spoza standardu Vue Storefront, ponad 40 endpointów REST API i katalog nagród wymagający silnika wyszukiwania. Poniżej pięć decyzji i wyzwań, które zdecydowały o tym, czy platforma da się skalować, czy tylko uruchomić.
Wybór wersji: VSF 1.12 czy 2.4
Projekt startował, gdy Vue Storefront przechodził między wersjami. VSF 1.12 z motywem Capybara był stabilny i sprawdzony, VSF 2.4 nowocześniejszy architektonicznie, ale wciąż dojrzewający, z nową strukturą danych wymagającą na czas projektu osobnej analizy. Policzyliśmy to przed wyceną: przejście na v2 oznaczało dodatkowe 100 do 200 godzin pracy lecz wyraźnie zmniejszało dług technologiczny w perspektywie trzech lat.
Architektura multi-tenant: core repo + theme submodule
Centralnym problemem było skalowanie. Podzieliliśmy repozytorium na dwie warstwy: core ze wspólną logiką biznesową (moduły, integracje API, ogólne tłumaczenia), identyczną w każdym wdrożeniu, oraz theme jako git submodule, czyli warstwę per tenant (rozszerzenia modułów, branding, ikony, dodatkowe tłumaczenia, specyficzne pola formularzy). Efekt: dodanie nowego klienta to nowy submoduł motywu podpięty pod core, bez duplikowania kodu, a bugfix w core trafia automatycznie do wszystkich tenantów.
6+ modułów zbudowanych od zera
Vue Storefront dostarcza standard: koszyk, użytkownik, katalog, zamówienia. Sodexo potrzebowało 6+ modułów, których w nim nie ma: Challenge (strefa zadań), WallOfFame (wyróżnienia i rankingi), ACL (dostęp per tenant i per rola), Points (punkty i konwersja na środki), Declaration (formularze deklaracji), i Wall (treści). Każdy wymagał zaprojektowania struktury danych, endpointów i implementacji zarówno w warstwie VSF API (Node.js), jak i na froncie.
Katalog nagród na ElasticSearch
Sekcja nagród to więcej niż prosty listing produktów. Działa na ElasticSearch: filtrowanie wieloatrybutowe, wyszukiwarka full-text, sortowanie, kategorie i marki jako filtry oraz lazy load. Przy tej skali katalogu, z nagrodami z różnych kategorii cenowych i marek, silnikowe podejście do wyszukiwania było warunkiem akceptowalnej wydajności listing page.
Dokumentacja przed kodem
Zanim powstała pierwsza linijka produkcyjnego kodu, dostarczyliśmy dwa dokumenty: dokumentację przedwdrożeniową VUE (opis każdego widoku, danych z API, interakcji i wykrytych nieścisłości) oraz listę endpointów VSF API (ponad 40 interfejsów REST, z podziałem na moduły standardowe i custom, każdy z metodą HTTP i opisem kontraktu). To był świadomy wybór procesowy: przy integracji z zewnętrznym backendem uzgodnienie kontraktu API przed implementacją pozwoliło wyłapać nieścisłości, zanim stały się droższe do naprawienia.
Co wydarzyło się po drodze
Środowisko multi-tenant z PWA to złożona specyfikacja: indywidualne ikony per tenant, opisy, różne layouty strony głównej. W trakcie projektu po stronie Sodexo pojawiły się wątpliwości dotyczące zakresu tej specyfikacji — część elementów multi-tenant ostatecznie została zrealizowana po stronie klienta. Sodexo wydłużyło harmonogram aby wiele uwagi po implementacji poświęcić manualnemu i automatycznemu testowaniu.
To uczciwy przykład tego, jak wygląda projekt integracyjny z dużą organizacją: harmonogram bywa podatny na decyzje po drugiej stronie stołu, specyfikacja zmienia się razem z rosnącym rozumieniem problemu. Nasza rola to nie tylko pisanie kodu, ale utrzymanie kierunku i jakości technicznej niezależnie od tych zmiennych.
Efekt biznesowy i techniczny
Sodexo otrzymało platformę z architekturą, która realnie obsługuje ich model biznesowy. Nowy klient korporacyjny nie wymaga nowego projektu frontendowego — wymaga nowego rozszerzenia obecnego projektu jako sub-moduł. Różnica między tygodniami a dniami w onboardingu partnera to nie slogan, to konsekwencja konkretnej decyzji architektonicznej podjętej na początku projektu.
Z naszej strony: projekt potwierdził, że potrafimy pracować z klientem enterprise w trybie dokumentacja-przed-kodem, zarządzać niejasnościami po stronie backendu na który nie mamy wpływu, i budować architekturę zaprojektowaną pod skalowanie, a nie tylko pod działanie.
Nasi eksperci
Buduje sklepy internetowe na dedykowanych frontach lub na zdefiniowanych frameworkach, m.in Alokai, Medusa i Hydrogen. Jeden z niewielu w Polsce ekspertów Storyblok CMS.
Senior Full Stack Developer z 20-letnim doświadczeniem. Ekspert w PHP, Java i Python. Łączy hardware z software’em.
Twój e-commerce hamuje wzrost?
Sprawdź, jak nasze rozwiązanią klasy Enterprise eliminują dług technologiczny i odblokowują konwersję!
Wykorzystywane technologie
Nasi specjaliści używają sprawdzonych narzędzi, aby Twój produkt działał bezbłędnie i spełniał oczekiwania użytkowników.
Technologie dobieramy indywidualnie do projektu, dbając o wydajność, bezpieczeństwo, SEO oraz UX.
Pracując na Twoich obecnych systemach, aktualizujemy je i optymalizujemy kod. Stale się rozwijamy, by dostarczać rozwiązania najwyższej światowej jakości.
Vue Storefront 2
Vue.js
Node.js
ElasticSearch
PWA
Rest API
Git submodules
Kluczowe wnioski
01
Multi-tenant to decyzja architektoniczna, nie feature. Zrób ją na początku — retrospektywne refaktorowanie pod multi-tenancy jest wielokrotnie droższe niż zaprojektowanie od razu.
02
Warstwa API jako oddzielny deliverable. Gdy pracujesz z zewnętrznym backendem, który nie mówi językiem twojego frameworka, middleware nie jest "integracją" — jest produktem. Wymaga osobnej wyceny, dokumentacji i odbioru.
03
Dokumentacja przed kodem ma cenę i wartość. Kilkanaście godzin analizy na starcie zapisuje się jako koszt. Tygodnie refaktorowania z powodu niezgodności kontraktu API nie mają etykietki — ale też mają swoją cenę.
04
ElasticSearch dla katalogów z setkami produktów i wieloma atrybutami to nie nadmiarowość — to warunek konieczny akceptowalnej wydajności.
05
Projekty enterprise mają swoją dynamikę. Harmonogram może się zmienić z powodów leżących po stronie klienta. Wartość partnera technologicznego mierzy się tym, jak utrzymuje jakość techniczną w tych warunkach.
Podsumowanie
Wdrożenie platformy benefitowej dla Sodexo Benefits and Rewards Polska pokazuje, jak jedna decyzja architektoniczna przekłada się na model biznesowy. Multi-tenant headless web app na Vue Storefront, oparta na podziale core repo plus theme submodule, sprawia, że obsługa kolejnego pracodawcy nie jest już liniową funkcją liczby pracodawców.
Sodexo dysponuje dziś platformą, która realnie obsługuje ich model: każdy nowy klient korporacyjny to nowy motyw podpięty pod wspólny core, a nie osobny projekt frontendowy, więc onboarding skraca się z tygodni do dni. Dla Sodexo skalowalność przestaje być kosztem, a staje się przewagą: im więcej pracodawców, tym wyraźniej widać wartość architektury zaprojektowanej pod wzrost, nie tylko pod działanie.
Zaufali nam
Dlaczego Beecommerce?
Synergia Biznes-IT
Działamy jako strategiczny most. Łączymy świat KPI z dyscypliną inżynierską. Tandem Business Lead + Tech Lead zapewnia, że technologia realizuje cele biznesowo-strategiczne.
Architektura klasy Enterprise
Budujemy skalowalne ekosystemy Headless odporne na piki sprzedażowe. Zapewniamy pełną synergię z ERP, PIM i CRM, trwale eliminując barierę długu technologicznego.
Ciągłość i Bezpieczeństwo
Rozumiemy koszt minuty przestoju w Enterprise. Dostarczamy systemy Fail-Safe z twardym SLA. Dbamy o Compliance i stabilność procesów transakcyjnych.
Beecommerce Hypercare
Projektujemy systemy raportujące marżę, retencję i realny zysk, a nie tylko ruch w serwisie. Dostarczamy twarde dane decyzyjne, zamieniając technologię w przewidywalny silnik wzrostu.
