Headless vs monolit dla średniego polskiego sklepu — kiedy migracja ma sens, kiedy spali budżet

Co kilka miesięcy ktoś mi pisze: „Marcin, mam sklep na PrestaShop, jest wolno, klient na konferencji powiedział, że headless to przyszłość. Migrujemy?"

Odpowiedź zazwyczaj brzmi: nie. Albo: jeszcze nie. Albo: najpierw napraw monolit, a potem porozmawiajmy.

Headless commerce to świetna architektura. Dla części sklepów. Dla większości polskich sklepów średniej wielkości — to 20-krotnie droższe rozwiązanie problemu, który można rozwiązać taniej. Zanim przepalisz 200-400k na migrację, przeczytaj to.

Co to w ogóle jest, w trzech zdaniach

Monolit: jedna aplikacja robi wszystko — backend, baza danych, frontend, panel admina. Przykłady: PrestaShop, WooCommerce, Magento (Open Source), Shopware. Frontend i backend są ze sobą sklejone.

Headless: backend (zarządzanie produktami, zamówieniami, klientami) jest oddzielony od frontendu (to, co widzi klient). Komunikują się przez API. Frontend zwykle pisany w Next.js, Astro, Nuxt. Backend to np. Saleor, Medusa, Shopify Storefront API, BigCommerce, commercetools — albo własny.

Po polsku: w monolicie zmiana koloru przycisku i zmiana algorytmu wyceny to zmiany w tej samej aplikacji. W headless to dwie różne aplikacje, dwa różne deploye, dwa różne zespoły (często).

Kiedy headless ma realny sens

Pominę marketingowe brednie typu „bo szybciej", „bo elastyczniej". Konkretnie — pięć sytuacji, w których migracja na headless w polskim sklepie się realnie opłaca.

1. Masz wiele kanałów sprzedaży i frontów

Sprzedajesz na sklepie internetowym, w aplikacji mobilnej, w kiosku w sklepie stacjonarnym, w marketplace, w PWA. Każdy z tych frontów potrzebuje danych produktowych, cen, stocku. W monolicie integracja każdego z nich to ból. W headless — jedno API obsługuje wszystkie.

To realny case dla sieci omnichannel. Dla 90% sklepów online-only — overkill.

2. Performance frontu jest twoim wąskim gardłem (i monolit już nie wyrobi)

Masz duży ruch (~200k+ sesji miesięcznie), monolit jest „doskręcony do końca" — Redis, CDN, cache na każdym poziomie — i nadal LCP > 3s, kanibalizuje to SEO i konwersję. Wtedy frontend w Next.js na Vercel/Cloudflare może realnie przyspieszyć Core Web Vitals do poziomu, którego monolit nie osiągnie.

Ale: zanim założysz, że to ten przypadek — sprawdź, czy monolit jest naprawdę zoptymalizowany. W 70% przypadków, które widziałem, sklep „wolny" na PrestaShop był wolny z powodu niezoptymalizowanych zapytań do bazy, nieumiejętnego cache'owania, źle ustawionych obrazków. Naprawa kosztowała 15k zamiast 300k.

3. Masz silny zespół developerski i chcesz pełnej kontroli

Headless wymaga dedykowanego frontend dewa, dedykowanego backend dewa, DevOpsa i tester­a. Minimum 3-4 osoby w zespole, najlepiej in-house. Jeśli twój sklep prowadzi „chłopak z miasta, który zrobił mi to na PrestaShop" — headless cię pochłonie i wypluje.

4. Masz unikalny model biznesowy, którego monolit nie obsłuży

Nietypowe konfiguratory, własna logika wyceny, abonamenty z mikrotransakcjami, marketplace z wieloma sprzedawcami z własnymi regułami — to są przypadki, gdzie monolit zaczyna się wić, a headless naturalnie obsługuje. Ale to wąskie nisze.

5. Skalujesz na rynki zagraniczne z bardzo różnymi UX

Sprzedajesz w PL, DE, CZ, FR — i każdy rynek wymaga istotnie innego UX, języka, designu, integracji płatniczych. W monolicie jeden frontend = kompromis dla wszystkich. W headless możesz mieć różne fronty na różnych domenach, korzystające z jednego backendu z produktami.

To realne dla skalujących się cross-border. Dla sklepu PL-only — bez znaczenia.

Kiedy NIE migrować — pięć ostrzegawczych flag

Te sytuacje to stop sign. Jeśli choć jedna jest twoja, odłóż migrację na 1-2 lata.

A. Twój sklep robi obrót < 5 mln PLN rocznie. Headless ma sens przy skali. Przy mniejszej — koszty utrzymania zjedzą zysk, a problemy, które rozwiązuje, są mniejsze niż koszty.

B. Nie wiesz, dlaczego chcesz migrować, poza „bo headless". Jeśli nie umiesz powiedzieć: „mój problem to X, monolit go nie rozwiązuje, headless tak" — nie migruj.

C. Twój zespół IT to 0-1 osoba (lub agencja na zlecenia). Headless wymaga ciągłej pieczy. Bez zespołu się rozsypie.

D. Polskie integracje są kluczowe i nie chcesz ich pisać od zera. PrestaShop ma gotowe moduły do BaseLinkera, Allegro, Przelewy24, Paynow, Furgonetki, Apaczki. W headless — wiele z nich musisz pisać sam albo szukać niedojrzałych pluginów.

E. Twój monolit działa, ale nie został zoptymalizowany. Wydaj 15-30k na audyt i optymalizację monolitu, zanim wydasz 300k na migrację. W 7 na 10 przypadków problem znika.

Koszty i timeline — konkretne liczby z polskiego rynku 2026

Brutalna część. To są realne widełki, jakie widzimy w projektach (anonimizowane, średnia sklep z 5-25 mln PLN obrotu).

Migracja na headless z PrestaShop/WooCommerce:

• Audyt i architektura: 25-50k PLN
• Frontend (Next.js + design system): 120-250k PLN
• Backend (jeśli zmiana z monolitu na Saleor/Medusa): 100-200k PLN
• Integracje (płatności, logistyka, BaseLinker, faktury): 40-80k PLN
• Migracja danych, testy, deploy: 30-60k PLN
• Razem: 315-640k PLN. Realistycznie środek widełek ~400-500k.

Czas: 6-12 miesięcy od decyzji do produkcji. W tym minimum 2-3 miesiące, w których stara strona działa, nowa nie.

Koszty utrzymania po migracji:

• Hosting/CDN (Vercel, Cloudflare): 2-8k PLN miesięcznie (zależnie od ruchu).
• Dev team: minimum 2 FTE, ~25-40k miesięcznie razem.
• Monitoring, narzędzia, licencje: 2-5k PLN miesięcznie.
• Razem: 30-50k PLN miesięcznie. Rocznie: 360-600k.

Porównaj to z utrzymaniem zoptymalizowanego PrestaShop:

• Hosting dedykowany: 1-3k PLN miesięcznie.
• Dev: 0.5-1 FTE on-demand, 8-15k miesięcznie.
• Razem: 9-18k PLN miesięcznie. Rocznie: ~150k.

Różnica: ~300k PLN rocznie. Plus koszt migracji. Czy headless da ci +500k PLN dodatkowego zysku rocznie? Jeśli tak — migruj. Jeśli nie — masz inwestycję, która się nigdy nie zwróci.

Stacki, które działają w polskim sklepie

Krótko, bez religii:

Saleor — polski projekt (sic!), open source, GraphQL, dobrze udokumentowany, sensowna społeczność. Dla średnich sklepów z silnym zespołem dev.

Medusa — JS-native, modułowy, dynamicznie się rozwija. Świetny dla zespołów Node.js.

Shopify Storefront API — Shopify jako backend, własny front. Najszybsza droga do headless, ale uzależnia cię od Shopify (i jego abonamentu).

commercetools — enterprise, drogo, dla dużych. Pomijam dla średnich sklepów.

BigCommerce / Shopware (headless mode) — opcja, ale rzadziej widzę w PL.

Custom backend (Laravel/Symfony/Node + Postgres) + Next.js front — dla zaawansowanych zespołów z nietypową logiką. Najdroższe, ale najbardziej elastyczne.

Pułapka pośrednia: „decoupled" zamiast pełnego headless

Jest opcja, którą rzadko widać w dyskusjach: decoupled architecture. Trzymasz monolit (np. PrestaShop) jako backend, ale frontend zastępujesz Next.js/Astro, który konsumuje API monolitu. Nie pełny headless, ale szybki frontend.

Plusy: mniej zmian, większość integracji zostaje, koszt 30-50% pełnej migracji. Minusy: PrestaShop API ma ograniczenia, czasem brakuje endpointów, część logiki trzeba duplikować.

Dla wielu sklepów PL średniej wielkości to najsensowniejszy kompromis: dostajesz szybki front, nie spalasz budżetu, zachowujesz dojrzałe integracje (BaseLinker, P24, faktury). Robiliśmy to dla kilku klientów Pro1 — efekty świetne, koszt znośny.

Co zrobić, zanim zdecydujesz

Trzy ruchy, zanim podejmiesz decyzję wartą 300-500k:

1. Audyt techniczny obecnego sklepu. Co jest realnym wąskim gardłem? Front, baza, hosting, kod, integracje? 80% odpowiedzi „chcemy headless" znika po audycie.
2. Mapa rozwoju biznesu na 3 lata. Jakie kanały, jakie rynki, jaki ruch? Headless ma sens dla skali, której realnie się spodziewasz, nie tej, którą chciałbyś mieć.
3. Realny rachunek zysków i strat. Migracja kosztuje X, utrzymanie Y rocznie. Co dokładnie zarobisz dzięki temu? Konkretnie, w liczbach.

W Pro1 robimy takie audyty i nieraz mówimy klientowi: nie migruj. Zaoszczędzone 400k to lepsza decyzja niż przepalone 400k. Sprawdź naszą ofertę albo umów rozmowę, jeśli właśnie ten temat stoi przed tobą.