Medusa vs WooCommerce: co naprawdę kosztuje utrzymanie sklepu

Wybierz WooCommerce, jeśli sklep ma mieścić się w standardzie: prosty katalog, jeden rynek, treść i sprzedaż w jednym systemie, a utrzymanie ma być tanie i dostępne u wykonawcy z dowolnego miasta. Wybierz Medusę, jeśli logika sprzedaży, model danych albo integracje wychodzą poza to, co da się złożyć z wtyczek, i masz kim utrzymywać własny kod zamiast cudzych rozszerzeń.

Obie platformy są darmowe na wejściu i obie zostawiają kod oraz dane po Twojej stronie. Argumenty znane z porównań z SaaS-em tutaj nie działają: nie ma prowizji od obrotu ani limitów planu. Zostaje pytanie mniej efektowne: ile kosztuje utrzymanie przy życiu rzeczy, którą już posiadasz.

Licencja kosztuje zero po obu stronach, więc zestawianie ceny WooCommerce z ceną naszego wdrożenia jest porównaniem dwóch różnych rzeczy. Rachunek rozkłada się na trzy warstwy i tak go tutaj rozbijamy: licencja, wdrożenie, utrzymanie. Do tego czwarta pozycja, której nikt nie planuje: koszt pierwszej zmiany po starcie.

To nie jest porównanie darmowego z płatnym

Najczęstszy błąd w tym zestawieniu polega na ustawieniu WooCommerce po stronie „za darmo”, a Medusy po stronie „drogo”. Licencyjnie obie są otwarte. WooCommerce to darmowa wtyczka do WordPressa rozwijana przez Automattic, a rdzeń Medusy jest na licencji MIT, z osobnymi warunkami dla wydania Enterprise.

Zanim przejdziemy do różnic, warto oczyścić pole. Te trzy rzeczy wyglądają po obu stronach tak samo:

• Zero prowizji od obrotu. WooCommerce deklaruje 0% udziału w przychodzie, Medusa podaje 0,0% opłaty od GMV także w swojej usłudze chmurowej. Płacisz operatorowi płatności, nie platformie.
• Kod i dane są Twoje. Baza stoi na Twojej infrastrukturze: MySQL albo MariaDB przy WooCommerce, PostgreSQL przy Medusie.
• Hosting jest Twoim problemem. Żadna z tych platform nie utrzyma serwera za Ciebie, chyba że dokupisz usługę zarządzaną.

Trzy warstwy kosztu, po obu stronach tak samo

Najuczciwszy sposób na policzenie tego wyboru to rozłożyć go na warstwy i przy każdej powiedzieć, skąd bierze się liczba. Pierwsza warstwa jest identyczna, druga i trzecia dzielą te platformy naprawdę.

Kwoty netto. Widełki po stronie WooCommerce pochodzą od polskich agencji wdrożeniowych i zostały zebrane 12 sierpnia 2026; różnią się między wykonawcami, więc podajemy pasmo, nie średnią. Widełki po stronie Medusy są nasze i publikujemy je w całości. Ceny hostingu i rozszerzeń podawane przez dostawców są w tabeli poniżej, sprawdzone 11 sierpnia 2026.

Dwie uwagi do pochodzenia tych liczb. Kosztu wdrożenia nie publikuje żaden z dostawców, więc lewa kolumna to rynek, a nie cennik. Publicznie krąży jeden punkt po stronie Medusy, agencja z Gdańska podaje „od około 20 000 dolarów”, ale jeden punkt nie jest widełkami i nie wiadomo, jaki zakres opisuje.

Obie kolumny opisują ten sam rynek pracy, więc różnica nie bierze się z geografii. Bierze się z zakresu: prosty sklep na gotowym motywie i platforma budowana pod model sprzedaży to dwa różne projekty, które tylko przypadkiem porównuje się w jednej tabeli.

„Wyżej” ma konkretne miejsce. Zaczyna się tam, gdzie WooCommerce też przestaje być tani, czyli przy własnym paśmie 25 000-60 000 zł i powyżej, bo o cenie decydują już integracje, migracja danych i logika sprzedaży. Na tym poziomie porównujesz dwa projekty, a nie licencje.

To jest zakres, nie oferta. Konkretna liczba wychodzi z rozmowy o katalogu, integracjach i stanie danych, a model wyceny opisujemy na stronie cennika.

Dwanaście wymiarów obok siebie

Ta tabela zestawia wyłącznie to, co da się sprawdzić u źródła: strony dostawców, dokumentacja, repozytorium. Żadna liczba poniżej nie jest naszym szacunkiem ani cudzą wyceną.

Stan na 11 sierpnia 2026. Źródła: woocommerce.com (wymagania serwera, cennik), wordpress.org, docs.medusajs.com, medusajs.com/pricing, github.com/medusajs/medusa. Kwoty podajemy w walutach, w jakich publikują je dostawcy. Do tabeli wracamy raz na kwartał.

Gdzie naprawdę siedzi koszt WooCommerce

W licencji go nie ma, bo licencji nie ma wcale. Rozkłada się na cztery miejsca, z których żadne nie wygląda groźnie osobno, a razem tworzą pozycję, której nikt nie zaplanował w budżecie.

Wtyczka to nie funkcja, tylko cudzy kod w Twoim checkoucie

Każda brakująca rzecz domyka się w WooCommerce wtyczką: subskrypcje, ceny B2B, paczkomaty, faktury, feedy. Sam WooCommerce wycenia rozszerzenia na 29 do 299 dolarów rocznie za sztukę, a swoje własne Subscriptions na 279 dolarów za rok.

Kwota jest tu mniejszą połową problemu. Większą jest to, że po roku ścieżka zakupowa składa się z kodu kilkunastu niezależnych autorów, a każdy z nich ma własny harmonogram wydań, własną poprzeczkę jakości i własne plany na przyszłość.

Cztery zegary, które nie chodzą razem

Aktualizacja w tym stosie nie jest jednym zdarzeniem. Tykają cztery niezależne zegary i to ich rozjazd, a nie sama aktualizacja, tworzy ryzyko dla checkoutu:

• PHP. WooCommerce wymaga dziś wersji 8.3 lub nowszej i testuje do 8.4, a starsze gałęzie opisuje jako po końcu oficjalnego wsparcia.
• WordPress. Wymagana wersja to 6.9 lub nowsza, a rdzeń aktualizuje się częściej niż większość wtyczek.
• WooCommerce. Wersja 11.0.1 w dniu sprawdzenia, przy ponad siedmiu milionach aktywnych instalacji.
• Każda wtyczka z osobna. Osobny autor, osobne tempo, osobna decyzja, czy w ogóle nadążać za resztą.

Nikt nie testuje Twojej kombinacji przed wydaniem, bo ta kombinacja istnieje wyłącznie u Ciebie. Dlatego w praktyce potrzebujesz środowiska testowego i kogoś, kto tam zagląda, zanim zmiana trafi na produkcję. To jest ta godzina miesięcznie, której nie widać na żadnej fakturze.

Bezpieczeństwo: to statystyka ekosystemu, nie straszak

Patchstack, firma sprzedająca ochronę dla WordPressa, w raporcie „State of WordPress Security in 2026” podaje 11 334 nowe podatności w ekosystemie WordPressa w 2025 roku, o 42% więcej niż rok wcześniej. 91% z nich dotyczyło wtyczek, 9% motywów, a w samym rdzeniu odnotowano sześć, opisanych jako niskiego priorytetu.

Dwie uczciwe uwagi do tej liczby. Źródłem jest dostawca zabezpieczeń, więc ma interes w tym, żeby robiła wrażenie. I dotyczy całego ekosystemu WordPressa, nie WooCommerce, więc nie mówi nic o Twoim sklepie. Mówi natomiast, gdzie leży powierzchnia ataku: w warstwie wtyczek, którą sam wybierasz.

Duży katalog: co zmienił HPOS, a czego nie

Zarzut, że WooCommerce trzyma zamówienia w tabelach wpisów WordPressa, jest już nieaktualny. Od wersji 8.2 dostępne jest High-Performance Order Storage: osobne tabele z własnymi indeksami, domyślnie włączone w nowych instalacjach. WooCommerce opisuje je wprost jako odpowiedź na skalowalność, niezawodność i prostotę struktury danych.

Nie mierzyliśmy wydajności żadnej z tych platform i nie podamy tu liczb. Można natomiast wskazać, gdzie architektura tworzy ryzyko: przy WooCommerce wydajność zależy od sumy wszystkich zainstalowanych rozszerzeń, bo każde dokłada własne zapytania i skrypty. HPOS porządkuje rdzeń, ale nie zmienia tego, co robią wtyczki. Co pęka i w jakiej kolejności przy skoku ruchu, rozkładamy osobno w tekście o dziesięciokrotnym ruchu.

Brak granicy między treścią a sklepem

Sklep i blog żyją w jednej instalacji, jednej bazie i jednym panelu. To zaleta, dopóki nie zamienia się w koszt: zmiana w warstwie treści potrafi dotknąć sprzedaży, a ruch na artykułach dzieli zasoby z koszykiem.

Przy Medusie ta granica istnieje z definicji, bo sprzedaż siedzi za API, a front i treść mogą stać osobno. Nie jest to lepsze samo w sobie. Jest lepsze wtedy, gdy naprawdę potrzebujesz osobnych ścieżek wdrożeniowych dla treści i dla sprzedaży. Co to znaczy w praktyce, opisujemy przy architekturze headless.

Co daje Medusa i czym za to płacisz

Medusa jest backendem sprzedaży w TypeScripcie, ułożonym w cztery warstwy: trasy API, workflow z logiką biznesową, moduły domenowe i baza PostgreSQL. Dostawców płatności, wysyłki, CMS-a czy wyszukiwarki podmienia się jako moduły, bez forkowania rdzenia.

• Model danych pod Twój asortyment. Produkty na wymiar, zestawy, konfiguracje i ceny liczone z parametrów nie muszą lądować w polach opisowych.
• Logika sprzedaży jako kod, nie jako obejście. Cenniki kontraktowe, akceptacje zamówień i własne reguły rabatowe piszesz w workflow, zamiast składać z trzech wtyczek.
• Jedna granica dla wielu kanałów. Ten sam backend obsługuje sklep, aplikację i integracje, bo wszystko idzie przez API.

Rachunek za to jest prosty i trzeba go powiedzieć wprost. Znika problem cudzych wtyczek, a pojawia się potrzeba zespołu: TypeScript, PostgreSQL, DevOps i integracje, których nikt za Ciebie nie napisał. To zamiana jednego kosztu na inny, nie jego usunięcie.

Koszt zmiany po starcie

To jest pozycja, która rozstrzyga najwięcej, a nie ma jej w żadnym budżecie wdrożenia. Pytanie brzmi prosto: ile kosztuje pierwsza rzecz, o którą poprosisz trzy miesiące po uruchomieniu sklepu.

Na WooCommerce zmiana poza standardem to zwykle kolejna wtyczka. Razem z funkcją kupujesz jej roczną licencję, jej autora, jego harmonogram wydań i ryzyko, że pokłóci się z resztą stosu. To dokładnie ta warstwa, o której mówi statystyka podatności wyżej: powierzchnia rośnie z każdą pozycją na liście.

U nas ta sama zmiana jest zadaniem w backlogu, na kodzie, który należy do Ciebie. Płacisz za pracę, nie za nową zależność, a po wdrożeniu nie zostaje nic, co trzeba osobno aktualizować i pilnować przy każdej kolejnej wersji.

Czego wtyczka nie zrobi

Do tej pory porównywaliśmy koszt tego samego. Jest jeszcze warstwa, w której obie platformy nie stoją równo, bo wszystko zależy w niej od dostępu do danych i do logiki sklepu: praca, którą przejmuje AI.

U nas to osobny etap z ceną. Automatyzacje AI wyceniamy od 6 000 zł netto za workflow, a zakres jest zwykle nudny i policzalny:

• Opisy produktów generowane z atrybutów, a nie z niczego.
• Tłumaczenie katalogu przy wejściu na kolejny rynek, opisane osobno w tekście o tłumaczeniu katalogu z AI.
• Feedy marketplace: mapowanie kolumn katalogu na pola kanału i walidacja przed wysyłką, tak jak w feedzie budowanym z Claude Code.
• Statusy zamówień i odpowiedzi na pytania o przesyłkę.
• Mapowanie atrybutów między eksportem z ERP a modelem produktu.

Druga rzecz to zarządzanie sklepem przez agentów AI. Warunkiem nie jest model, tylko backend: własny kod, własna baza i API, do którego agent ma pełny dostęp. Tam, gdzie sklep składa się z cudzych wtyczek, ten dostęp kończy się na granicy API konkretnej wtyczki.

Na WooCommerce każda z tych rzeczy też jest osiągalna, zwykle jako kolejna wtyczka albo integracja z zewnętrznym SaaS-em: własny abonament, własny cykl życia, własny dostęp do Twoich danych. To nie jest zarzut, tylko inny rachunek. Kupujesz gotową funkcję zamiast budować zdolność.

Kiedy wybrać WooCommerce

Ta sekcja nie jest kurtuazją wobec konkurenta. WooCommerce wygrywa w sytuacjach, które opisują większość polskich sklepów, a nie jakiś margines rynku.

• Katalog mieści się w standardzie. Kilkaset produktów z prostymi wariantami, jeden rynek, jedna waluta, sprzedaż detaliczna.
• Treść jest częścią sprzedaży. Blog, poradniki i sklep w jednym panelu to realna oszczędność pracy, a nie wada architektury.
• Budżet startowy jest bliski zeru. Rdzeń nic nie kosztuje, a pierwsze potrzeby domykasz gotowym rozszerzeniem zamiast projektem wdrożeniowym.
• Nie masz zespołu technicznego. Wykonawcę WordPressa znajdziesz w każdym mieście i wymienisz go bez przepisywania sklepu.
• Sprawdzasz dopiero, czy produkt się sprzedaje. Na tym etapie każda złotówka wydana na architekturę to złotówka niewydana na weryfikację hipotezy.

Dorzucimy jeszcze jedno, choć budujemy na Medusie. Jeśli Twoja lista problemów z WooCommerce sprowadza się do wolnego hostingu i dwudziestu wtyczek instalowanych latami bez przeglądu, to nie jest argument za zmianą platformy. To argument za porządkami.

Kiedy ten wybór w ogóle stoi

Większość sklepów nie ma tu żadnej decyzji do podjęcia, bo mieści się w standardzie, a wtedy WooCommerce jest tańszą odpowiedzią. Pytanie o silnik robi się realne dopiero wtedy, gdy w firmie widać konkretne rzeczy. Pięć markerów, po których to poznajemy:

• Katalog nie mieści się w standardowym modelu produktu. Produkty na wymiar, zestawy, konfiguratory, ceny liczone z parametrów. Objaw jest prosty: dane, które powinny być polami, siedzą w opisie albo w arkuszu obok.
• Logika sprzedaży jest przewagą, nie formalnością. Cenniki kontraktowe B2B, limity kupieckie, akceptacje zamówień, reguły per klient. Jeśli to jest powód, dla którego u Ciebie kupują, nie powinno mieszkać w cudzej wtyczce.
• Tempo wyznaczają integracje z ERP i magazynem. Nie strona, tylko stany, ceny, dokumenty i statusy. W takim projekcie front jest najmniejszym problemem.
• Sprzedajesz w wielu kanałach naraz. Sklep, marketplace, aplikacja, hurt. Każdy kanał chce danych po swojemu, a źródło prawdy ma zostać jedno.
• Suma wtyczek stała się ryzykiem operacyjnym. Nie chodzi o ich liczbę, tylko o to, że aktualizacja bywa wydarzeniem, przed którym ktoś wstrzymuje oddech.

Nie rozpoznajesz siebie w żadnym z tych punktów? Wtedy ten wybór Cię nie dotyczy, a przejście na Medusę kupi Ci kontrolę, której nie wykorzystasz. Rozpoznajesz kilka? Zostaje warunek ważniejszy od całej tabeli: musisz mieć kim to utrzymywać, własnym zespołem albo partnerem na stałej opiece. Bez tego Medusa jest złym wyborem niezależnie od swoich zalet.

Polskie realia, o których nie piszą porównania z zagranicy

Tutaj przewaga WooCommerce jest największa i nie ma sensu jej łagodzić. Płatności, kurierzy i integracje z popularnymi programami magazynowymi mają w katalogu wtyczek gotowe rozwiązania, często w kilku wersjach do wyboru, a odbiór w paczkomacie domyka się instalacją, nie projektem.

Medusa dokumentuje oficjalnie Stripe i PayPala jako dostawców płatności oraz ShipStation po stronie wysyłki. Polskiej bramki ani paczkomatów w tej dokumentacji nie ma, więc trzeba je napisać jako moduł. To realny koszt wdrożenia w Polsce i trzeba go policzyć przed decyzją, nie po niej.

Druga polska specyfika to dostępność wykonawców. WordPress i PHP to szeroki rynek pracy, Node.js z Medusą znacznie węższy. Jeśli plan zakłada, że za dwa lata sklep przejmie ktoś inny, ten argument waży więcej niż większość różnic technicznych z tabeli.

Czego to porównanie nie obejmuje

Granice stawiamy wprost, żeby dało się z tego tekstu korzystać jak ze źródła:

• Wydajności pod obciążeniem. Nie robiliśmy pomiarów żadnej z platform i nie powtarzamy cudzych benchmarków.
• Wyceny Twojego projektu. Widełki w tabeli warstw to pasmo rynkowe po stronie WooCommerce i nasze publikowane widełki po stronie Medusy, a nie oferta. Konkretna liczba zależy od zakresu, integracji i stanu danych; model wyceny opisuje cennik.
• Widełek innych wykonawców Medusy. Podajemy własne, bo nikt na tym rynku nie publikuje swoich. Jeśli zbierasz oferty, porównuj zakresy, nie same kwoty.
• Warunków negocjowanych indywidualnie. Ceny hostingu zarządzanego i wsparcia w wersji enterprise bywają ustalane per klient.
• Porównania z platformami SaaS. Shopify oraz polskie Shoper i IdoSell to inna rozmowa; drogi wyjścia opisujemy przy migracji z Shopify i migracji z Shopera i IdoSell.
• Stanu na przyszłość. Wersje, wymagania i ceny dostawców sprawdziliśmy 11 sierpnia 2026, a widełki wdrożeń i utrzymania 12 sierpnia 2026. Wracamy do nich raz na kwartał.

Jak podjąć tę decyzję bez zgadywania

Kolejność, która oszczędza najwięcej pieniędzy, jest nudna i sprowadza się do trzech list:

• Lista pierwsza: czego się nie da. Wypisz to, czego obecna platforma nie umie zrobić, a co masz w planie na najbliższe osiemnaście miesięcy.
• Lista druga: ile kosztuje status quo. Policz roczne utrzymanie tego, co już masz: hosting, rozszerzenia, godziny na aktualizacje i obejścia.
• Lista trzecia: ile zmian było w zeszłym roku. Policz, ile razy potrzebowałeś czegoś poza standardem i ile z tego domknęła wtyczka. To najlepszy dostępny wskaźnik kosztu zmiany na następne lata.

Dopiero z tymi dwiema listami porównanie silników ma sens, bo widać, co realnie kupujesz. Ramę do tej rozmowy dają teksty o kryteriach wyboru platformy i o sygnałach, że sklep wyrósł z obecnej, a sam rachunek w TCO w trzy lata.

Medusa jest przy tym tylko fundamentem. To, co z niej budujemy, nazywamy BEAM: platformą, z której klient prowadzi cały swój eCommerce z jednego miejsca, dowożoną w czterech etapach, od Blueprintu przez Engineering po Maintenance & Growth. Jeśli rachunek wychodzi po stronie Medusy, zakres pracy opisujemy przy wdrożeniach Medusy; jeśli po stronie WooCommerce, powiemy to wprost. Szerszy przegląd rodzajów platform jest na stronie platform eCommerce.

Obie platformy kosztują zero na wejściu i obie wystawiają rachunek gdzie indziej. Na WooCommerce płacisz utrzymaniem i kolejnymi wtyczkami za to, że start był tani. Na Medusie płacisz wdrożeniem i zespołem, a w zamian dostajesz kontrolę nad logiką sprzedaży i przewidywalny koszt zmiany. Cała decyzja sprowadza się do tego, którą z tych faktur wolisz dostawać.