TL;DR
- Headless commerce oddziela frontend od backendu. Sklep i silnik e-commerce działają niezależnie, komunikując się przez API.
- Dla 80% polskich sklepów MŚP: headless to overengineering. Shopify, WooCommerce lub Shoper wystarczą i będą tańsze w utrzymaniu.
- Headless ma sens przy: 10 000+ SKU, niestandardowym checkout, multi-region, bardzo wysokich wymaganiach Core Web Vitals.
- Trzy platformy warte rozważenia: Shopify Hydrogen (dla sklepów już na Shopify), Medusa.js (open source, self-hosted), Saleor (GraphQL-first, enterprise-ready).
- Koszt budowy headless: 25 000-80 000 PLN. Koszt utrzymania: 2-5x wyższy niż monolitu.
Headless commerce: kiedy to rewolucja, a kiedy przepłata?
Headless commerce pojawia się w każdej konferencji e-commerce jako "następny poziom". W praktyce, dla większości polskich sklepów, headless to droższe narzędzie do rozwiązania problemu który nie istnieje.
Zanim odpowiem kiedy headless commerce ma sens, powiem kiedy nie ma: przy sklepie z 50-2 000 produktami, jedną wersją językową, standardowym checkout i zespołem bez full-stack developerów. To opis 80% polskich sklepów MŚP. Dla nich monolit (Shopify, WooCommerce, Shoper) jest lepszy, tańszy i bezpieczniejszy.
To nie jest modna opinia. Jest wbrew temu co piszą agencje e-commerce, bo headless to wyższy budżet projektu. Ale uczciwa analiza prowadzi do tego samego wniosku.
Jak działa headless commerce w praktyce?
W tradycyjnym sklepie (monolit) frontend i backend to jedna aplikacja. Shopify renderuje strony, obsługuje koszyk, checkout, płatności i CMS w jednym systemie. Nie musisz nic konfigurować żeby strona działała.
W architekturze headless commerce frontend żyje osobno: to aplikacja Next.js, Nuxt, Remix lub statyczna strona (Astro, Gatsby). Komunikuje się z backendem e-commerce przez API (REST lub GraphQL). Backend obsługuje produkty, zamówienia, płatności. Frontend wyświetla je jak chce.
Zalety tej separacji:
- Pełna swoboda frontendu: możesz zbudować dowolny UX bez ograniczeń szablonów platformy
- Wydajność: frontend jako statyczna strona + CDN = najszybsze możliwe Core Web Vitals
- Omnichannel: ten sam backend obsługuje sklep, aplikację mobilną, kiosk w sklepie stacjonarnym
- Niezależny deployment: zmiana frontendu nie wymaga dotykania backendu i odwrotnie
Wady:
- Złożoność: dwa systemy zamiast jednego, dwa deployments, dwa monitoring
- Koszt: droższy build, droższe utrzymanie, potrzebny developer znający oba stacki
- Czas na rynek: MVP w monolicie: 4-6 tygodni. MVP headless: 10-20 tygodni minimum
Trzy platformy headless warte uwagi polskiego MŚP
Shopify Hydrogen
Shopify Hydrogen to oficjalny React meta-framework Shopify do budowy headless storefront. Zaleta: backendowe funkcje Shopify (checkout, płatności, inventory) zostają. Zmieniasz tylko frontend. Dobry wybór jeśli masz już sklep na Shopify i chcesz pełnej kontroli nad frontendem bez migracji backendu.
Wady: vendor lock-in do Shopify (backend i hosting). Koszty Shopify Plus (wymagany dla Hydrogen w pełnym zakresie) to $2 300/mies.
Medusa.js
Medusa to open-source platforma e-commerce dla developerów. Self-hosted, GraphQL i REST API, modularna architektura (możesz wymieniać płatności, wysyłkę, CMS osobno). Żadnych miesięcznych opłat platformowych.
Dla kogo: zespoły z full-stack devami które chcą pełnej kontroli nad kodem i danymi. Dobra opcja dla sklepów z niestandardową logiką biznesową (custom pricing, B2B, wholesale).
Wady: brak managed hostingu (musisz sam deployować), małe community versus Shopify/WooCommerce, mniej gotowych integracji z polskimi systemami.
Saleor
GraphQL-first platforma, open-source, silna w enterprise. Zaawansowane zarządzanie wieloma kanałami sprzedaży, multi-currency, multi-language out of the box. Hosting zarządzany dostępny w Cloud.
Dla kogo: sklepy z poważnymi wymaganiami multi-region i wielokanałowości. Wchodzi w grę przy budżetach powyżej 100 000 PLN za projekt.
Headless Shopify (Hydrogen): kiedy ma sens?
Hydrogen jest właściwym wyborem w czterech konkretnych sytuacjach:
1. Core Web Vitals są blokerem SEO
Jeśli Google PageSpeed Insights i GSC pokazują LCP powyżej 3,5s i INP powyżej 300ms, a wszystkie optymalizacje monolitu zostały wyczerpane: Hydrogen z SSG/ISR może dać 0,8-1,5s LCP. To ma znaczenie dla rywalizacji o pierwszą stronę Google przy konkurencyjnych frazach.
2. Potrzebujesz custom checkout
Shopify Plus pozwala na rozbudowę checkout, ale tylko w granicach platformy. Headless frontend: checkout może być w pełni customowy (multi-step, konfigurator produktów, warunkowe pola), bez limitów szablonów.
3. Sklep + aplikacja mobilna + POS z jednym backendem
Trzy frontendy (web, mobile, punkt sprzedaży) komunikujące się ze wspólnym inventory i zamówieniami: to naturalny use case headless. Alternatywa: trzy oddzielne systemy z ręczną synchronizacją. Headless jest tu tańszy długoterminowo.
4. Treści zarządzane przez CMS z zaawansowanym workflow
Duże sklepy z dużą częstotliwością zmian kontentu (codzienne promocje, bannery, landing page'e dla kampanii) zyskują na połączeniu Shopify (backend) z headless CMS (Sanity, Contentful, Storyblok). Marketerzy mogą zmieniać treści bez deploymentu.
Kiedy headless commerce przeszkadza zamiast pomagać
Z mojego doświadczenia: większość polskich firm przychodzi z pomysłem na headless po przeczytaniu artykułów technicznych, zanim sprawdziła czy mają problem który headless rozwiązuje.
Konkretne sygnały że headless NIE jest właściwą odpowiedzią:
Mały katalog produktów (< 2 000 SKU) bez planów ekspansji. Monolit jest wystarczająco szybki jeśli jest poprawnie skonfigurowany. Optymalizacja obrazów, cache, CDN i lazy loading rozwiązują 90% problemów z wydajnością bez zmiany architektury.
Brak własnych full-stack developerów. Headless wymaga utrzymania dwóch systemów w dwóch technologiach. Jeśli nie masz dewelopera który zna Next.js i API sklepu: każda zmiana to kosztowne zlecenie zewnętrzne. Monolit jest w tym scenariuszu tańszy w utrzymaniu.
Timeline poniżej 3 miesięcy na MVP. Headless nie da się sensownie dostarczyć w 4 tygodnie. Jeśli musisz sprzedawać szybko: monolit, deploy, optymalizacja po uruchomieniu.
Budżet poniżej 40 000 PLN. Poniżej tej kwoty nie da się zbudować solidnego headless z właściwą architekturą, testami i dokumentacją. To co dostaniesz za mniej: prototyp który nie wytrzyma ruchu i będzie generował koszty techniczne zamiast przychodów.
Tabela decyzyjna: headless commerce czy tradycyjny e-commerce?
| Kryterium | Headless | Monolit |
|---|---|---|
| Katalog produktów | 10 000+ SKU | do 5 000 SKU |
| Wersje językowe | 5+ języków, multi-currency | 1-3 języki |
| Checkout | Niestandardowy, multi-step | Standardowy checkout platformy |
| Frontendy | Web + mobile + POS | Tylko web |
| Wymagania CWV | LCP < 1s, INP < 100ms | Standardowe |
| Własny dev team | Full-stack minimum 2 osoby | Dowolny |
| Budżet projektu | 40 000 PLN+ | 4 000-20 000 PLN |
| Timeline MVP | 3-6 miesięcy | 4-8 tygodni |
Jeśli Twój sklep spełnia 2-3 z kryteriów po lewej: czas rozmawiać o headless. Jeśli spełnia 0-1: monolit.
Więcej o opcjach opcjach e-commerce i integracji z BaseLinker niezależnie od architektury.
Koszt migracji na headless: realna kalkulacja
Koszt budowy headless sklepu od podstaw:
| Zakres | Koszt |
|---|---|
| Projekt architektury + wybór stacku | 5 000-10 000 PLN |
| Headless frontend (Next.js/Hydrogen) | 15 000-30 000 PLN |
| Backend API + integracje | 8 000-20 000 PLN |
| CMS headless (Sanity/Contentful setup) | 3 000-8 000 PLN |
| Testy, deploy, dokumentacja | 5 000-12 000 PLN |
| Razem | 36 000-80 000 PLN |
Koszt miesięczny utrzymania (po buildzie):
Monolit Shopify: 500-1 500 PLN/mies (hosting, maintenance, mniejsze zmiany). Headless: 2 000-6 000 PLN/mies (dwa systemy, dwa deployments, więcej konfiguracji przy zmianach).
Koszt migracji istniejącego sklepu:
Migracja danych produktów, zamówień, klientów to dodatkowe 5 000-15 000 PLN. Plus ryzyko przerwy w działaniu sklepu jeśli migracja nie jest dokładnie zaplanowana.
Podsumowanie kosztowe: headless zwraca się przy przychodach sklepu powyżej 500 000 PLN/rok, gdzie różnica w wydajności (konwersja) lub elastyczności (szybszy czas wprowadzenia zmian) uzasadnia wyższe koszty.
Od czego zacząć jeśli zdecydujesz się na headless?
Konkretna ścieżka jeśli Twój sklep spełnia kryteria:
Krok 1: Audyt obecnego sklepu
Zanim zmienisz architekturę: zmierz obecne Core Web Vitals (Google PageSpeed Insights, GSC). Zmierz czas implementacji typowych zmian (jak długo trwa dodanie nowej sekcji na homepage?). Zmierz ból (co konkretnie nie działa i ile to kosztuje miesięcznie).
Krok 2: Proof of Concept
Nie migruj całego sklepu. Zbuduj headless frontend dla jednej sekcji (landing page kampanii albo kategoria produktów). Zmierz wydajność. Porównaj z monolitem.
Krok 3: Migracja stopniowa
Strangle pattern: headless frontend zastępuje monolit strona po stronie. Backend zostaje. W każdym momencie można zatrzymać migrację bez przerywania działania sklepu.
Jeśli chcesz ocenić czy headless ma sens dla Twojego sklepu lub potrzebujesz wyceny, pomożemy przeprowadzić audyt. Szczegóły usług w ofercie Soft Synergy. Nie sprzedajemy headless każdemu, bo w większości przypadków to nie jest właściwa odpowiedź.