Medusa.js – co to jest i kiedy ma sens

Medusa.js wraca w każdej rozmowie o „wyjściu z Shopify” albo „sklepie szytym na miarę”. Zanim podejmiesz decyzję na podstawie samego hasła, warto wiedzieć, czym to naprawdę jest, a czym nie. W skrócie: Medusa to open-source’owy silnik e-commerce napisany w TypeScript, który uruchamiasz na własnym serwerze w środowisku Node.js. To nie jest gotowy sklep „z pudełka” ani wtyczka do WordPressa. To zestaw klocków, z których składasz backend handlowy pod konkretny biznes.

Co to właściwie jest

Trzy słowa opisują Medusę najlepiej: headless, open-source, Node.

Headless znaczy, że backend (logika sklepu: produkty, koszyk, zamówienia, płatności) jest oddzielony od frontu, czyli tego, co widzi klient. Rozmawiają ze sobą przez API. Dzięki temu ten sam backend obsłuży stronę WWW, aplikację, panel handlowca B2B czy kasę w sklepie stacjonarnym.

Open-source, a konkretnie licencja MIT, znaczy, że kod jest darmowy i Twój. Możesz go czytać, zmieniać i używać komercyjnie bez opłat licencyjnych. Nie płacisz abonamentu za samą platformę, nie ma prowizji od obrotu i nikt Ci nie wyłączy sklepu za przekroczenie limitu.

Node znaczy, że to aplikacja serwerowa w JavaScript i TypeScript. Jeśli Twój zespół albo partner techniczny pracuje w tym ekosystemie, wejście jest naturalne.

Aktualna linia to Medusa 2, przepisana wokół modułów. I to jest sedno, więc rozłóżmy architekturę na części.

Architektura: moduły, API, storefront

Medusa dzieli logikę na niezależne moduły. Osobno produkty, osobno koszyki, osobno zamówienia, płatności, realizacja (fulfillment), magazyn i klienci. W dokumentacji mówi się o kilkudziesięciu gotowych modułach. Praktyczny skutek jest taki, że dowolny z nich możesz podmienić albo rozszerzyć, nie wywracając reszty. Chcesz własną logikę cen B2B? Piszesz moduł albo rozszerzasz istniejący, zamiast walczyć z zamkniętym systemem.

Na to nakładają się workflow – sposób na spięcie kroków w jeden proces (na przykład „utwórz zamówienie, zarezerwuj stan, wyślij do ERP, powiadom magazyn”) z obsługą błędów i wycofaniem, gdy któryś krok padnie.

Całość wystawia dwa API: Admin (dla panelu i integracji wewnętrznych) oraz Store (dla frontu i aplikacji). Medusa dostarcza gotowy panel administracyjny, ale front budujesz osobno. Najczęściej jest to aplikacja w Next.js – Medusa daje startowy szablon storefrontu, który traktujesz jak punkt wyjścia, nie jak gotowiec. Jeśli chcesz zobaczyć, jak taki złożony sklep wygląda w praktyce, mamy pokazowe wdrożenie pod demo.koda.plus.

Jeśli słowo „headless” nadal brzmi mgliście, rozpisaliśmy je po ludzku w osobnym wpisie: headless e-commerce po ludzku.

Co dostajesz gotowe, a co budujesz

Łatwo pomylić „open-source” z „gotowe za darmo”, więc rozdzielmy to jasno. Z pudełka masz działający silnik handlowy: produkty z wariantami, koszyk, zamówienia, obsługę wielu regionów i walut, podatki, promocje, zarządzanie magazynem i gotowy panel administracyjny. To solidny fundament, na którym stoi cała reszta.

Sam budujesz trzy rzeczy: front (wygląd i doświadczenie klienta), integracje (płatności, wysyłka, ERP, feedy) oraz nietypową logikę biznesową, której akurat potrzebujesz. Medusa daje pod to gotowe punkty zaczepienia. Płatności i realizację podpina się przez moduły providerów, a własne reguły dokładasz jako moduły albo workflow, nie przez łatanie rdzenia. To ma znaczenie przy aktualizacjach: Twój kod żyje obok silnika, a nie w jego środku, więc podniesienie wersji nie każe przepisywać wszystkiego od nowa.

Czym różni się od gotowego SaaS

Najprościej zestawić Medusę z platformą SaaS w kilku wymiarach:

Wymiar	SaaS (np. Shopify)	Medusa.js
Model	abonament plus prowizje	open-source, self-hosted
Kod i dane	u dostawcy	u Ciebie
Checkout	ograniczona ingerencja	pełna kontrola
Start	szybki	wolniejszy, wymaga zespołu
Utrzymanie	po stronie dostawcy	po Twojej stronie
Reguły biznesowe	w ramach tego, co daje platforma	dowolne

Na SaaS płacisz za to, że ktoś utrzymuje infrastrukturę i aktualizacje, a Ty dostajesz sklep w kilka dni. Ceną są ograniczenia: checkout jest w dużej mierze zamknięty, nietypowe reguły trzeba obchodzić, a dane i logika żyją u dostawcy. Medusa odwraca ten układ – zdejmuje ograniczenia, ale utrzymanie i rozwój lądują po Twojej stronie. Bardziej rozłożyste porównanie z konkretną platformą znajdziesz w tekście Medusa.js czy Shopify.

Jest jeszcze wymiar, który trudno wycenić, dopóki nie uderzy: uzależnienie od dostawcy. Na zamkniętej platformie poruszasz się w tempie jej mapy drogowej. Gdy dostawca zmieni cennik, wycofa funkcję albo przestawi priorytety, dostosowujesz się Ty, nie on. Przy otwartym kodzie to ryzyko maleje, bo najgorszy scenariusz to samodzielne utrzymanie tego, co już masz. Dla firmy, która buduje na lata, sama ta przewidywalność bywa argumentem.

Dla kogo Medusa ma sens

Uczciwie: Medusa nie jest dla każdego. Ma sens, gdy:

• Masz nietypowe reguły biznesowe – cenniki B2B per kontrahent, limity kupieckie, jednostki sprzedaży, złożone rabaty. Rzeczy, które w zamkniętym checkoucie są bólem.
• Integrujesz się z ERP, WMS i feedami hurtowni, a sklep ma być częścią większego systemu, nie samotną wyspą.
• Sprzedajesz w wielu kanałach z jednego źródła: web, aplikacja, marketplace, B2B i B2C obok siebie.
• Zależy Ci na własności kodu i danych, bo planujesz długo i nie chcesz być zakładnikiem cudzej mapy drogowej.
• Masz zespół albo partnera technicznego, który to utrzyma.

Dla kogo Medusa NIE ma sensu

Równie uczciwie – bywają sytuacje, w których Medusę odradzamy:

• Prosty sklep B2C, który ma ruszyć za dwa tygodnie. Gotowy SaaS zrobi to taniej i szybciej.
• Brak zaplecza technicznego i brak budżetu na partnera. Medusa to backend, który ktoś musi prowadzić. Bez tego zamienia się w kłopot.
• Sklep, który nigdy nie wyjdzie poza standard. Jeśli wszystko, czego potrzebujesz, mieści się w tym, co daje pudełkowa platforma, płacenie za elastyczność, której nie wykorzystasz, nie ma sensu.

Wybór narzędzia to nie kwestia mody. Jeśli Twój przypadek jest prosty, prostota jest zaletą, nie wstydem.

Koszt posiadania

Brak opłaty licencyjnej nie znaczy „za darmo”. Na całkowity koszt składają się trzy pozycje:

• Wdrożenie – zbudowanie backendu i frontu pod Twój przypadek. To główny koszt na starcie.
• Hosting – aplikacja Node plus baza PostgreSQL i Redis. Realny, comiesięczny wydatek, choć zwykle daleko od abonamentów w segmencie enterprise SaaS.
• Utrzymanie i rozwój – aktualizacje, nowe funkcje, integracje. Przy własnym backendzie to ciągła pozycja, nie jednorazowa.

Jeśli nie chcesz zarządzać infrastrukturą samodzielnie, twórcy Medusy oferują też hosting zarządzany (Medusa Cloud). To kompromis: część wygody SaaS przy zachowaniu otwartego kodu.

Warto policzyć też koszt alternatywny w drugą stronę. Na SaaS z pozoru niski abonament potrafi urosnąć przez prowizje od obrotu, dopłaty za aplikacje z marketplace i wyższy plan wymuszony jedną funkcją. Przy dużym obrocie i rozbudowanych integracjach bywa, że model „płacę za pracę i hosting” wychodzi taniej niż „płacę procent od każdej sprzedaży”. To nie jest reguła, tylko rachunek, który warto zrobić na własnych liczbach, zanim wybierzesz model.

W praktyce Medusa opłaca się tam, gdzie elastyczność zwraca się w procesach: mniej ręcznej roboty, mniej obejść, sklep dopasowany do sposobu, w jaki naprawdę sprzedajesz. Tam, gdzie tej elastyczności nie wykorzystasz, taniej wyjdzie SaaS.

Budujemy sklepy i hurtownie na Medusie od strony całego ekosystemu – backend, front, integracje i procesy. Jeśli zastanawiasz się, czy to droga dla Ciebie, zobacz sklepy na Medusa.js albo po prostu opisz nam swój przypadek.