Spryker dla B2B - kiedy ma sens, ile kosztuje

Czym naprawdę jest Spryker

Spryker nie jest sklepem internetowym jak Magento czy Shopware. To framework commerce'owy - zbiór ponad 300 modułów, z których składasz własną platformę. To brzmi marketingowo, ale ma realne konsekwencje, których nie widać w pierwszym demo.

Modularność jest realna. Spryker daje moduły do katalogu, koszyka, zamówień, klientów, cenników, kont B2B, quote'ów i tak dalej. Wybierasz, których chcesz, łączysz je w aplikację, dostosowujesz pod swoje. Nie ma "rdzenia sklepu" do customizacji - bo nie ma sklepu, jest fundament, na którym sklep dopiero powstaje. To filozofia inna niż Magento, gdzie po instalacji masz działający sklep, który tylko przepisujesz.

Headless od pierwszego dnia. Frontend nie jest częścią Sprykera. Spryker wystawia API (Glue API, więcej niżej), a frontend napiszesz w Next.js, Nuxt, Astro - cokolwiek. Producent oferuje referencyjny "Spryker Storefront" w Next.js, którego można użyć jako bazy. To plus dla zespołów, które wiedzą, że potrzebują różnych frontendów dla różnych kanałów (web, aplikacja mobilna, kiosk). Minus dla zespołów, które nie mają frontend developerów i myślały, że "sklep przyjdzie z producentem".

Symfony pod spodem, ale to nie znaczy, że Symfony developer napisze w Sprykerze od ręki. Architektura BAPI/Yves/Zed jest własna. Pierwsze tygodnie programista zwykle uczy się "jak Spryker chce to robić" i często nie zgadza się z tym, co Symfony i Laravel zrobiłyby prościej. To inwestycja w naukę, która zwraca się dopiero po pół roku.

Multi-store, multi-region, multi-tenant są w core, nie w pluginie. Grupy zakupowe, holdingi, międzynarodowe firmy potrzebują tego standardowo i Spryker im to daje bez instalowania dodatków. To realna wartość dla konkretnego profilu klienta - i pułapka dla wszystkich pozostałych, którzy płacą za funkcje, których nie używają.

B2B w DNA. PunchOut, cenniki kontraktowe, quote management, company accounts z rolami i akceptacjami zamówień - są częścią core. W Magento to są moduły, których trzeba szukać, kupować i utrzymywać osobno. W Sprykerze to działa od pierwszego deploymentu.

Czym Spryker nie jest. Nie jest sklepem out-of-the-box - bez 6-9 miesięcy wdrożenia nie masz nic, co można pokazać klientowi. Nie jest tańszy niż Adobe Commerce - licencja bywa w tym samym przedziale, a często wyższa. Nie jest dla małych firm - ROI poniżej pewnej skali GMV po prostu nie istnieje, niezależnie od entuzjazmu zespołu.

Platformy e-commerce B2B 2026 - szerszy kontekst rynku platform.

Modularność vs konkurencja

Najlepiej pokazać różnicę na konkretnym przykładzie - Quick Order, czyli funkcja, której potrzebuje większość sklepów B2B (kupujący wkleja listę SKU z ilościami i jednym kliknięciem ma to w koszyku).

W Magento instalujesz moduł Quick Order (jest w core w wersji Adobe Commerce, w Open Source dorabiasz dedykowanym modułem od Mageworx albo własnym), modyfikujesz template do swojego brandu, działa. W Shopware jest plugin Quick Order z konfiguracją, instalujesz przez Composer, klikasz w admin i masz. W Sprykerze składasz funkcję z modułów Cart, Product, CSV Import, łączysz z własnym frontendem - dokładnie taki Quick Order, jakiego potrzebujesz, ze swoją walidacją SKU, swoim trybem podziału zamówienia per magazyn, swoim handlingiem nieznanych pozycji.

Brzmi to świetnie w teorii. W praktyce modularność Sprykera realnie istnieje, ale wymaga developera, który rozumie filozofię i konwencje platformy. Nie da się "kliknąć w admin" jak w Shopware - bo nie ma w admin tego, co kliknąć. Z drugiej strony, kiedy potrzebujesz Quick Order'a, który dzieli SKU per magazyn z wybraną logiką priorytetów dostawy, Magento z zewnętrznym modułem nie zrobi tego bez przepisywania połowy modułu. Spryker zrobi, bo to po prostu kolejna kompozycja modułów.

Dla 80% sklepów B2B, które po prostu chcą Quick Order z palcem cykającym po koszyku, modularność Sprykera jest dramatycznie nieadekwatna. Dla 20%, które mają nietypowe wymagania B2B i budżet na zespół, który to obsłuży - to ratuje życie.

Cennik i licencje - rzeczywisty TCO

Spryker nie publikuje cennika, każda wycena jest negocjowana per klient. Ale z rozmów z partnerami i obserwacji rynku w Polsce wynikają realne przedziały. Pierwszy model to Spryker Cloud Commerce OS - subskrypcja roczna, skalowana z GMV sklepu. Im więcej sprzedajesz, tym wyższa licencja. Dla średniego klienta z polskim ruchem to 100-500 tys. EUR rocznie. W cenie infrastruktura zarządzana przez Spryker na AWS, SLA, support. Drugi model to Spryker On-Premise - jednorazowa licencja plus roczny support, własna infrastruktura, własne utrzymanie. Niższy koszt roczny, ale wyższy nakład pracy IT i pełne ryzyko produkcyjne po twojej stronie.

Realny TCO trzyletni dla średniego sklepu B2B z 50 tys. SKU wygląda mniej więcej tak (przedziały, bo każde wdrożenie jest inne):

Pozycja	Kwota
Licencja Spryker Cloud (3 lata)	600 tys. - 1.5M EUR
Wdrożenie (zespół 5-8 osób przez 6-12 miesięcy)	800 tys. - 2M EUR
Utrzymanie wewnętrzne (3-4 osoby przez 3 lata)	1M - 1.5M EUR
Frontend (custom, np. Next.js)	200 tys. - 500 tys. EUR
Łącznie	2.6 - 5.5M EUR

Dla porównania ten sam sklep na innych platformach:

Platforma	TCO 3 lata
Magento Open Source	800 tys. - 1.5M EUR
Adobe Commerce	1.5 - 3M EUR
Spryker Cloud	2.6 - 5.5M EUR

Premia za Sprykera wynosi 2-4 razy względem Magento Open Source. Żeby to się zwracało, musisz mieć konkretną wartość ze Sprykera, której Magento ci nie da - typowo wielokrotny region z różnymi walutami i VAT-em, zaawansowany quote management z aprobatami, multi-tenant dla grupy zakupowej. Bez tego płacisz premię za funkcje, których nie używasz, i bardzo szybko ekonomicznie wracasz do Adobe Commerce albo Shopware.

Headless first - co to znaczy w praktyce

Spryker eksponuje dwa rodzaje API i to rozróżnienie ma znaczenie architektoniczne. Glue API to publiczne REST API dla frontendu - storefront (produkty, kategorie, koszyk, checkout) i B2B (company accounts, kontrakty, quote'y). Format jest wzorowany na JSON:API spec, więc dowolny frontend developer się tam odnajdzie. Zed API to wewnętrzne API RPC dla integracji - ERP, OMS, PIM. Dostępne tylko z sieci wewnętrznej, nie wystawione publicznie.

Frontend budujesz albo z gotowego Spryker Storefront (referencyjna implementacja w Next.js, możesz wziąć jako bazę i przerabiać), albo od zera w technologii, którą lubisz. Mobile aplikacja, kiosk w magazynie, integracja z marketplace - wszystko przez to samo Glue API. Backend nie wie, że obsługuje pięć różnych frontendów, dla niego to są HTTP requesty.

Plusy są realne. Pełna kontrola nad frontendem znaczy, że performance, UX i brand są twoje, nie wymuszone przez producenta. Multi-channel jest tani - jeden backend, wiele kanałów. Aktualizacje Sprykera nie kolidują z deployami frontendu, bo żyją w innych repo i mają osobne pipeline'y.

Minusy są równie realne. Frontend to osobny duży projekt - 200-500 tys. EUR dla custom Next.js z pełnym B2B UX. Potrzebujesz zespołu frontendowego i backendowego razem, nie jednego "full-stack Magento developera". Time-to-market jest dłuższy niż dla klasycznego sklepu z gotowym frontendem - dla niecierpliwego prezesa to czasem deal breaker.

Headless commerce dla B2B - szersze ujęcie tematu.

Polski rynek - partnerzy, talenty, ryzyko

To jest moim zdaniem najczęściej pomijana zmienna przy wyborze Sprykera w Polsce, a powinna być na początku listy. Spryker w polskim ekosystemie ma realnie kilku partnerów z certyfikacjami, ich stawki to 150-250 EUR za godzinę (porównywalnie ze specjalistami Adobe Commerce), a czas oczekiwania na start projektu sięga 3-6 miesięcy w szczycie - bo zespołów certyfikowanych jest mało i są zajęte.

Developerów Sprykera w całej Polsce można policzyć w dziesiątkach, nie setkach. Stawki dla seniora to 25-40 tys. zł brutto miesięcznie - więcej niż w Magento, bo rzadkość kosztuje. Rynek pracy jest płytki, co znaczy, że jeśli senior z twojego zespołu zmieni firmę, znalezienie zastępcy zajmie 3-6 miesięcy i prawdopodobnie kosztownie podbije stawki w całym zespole.

Ryzyko długoterminowe siedzi w dwóch miejscach. Co, jeśli partner przestanie wspierać Spryker (rotacja działów Spryker w niektórych software house'ach jest faktem)? Mała baza ekspertyzy w kraju oznacza, że zmiana partnera jest droga i ryzykowna. Co, jeśli kluczowy developer odejdzie? Trudniej zrekrutować zastępcę niż w Magento, gdzie programistów są tysiące.

Łagodzenie tego ryzyka wymaga świadomych decyzji. Buduj wewnętrzny zespół, nie polegaj wyłącznie na outsourcingu. Dokumentuj decyzje architektoniczne porządnie - to nie jest opcjonalne, bo bez tego nowa osoba w zespole będzie się uczyła kodu 4 miesiące. Inwestuj w Spryker Academy i wewnętrzne treningi, traktuj to jako CapEx, nie OpEx.

Kiedy odpuścić Spryker

Lubię tę sekcję bardziej niż "kiedy wybrać", bo decyzja, której wdrożenia nie zaczynać, oszczędza więcej pieniędzy niż decyzja, które wdrażać.

Odpuść Sprykera, jeśli twój roczny GMV jest poniżej 10 mln EUR. Poniżej tej skali ROI z funkcji Sprykera (multi-region, zaawansowane B2B) jest mniejszy niż premia, którą za nie płacisz. Odpuść, jeśli masz mały zespół IT (1-3 osoby) - Sprykera nie utrzymasz w takim składzie. Odpuść, jeśli nie masz budżetu rzędu miliona EUR plus na trzy lata. Odpuść, jeśli twoje time-to-market jest krótsze niż 6 miesięcy - Spryker nie odpali w cztery miesiące. Odpuść, jeśli wystarczą ci cenniki per grupa i role użytkowników, bo to ogarnie Magento i Shopware za ułamek ceny. Odpuść, jeśli nie masz zespołu frontendowego ani planów, żeby go zatrudnić.

Spryker ma sens dla ciebie, jeśli mówisz "tak" na większość z poniższych. Duża skala, GMV powyżej 50 mln EUR. Multi-region, multi-brand, multi-channel jako realne wymaganie, nie aspiracja. Zaawansowane B2B (PunchOut, quote management, approval flows wielopoziomowe) jako część modelu biznesowego, nie nice-to-have. Dojrzały zespół IT z własną kulturą DevOps. Headless jako świadoma strategia, której skutki ekonomiczne rozumiesz, a nie hype z konferencji.

W praktyce polski rynek ma kilkadziesiąt realnie sensownych wdrożeń Sprykera, najczęściej w polskich oddziałach globalnych marek (gdzie wybór był podjęty globalnie). Dla rodzimego średniego B2B Spryker bardzo rzadko jest najlepszym wyborem - choć dyskusja jest modna.

Magento vs Shopware dla B2B - typowy realny wybór dla średniego B2B w Polsce.

FAQ

Czy Spryker jest dla średniej hurtowni? Najczęściej nie. Średnia hurtownia z GMV 5-30 mln EUR jest lepiej obsłużona przez Shopware albo Magento. Spryker zaczyna się opłacać przy zaawansowanych wymaganiach B2B i większej skali. Jeśli twoja lista wymagań to "cenniki per grupa, multi-magazyn, integracja z Comarchem" - Magento to zrobi za ułamek ceny.

Ile kosztuje wdrożenie Spryker w PL? Realistycznie 1-3 mln EUR dla pełnego wdrożenia z infrastrukturą i custom headless frontendem. Ten sam sklep na Magento z porównywalną skalą funkcjonalności - 300 tys. do 1 mln EUR. Trzykrotna premia za Sprykera musi mieć biznesowy sens.

Czy znajdę developerów Spryker w PL? Tak, ale rynek jest płytki - kilkudziesięciu doświadczonych developerów w całej Polsce. Stawki wyższe niż dla Magento z uwagi na rzadkość. Rotacja w zespole projektowym jest realnym ryzykiem - planuj redundancję kompetencji wewnątrz zespołu, nie polegaj na jednej osobie.

Czy Spryker zastąpi Adobe Commerce? Nie - to platformy dla różnych profili klientów. Adobe Commerce ma silniejszy ekosystem modułów i niższy próg wejścia. Spryker ma elastyczniejszą architekturę modułową i B2B w core, ale wymaga większego budżetu i dojrzalszej organizacji. Wybór zależy nie tyle od funkcji, ile od dojrzałości IT i finansów.

Czy Spryker Cloud Commerce daje lepszą wydajność niż self-hosted? Tak, w większości przypadków. Spryker Cloud korzysta z AWS z auto-scalingiem, natywnym cache'owaniem i CDN dograniem do platformy. Self-hosted wymaga, żebyś sam to wszystko zbudował - i typowo z gorszym rezultatem niż zespół Sprykera, który robi to dla wielu klientów na produkcji.

Co dalej

• Platformy e-commerce B2B: Platformy e-commerce B2B 2026
• Wybór platformy: Jak wybrać platformę e-commerce B2B
• Architektura headless: Headless commerce dla B2B