Medusa + KODA Plus
a nie WooCommerce.
WooCommerce świetnie startuje, ale rośnie przez doklejanie kolejnych płatnych wtyczek do monolitu WordPressa, co przy skali i przy poważnym B2B robi się wolne, drogie i kruche. Medusa daje headless backend w TypeScript, gdzie logikę B2B piszemy jako natywne moduły, a nie łatamy wtyczkami, więc front jest szybki, koszty są przewidywalne, a kod w całości należy do klienta.
- Funkcje rosną przez płatne wtyczki: subskrypcje, B2B, dynamiczne ceny, bundle, multi magazyn czy zaawansowany checkout to osobne rozszerzenia z roczną licencją, więc realny koszt rośnie z każdym modułem i nigdy się nie kończy.
- WooCommerce trzyma produkty, zamówienia i meta dane w tabelach postów WordPressa (wp_posts, wp_postmeta), więc przy dużym katalogu i ruchu zapytania do bazy stają się wąskim gardłem mimo HPOS i cache.
- Front i logika sklepu są spięte w jednym monolicie PHP z motywem i kilkudziesięcioma wtyczkami, więc każda aktualizacja WordPressa, motywu albo wtyczki grozi konfliktem i regresją.
- Zaawansowany B2B (tiery cenowe per grupa, rejestracja po NIP z walidacją GUS, MOQ, limity kredytowe, quick order po SKU) wymaga sklejania kilku komercyjnych wtyczek, które nie były projektowane razem i często gryzą się ze sobą.
- Powierzchnia bezpieczeństwa jest duża: im więcej wtyczek, tym więcej potencjalnych podatności, a niezałatany WordPress to najczęstszy wektor włamań w polskim e-commerce.
- Klient dostaje całe repozytorium na GitHub: storefront Astro plus backend Medusa, zero abonamentu za moduły, bo logika B2B to nasz kod, a nie wynajmowana wtyczka.
- Front jest statyczny i renderowany na brzegu sieci na Cloudflare, więc czas ładowania nie zależy od liczby zapytań do bazy, a backend Medusa skaluje się niezależnie na Railway.
- Funkcje B2B (tiery cenowe, akceptacja firm z walidacją GUS, quick order po SKU, negocjacje live, limity kredytowe, loyalty, faktury VAT i JPK) piszemy jako natywne moduły Medusa, spójne i utrzymywane razem, a nie zlepek wtyczek.
- Brak vendor lock-in: dane wychodzą jako standardowy SQL z Postgresa, a front to statyczne pliki, więc migracja czy zmiana hostingu nie wymaga przepisywania sklepu.
- Polskie integracje (BLIK, Przelewy24, PayU, InPost, DHL, Subiekt i InsERT) podpinamy przez oficjalne SDK i API jako moduły backendu, bez polegania na pojedynczych wtyczkach utrzymywanych przez zewnętrznych autorów.
Pełne porównanie
Rdzeń WooCommerce jest open-source (GPL), ale kluczowe rozszerzenia kupujesz z licencją i aktualizacjami na abonament; sklep żyje wewnątrz instalacji WordPressa.
Całe repozytorium (front Astro plus backend Medusa) trafia do klienta na GitHub i jest w 100 procent jego własnością, bez licencji na moduły.
Tanio na start, ale realny budżet rośnie z każdą płatną wtyczką (subskrypcje, B2B, ceny dynamiczne, bundle) plus coroczne odnowienia licencji i koszt utrzymania serwera pod rosnący ruch.
Wyższy koszt budowy na starcie, za to bez abonamentów za moduły; logika to kod klienta, a hosting Cloudflare plus Railway jest przewidywalny i skaluje się stopniowo.
Przez motyw, hooki i wtyczki w PHP; możliwe daleko, ale każda głębsza zmiana ryzykuje konflikt z innymi wtyczkami i pęka przy aktualizacjach.
Pełna customizacja w TypeScript: front i backend rozdzielone, logika jako izolowane moduły Medusa, zmiany nie ruszają reszty sklepu i są pod kontrolą wersji.
Wykonalny, ale przez sklejanie kilku komercyjnych wtyczek (ceny per grupa, rejestracja firm, MOQ, quick order), które nie były projektowane razem; przy poważnym B2B robi się kruche.
B2B jest natywny: tiery cenowe per grupa, akceptacja firm z walidacją GUS po NIP, MOQ, quick order po SKU, limity kredytowe, negocjacje live i faktury VAT/JPK jako spójne moduły backendu.
Dane rozsiane w tabelach postów i meta WordPressa plus zależności od konkretnych wtyczek; eksport i migracja na inny stack to realny projekt, nie przełącznik.
Zero lock-in: dane wychodzą jako standardowy SQL z Postgresa, a front to statyczne pliki; zmiana hostingu czy dalszy rozwój nie wymaga przepisywania sklepu.
Monolit PHP zależny od zapytań do MySQL na tabelach postów; przy dużym katalogu i ruchu trzeba mocno cachować i skalować serwer, a i tak baza bywa wąskim gardłem.
Front statyczny serwowany z brzegu sieci Cloudflare (czas ładowania niezależny od bazy), backend Medusa skaluje się osobno na Railway; obciążenie rozłożone, nie spięte w jeden serwer.
BLIK, Przelewy24, PayU, InPost, DHL czy integracja z Subiekt/InsERT są dostępne, ale jako wtyczki różnych autorów o różnej jakości i tempie aktualizacji.
Polskie płatności i logistyka (BLIK, Przelewy24, PayU, InPost, DHL) oraz ERP (Subiekt, InsERT) podpinane przez oficjalne SDK i API jako moduły backendu, utrzymywane spójnie z resztą kodu.
Trzeba pilnować aktualizacji rdzenia WordPressa, motywu i każdej wtyczki naraz, kontrolować konflikty i podatności; im więcej wtyczek, tym większa powierzchnia ryzyka.
Mniejsza powierzchnia ryzyka: brak motywów i kilkudziesięciu wtyczek, zależności pod kontrolą wersji w repo, aktualizacje testowane w CI przed wdrożeniem, front i backend aktualizowane niezależnie.
Uczciwie
Jeśli prowadzisz prosty sklep B2C, masz mały katalog i już żyjesz w ekosystemie WordPressa (blog, treści, znajomy zespół), WooCommerce wystartuje szybciej i taniej, a gotowe wtyczki pokryją większość potrzeb bez pisania kodu.
Twój sklep. Twój kod.
Pokażemy na Twoim przypadku, jak wyglądałby sklep na Medusa + KODA Plus i ile realnie kosztuje w porównaniu z WooCommerce.