Medusa czy Saleor - porównanie platform sprzedaży internetowej 2026

Medusa i Saleor rozwiązują podobny problem: oddzielają silnik sprzedaży od doświadczenia klienta. Różnią się jednak filozofią. Medusa v2 przypomina zestaw modułów sprzedażowych dla zespołów JavaScript/TypeScript, które chcą budować własne procesy, reguły cenowe i połączenia z systemami firmowymi. Saleor jest bliżej zaplecza sprzedażowego z GraphQL w centrum, dobrego dla organizacji, które chcą jednego spójnego sposobu komunikacji z platformą i mają gotowość utrzymania Python/Django.

Dla dyrektora technicznego prawdziwe pytanie nie brzmi: “która platforma ma dłuższą listę funkcji?”. Brzmi: “który wybór będzie tańszy do utrzymania przez trzy lata, szybszy dla naszego zespołu i mniej ryzykowny przy systemie finansowo-magazynowym, bazie produktów, magazynie, płatnościach oraz aplikacji mobilnej?”.

GMI najczęściej rekomenduje Medusa przy sprzedaży firmowej, sprzedaży wielu dostawców, niestandardowej ścieżce zakupu, połączeniach z systemem finansowo-magazynowym i planie: sklep internetowy + aplikacja React Native. Saleor warto poważnie rozważyć przy prostszej sprzedaży konsumenckiej, mocnym katalogu wariantów, strategicznym GraphQL i zespole, który już umie utrzymać Python/Django w produkcji.

Całkowity koszt elastycznej platformy sprzedażowej rzadko rozbija się o “cenę platformy” w pierwszym miesiącu. Prawdziwe koszty siedzą w rozszerzeniach, migracji danych, połączeniach z systemami firmowymi, utrzymaniu wersji, testach regresji i czasie zespołu, który po starcie musi rozwijać plan produktu.

Przy sprzedaży firmowej i wielu połączeniach z systemami Medusa zwykle wygrywa w perspektywie trzech lat: nie ma klasycznej prowizji platformy abonamentowej od wartości sprzedaży, jeden zestaw JavaScript/TypeScript obejmuje zaplecze, sklep i kanał mobilny, łatwiej znaleźć programistów TypeScript, a zespół rzadziej przełącza się między różnymi światami technologicznymi.

Saleor może być szybszy w pierwszej wersji sprzedaży konsumenckiej dla branż mody, urody lub stylu życia, gdy katalog jest dobrze opisany, GraphQL jest standardem, a zespół ma doświadczenie z Python/Django. Koszt rośnie, kiedy projekt zaczyna wymagać hurtowych wyjątków: limitów kredytowych, akceptacji zamówień, częściowej realizacji wysyłek, cen kontraktowych i niestandardowego przepływu danych z systemu finansowo-magazynowego.

Widełki GMI: pierwsza wersja Medusa dla sprzedaży konsumenckiej lub firmowej to zwykle EUR 45 000 - 90 000; złożona sprzedaż firmowa z systemem finansowo-magazynowym i migracją danych to EUR 55 000 - 120 000. Pierwsza wersja Saleor dla sprzedaży konsumenckiej mieści się zwykle w podobnym zakresie, ale niestandardowa sprzedaż firmowa wymaga osobnej wyceny. Stałą cenę podajemy dopiero po rozpoznaniu procesu, danych i połączeń z systemami, bo bez mapy zależności każda liczba jest zgadywaniem.

W sprzedaży firmowej nie wystarczy mieć produkty, koszyk i ścieżkę zakupu. Potrzebujesz cenników kontraktowych, grup klientów, limitów kredytowych, ról po stronie kupującego, ponawiania zamówień, faktur, częściowej realizacji wysyłek i wyjątków, które dziś żyją w systemie finansowo-magazynowym albo w głowach handlowców.

Medusa daje dobry punkt startu, bo jej model modułów i procesów naturalnie prowadzi do rozszerzania obszaru sprzedaży w kodzie klienta. To jest mocne przy sprzedaży wielu dostawców i sprzedaży firmowej, gdzie jeden sprzedawca ma inne reguły realizacji zamówień, a jeden klient może mieć kilka poziomów cen.

Saleor również może obsłużyć sprzedaż firmową, zwłaszcza gdy zespół dobrze projektuje schemat GraphQL, aplikacje i komunikaty między systemami. Ryzyko pojawia się wtedy, gdy każdy wyjątek hurtowy staje się osobnym rozszerzeniem wokół platformy, a po stronie firmy nie ma osoby odpowiedzialnej za spójność architektury.

Medusa dobrze współpracuje z architekturą Next.js + React Native, bo zespół może utrzymać jeden główny język i jeden sposób myślenia o domenie sprzedaży. Przy aplikacji sklepowej, panelu handlowca albo aplikacji lojalnościowej zmniejsza to koszt utrzymania zasad komunikacji między systemami.

Saleor GraphQL daje czystą umowę dla wielu aplikacji i miejsc styku z klientem. To mocne w organizacjach, które mają już standardy zarządzania schematem danych, Apollo/urql, monitorowanie zapytań i proces wersjonowania GraphQL. Bez tych praktyk GraphQL potrafi przenieść chaos z zaplecza do aplikacji klienckich.

Utrzymanie: obie platformy wymagają aktualizacji, testów regresji, monitorowania ścieżki zakupu, alertów połączeń z systemami i planu wycofania zmian przed szczytami sprzedażowymi. Otwarty kod nie znaczy “bez kosztu”; znaczy “bez zamknięcia u dostawcy, ale z odpowiedzialnością za własną architekturę”.

Przykład GMI ze sprzedaży mobilnej: SFD ma ponad 100 000 pobrań i ocenę 4.9 w App Store na aplikacji React Native ze wspólnym zapleczem sprzedażowym. To jest argument za projektowaniem kanałów razem, nie za dokładaniem aplikacji po roku jako osobnego projektu bez wspólnego modelu danych.

W GMI nie zaczynamy od sprzedawania Medusa od progu. Zaczynamy od mapy operacyjnej: kanały, marża, koszyk, reguły cenowe, połączenia z systemami, dane, zespoły i termin. Dopiero potem rekomendujemy Medusa, Saleor, platformę abonamentową albo etap przejściowy.

Jeżeli wybór wskazuje Medusa, projektujemy architekturę Next.js/React Native/Medusa z jasno opisanymi granicami modułów i połączeń z systemami. Jeżeli wskazuje Saleor, dokumentujemy zasady zarządzania GraphQL, aplikacjami, komunikatami między systemami i odpowiedzialnością za Python/Django. W obu przypadkach celem jest stała cena po rozpoznaniu zakresu i ryzyk, nie otwarty rachunek za niepewność.