Często sprzedają kilkaset prostych produktów z magazynu, prowadzonego na Comarchu i tyle. I nie ma w tym nic złego po prostu taki mają biznes.
Ta sama osoba, która nie wpadłaby na pomysł, żeby projektować własny system magazynowy, chce zaprojektować indywidualny sklep. Bo sklep to wizytówka. Bo konkurencja ma. Bo agencja powiedziała, że na Shoperze nie da się zrobić „wszystkiego po swojemu".
Zanim pójdziemy dalej, dwie rzeczy o mnie, bo to nie ma być reklama konkretnego rozwiązania.
Jestem partnerem Shopera. Sprzedaję wdrożenia na tej platformie i mam w ich App Store własną aplikację i kolejne w fazie testów. Jednocześnie buduję sklepy na Medusie i Next.js, a sklep dla marki którą pomagam współtworzyć, Folk Club, stoi na Medusie, nie na Shoperze, mimo że na Shoperze zarobiłbym prowizję od samego siebie. Zarabiam więc na obu odpowiedziach. Ma to jedną zaletę: nie mam jednoznacznego interesu w tym, żebyś wybrał którąkolwiek. Mam interes w tym, żebyś nie wrócił za rok z pretensjami, po skorzystaniu z moich usług.
W tym tekście postaram się poprowadzić cię do wyboru. Zamieńmy pytanie „Shoper czy dedyk" na inne. Po drodze dostaniesz liczby z badań, mój własny rachunek za pół roku budowy sklepu i listę przypadków, w których moja teza nie działa.
Cztery rzeczy, które nazywasz dedykiem
Słowo „dedyk" w ustach klienta znaczy zwykle „wszystko, co nie jest Shoperem", lub ogolniej SaaS’em . To tak, jakby „samochód" znaczyło „wszystko, co nie jest rowerem". Zanim zaczniemy porównywać, trzeba rozdzielić cztery różne rzeczy, bo mają cztery różne bilanse.
Pierwsza to SaaS: Shoper, IdoSell, Shopify. Wynajmujesz gotowy sklep razem z serwerem, bezpieczeństwem, aktualizacjami i integracjami. Płacisz abonament. Nie masz dostępu do silnika.
Druga to monolit open source: WooCommerce, PrestaShop, Magento. Silnik jest cudzy i darmowy, wtyczki są cudze i częściowo płatne, a serwer, aktualizacje i bezpieczeństwo są twoje. Klient nazywa to dedykiem, bo agencja postawiła to „specjalnie dla niego". Nie jest to dedyk. To jest Shoper, za który odpowiadasz sam.
Trzecia to headless open source: Medusa, Saleor. Silnik sklepu utrzymuje społeczność, ale front, czyli to, co widzi klient, piszesz od zera. Na tym buduję. Dwa osobne systemy, dwa osobne wdrożenia, pełna kontrola nad każdym elementem i pełna odpowiedzialność za każdy.
Czwarta to kod od zera. Rzadkie, drogie i w 2026 roku prawie zawsze błąd, bo silniki open source rozwiązały już problemy, które musiałbyś rozwiązać sam.
Większość dyskusji „Shoper czy dedyk" miesza drugą z trzecią i przez to nie ma sensu. Rachunek za Woo i rachunek za Medusę to są dwie różne sytuacje, a Ty widzisz tylko to, że obie są droższe niż abonament.
Lokal w galerii
Nikt, kto otwiera sklep z butami, nie buduje własnej galerii handlowej. Wynajmuje lokal. Dostaje ściany, ogrzewanie, ochronę, sprzątanie, parking i ruch ludzi, którzy i tak tam przychodzą. Podpisuje regulamin galerii, w którym stoi, o której otwiera, jak może wyglądać witryna i że ściany nośnej nie ruszy. I nikt nie uważa, że jest przez to mniej poważnym przedsiębiorcą. Lokal nie jest jego przewagą. Lokal jest kosztem prowadzenia sprzedaży, a przewaga leży na półkach.
Jeśli twój sklep robi dokładnie to, co lokal w galerii, czyli wystawia produkt, przyjmuje pieniądze i wydaje towar, to jest lokalem. I wtedy Shoper.
Ile ten lokal kosztuje? Standard to 3 249 zł netto rocznie po pierwszym roku, Premium 7 849 zł. Za to dostajesz hosting, bezpieczeństwo, aktualizacje bez pytania, integracje z InPost, Allegro, Autopay i księgowością klikane w panelu, a nie pisane. Na tej platformie w 2025 roku złożono zamówienia za 11,8 mld zł w samych sklepach i 21 mld zł licząc marketplace'y i inne kanały (raport Shoper S.A. za 2025, dane szacunkowe ze spółki giełdowej, nie z folderu reklamowego). Piszę to nie po to, żeby powiedzieć, że Shoper jest fajny, tylko żeby pokazać skalę. Każdy błąd w ich checkoucie kosztuje ich samych miliony, więc go poprawiają. Twój własny checkout poprawiasz ty, w wolnej chwili.
Uczciwie: GMV mówi o skali galerii, nie o tym, czy lokale w niej zarabiają. Miliardy obrotu to suma dziesiątek tysięcy sklepów, z których część nie sprzedaje nic. Skala dowodzi, że budynek stoi pod obciążeniem. Nie dowodzi, że do twojego lokalu ktoś wejdzie.
Jak przebudować galerię?
Wiem, gdzie Shoper się kończy, bo w to uderzyłem. Aplikacja 2+1, którą napisałem do ich App Store, powstała z prostego powodu: natywne promocje Shopera nie umieją zrobić mechaniki „trzeci produkt gratis" tak, jak chcą jej sklepy odzieżowe. Przy pisaniu tej aplikacji zderzyłem się z trzema ograniczeniami i przy każdym dam ci werdykt, bo to jest informacja, która pokazuje gdzie można zderzyć się ze ścianą.
Metafield, czyli miejsce, gdzie aplikacja może zapisać własne dane przy produkcie, ma limit 256 znaków na wartość. Konfiguracja promocji się w tym nie mieści. Obejście: dzielenie JSON-a na kilka pól z minimalnymi kluczami.
Werdykt: obejście czyste, ale wymaga myślenia o strukturze danych od pierwszego dnia.
Storefront, czyli API po stronie sklepu, nie ma dostępu do danych produktu z poziomu koszyka. Obejście: przenieść logikę na serwer i renderować tam.
Werdykt: obejście brzydkie, bo kosztuje dodatkową warstwę, której w normalnym sklepie by nie było.
Oficjalne SDK jest nieaktualne. Obejście: pisać bezpośrednio do REST API.
Werdykt: obejście czyste, ale znaczy, że dokumentacja, którą czytasz, może kłamać.
To są ściany działowe. Da się je przestawić, jeśli wiesz jak i ile to kosztuje. Ale jest jedna ściana nośna, której nie ruszysz niczym: logika, która musi wiedzieć o czymś spoza sklepu. O kolejce produkcyjnej, o stanie maszyny, o tym, ile metrów tkaniny zostało na rolce. Shoper może to dostać przez API, ale nie umie na tym reagować w czasie rzeczywistym w koszyku.
Lokal w galerii nie ma hali produkcyjnej na zapleczu, bo nie do tego służy.
Warsztat
Folk Club sprzedaje góralskie stroje i odzież inspirowaną folklorem. Część produktów jest gotowa, część szyta na zamówienie, a czas realizacji zależy od tego, ile zamówień jest już w kolejce i co konkretnie ktoś wybrał w konfiguratorze. Klient, który zamawia we wtorek, dostaje inny termin niż ten, który zamawia w czwartek, bo we wtorek kolejka była krótsza. Sklep liczy to per produkt, na bieżąco, z danych z produkcji.
Tego Shoper nie zrobi. Nie dlatego, że jest słaby, tylko dlatego, że to nie jest funkcja sklepu. To jest funkcja warsztatu.
Budowa zajęła pół roku. Dotychczasowy koszt to około 40 tysięcy złotych. Za 40 tysięcy kupiłbym dwanaście lat licencji Shoper Standard z wdrożeniem. Grubo.
Tu biję się w pierś, bo część tych pieniędzy poszła nie na sklep, tylko na testy i projektowanie rozwiązań. Medusa ma miejsca, w których zapytanie do bazy zwraca po cichu same identyfikatory, jeśli pomylisz ścieżkę do pola, i nie mówi ci, że coś jest nie tak. Ma limit, przy którym ceny obliczają się poprawnie dla czterdziestu produktów, a powyżej zaczynają znikać, o czym dowiadujesz się z reklamacji. Integrację z Przelewy24 pisałem sam, bo oficjalnej gotowej nie ma. Pierwsze buildy zabijały serwer z braku pamięci, zanim przeniosłem je na osobną maszynę.
I mimo tego nie żałuję, bo to nie był tylko koszt sklepu. Płaciłem za to, żeby sklep wiedział, co dzieje się w pracowni. Konfigurator i kolejka produkcyjna są odzwierciedleniem modelu biznesowego, który jest taki nie inny i takim na najbliższe lata zostanie. Sposób kupowania jest częścią produktu. To jest cała różnica.
“Sklep trzeba budować tylko wtedy, gdy przewaga konkurencyjna siedzi w mechanice sprzedaży. Jeśli siedzi w produkcie, cenie albo marketingu, sklep wynajmij i pieniądze włóż tam, gdzie ta przewaga jest.”
Przeczytaj to jeszcze raz, bo to jest cały artykuł w jednym zdaniu. Reszta to dowody i wyjątki.
Rachunek, którego klient nie widzi
Klient widzi cenę wdrożenia. Nie widzi rachunku za pięć lat. A rachunek za pięć lat jest tym, co decyduje.
Zacznijmy od monolitu, bo tu dane są najtwardsze. Patchstack, firma, która żyje z łatania WordPressa, policzyła w raporcie za 2025 rok 11 334 nowe luki bezpieczeństwa w ekosystemie WordPress, o 42% więcej niż rok wcześniej. 91% z nich siedziało we wtyczkach, nie w rdzeniu. 46% nie było załatanych w dniu publicznego ujawnienia. Mediana czasu od ujawnienia do pierwszego ataku: pięć godzin.
Czytaj to pod włos. Patchstack sprzedaje bezpieczeństwo, więc ma interes w dużych liczbach, a część branży WordPressowej publicznie kwestionuje ich metodologię liczenia. Nie wiem, czy to 11 tysięcy, czy 7. Wiem, że kierunek jest ten sam od lat i że sklep na Woo z trzydziestoma wtyczkami to trzydziestu dostawców kodu, których nie znasz, z których połowa nie łata na czas, i każdy z nich ma dostęp do twojej bazy klientów. Nie płacisz za to abonamentu. Płacisz za to w przedświątecznym piku, gdy nagle sklep leży.
Headless ma inny rachunek. Nie ma wtyczek od anonimów, ale ma dwa osobne systemy, które trzeba wdrażać, aktualizować i pilnować. Integracje z polskim rynkiem piszesz sam: Przelewy24, InPost, Allegro, faktury. W Shoperze to jest checkbox. W Medusie to jest tydzień. I potrzebujesz człowieka, który to wszystko zna. Jeśli ten człowiek jest jeden, nie masz sklepu. Masz zakładnika.
Ile to kosztuje w utrzymaniu? Nie mam badania, mam własne projekty, więc powiem tak: w żadnym z nich nie było to mniej niż jeden dzień pracy programisty w miesiącu, a w pierwszym roku dwa. Policz to po swojej stawce i porównaj z 3 249 zł rocznie. Pisałem już w tekście o odwróconej proporcji, że każda złotówka włożona w rzecz, która nie jest przewagą, jest złotówką wyjętą z reklamy. Utrzymanie własnego kodu, którego nikt nie widzi, jest tego najczystszym przykładem.
Checkout, którego nie napisałeś
Baymard Institute śledzi porzucanie koszyków od trzynastu lat i po zsumowaniu 49 niezależnych badań podaje średnią 70,19%. Siedmiu na dziesięciu ludzi, którzy włożyli coś do koszyka, wychodzi bez płacenia. Prawie jeden na pięciu robi to z powodu zbyt długiego albo skomplikowanego checkoutu, a przeciętny checkout ma 5,1 kroku i 11,3 pola.
Sceptycyzm obowiązkowy: to dane głównie amerykańskie, z ankiet, w których ludzie sami mówią, dlaczego wyszli, a ludzie w ankietach kłamią, zwłaszcza sobie. Polska ma BLIK i paczkomaty, więc rozkład powodów u nas wygląda inaczej. Ale rząd wielkości się nie zmienia i mechanizm też nie: każde zbędne pole to procent klientów mniej.
Dlaczego to ważne przy wyborze platformy? Bo na Shoperze checkout jest ich i testują go na dziesiątkach tysięcy sklepów. Na własnym sklepie checkout jest twój i testujesz go na sobie. Za każde pole w Folk Clubie odpowiadam osobiście i nie mam za sobą dziesięciu tysięcy sklepów, które sprawdziły, czy działa. Nie znaczy to, że checkout Shopera jest bez wad, bo da się go ustawić źle i widziałem to nieraz. Znaczy to, że punkt startu jest inny.
To samo z szybkością. Deloitte i Google w badaniu Milliseconds Make Millions z 2020 roku przeanalizowali 30 milionów sesji mobilnych w 37 markach i policzyli, że poprawa szybkości o 0,1 sekundy dała w handlu o 8,4% więcej konwersji i o 9,2% wyższą wartość koszyka. Pod włos: to obserwacja, nie eksperyment, a szybsze sklepy to często po prostu lepiej prowadzone sklepy, więc część efektu to korelacja. Ale 0,1 sekundy to mrugnięcie i nawet połowa tego efektu jest warta pieniędzy. Shoper Premium ma cache, który oddaje stronę z pamięci serwera, zanim w ogóle ruszy PHP. Na własnym hostingu tę szybkość musisz sobie zbudować, a potem utrzymać.
Ale SaaS to klatka
Ten argument jest prawdziwy częściej, niż wdrożeniowcy lubią przyznawać.
Tak, jesteś zależny od dostawcy. W tym roku Shoper połączył się z cyber_Folks i jeśli to zmieni ceny, politykę albo tempo rozwoju, nie masz nic do gadania. Eksport danych jest możliwy, ale sklep nie przenosi się jak paczka, bo szablon, integracje i konfiguracja zostają. Abonament może wzrosnąć. Funkcja, na której opierasz sprzedaż, może zniknąć w aktualizacji. To wszystko prawda.
Odpowiedź brzmi tak samo jak przy lokalu w galerii: on też jest cudzy, galeria może podnieść czynsz, zmienić regulamin albo sprzedać cały budynek nowemu właścicielowi, a ty dowiesz się z pisma. Pytanie nie brzmi, czy zależność istnieje, tylko czy jej cena jest niższa niż koszt niezależności. Dla sklepu, który jest lokalem, jest niższa o rząd wielkości, bo alternatywą jest własny budynek z własnym dachem do łatania. Dla warsztatu nie, bo halę i tak musisz utrzymać sam, więc czynsz w galerii nic ci nie oszczędza, a odbiera ci prawo do przestawienia ściany.
Kiedy się mylę
Zanim ktoś złapie mnie za słowo, sam podam przypadki, w których teza „prosty produkt to Shoper" nie działa.
Sprzedaż B2B z indywidualnymi cennikami dla kontrahentów, gdzie każdy klient widzi inne ceny i inne warunki dostawy, skomplikowana gospodarka magazynowa, własna produkcja. Produkt może być prosty jak śruba, ale mechanika sprzedaży jest złożona i Shoper się na niej wywraca. To jest warsztat, choć wygląda jak galeria.
Sklep z asortymentem powyżej 50 tysięcy produktów albo z wieloma magazynami, gdzie integracja z ERP nie jest dodatkiem, tylko sercem operacji. Shoper Premium to obsłuży, ale sprawdź, czy sposób, w jaki twój ERP myśli o stanach, da się przetłumaczyć na to, jak myśli o nich Shoper. Często nie.
Eksport na kilka rynków z osobnymi domenami i osobną logiką podatkową. Da się, ale zanim uwierzysz mi albo komukolwiek na słowo, przetestuj to na koncie trial z prawdziwym asortymentem.
I w drugą stronę. Miałem klienta, który chciał sklep „w pełni po swojemu" dla dwustu produktów. Dostał go od kogoś innego, bo ja odmówiłem. Rok później płacił co miesiąc za utrzymanie i poprawki sklepu, który robił dokładnie to, co Shoper robi w abonamencie, tylko wolniej i z przerwami. Nie kupił warsztatu. Kupił własną galerię, w której miał tylko jeden swój lokal, a utrzymywał, cały obiekt.
Jest jeszcze przypadek, w którym headless jest błędem mimo złożonej mechaniki: kiedy nie ma kto tego utrzymać. Jeśli budujesz warsztat, a jedyny człowiek, który go zna, to freelancer z Upworka, to za dwa lata masz kod, którego nikt nie tknie. Wtedy lepsza jest brzydka aplikacja na Shoperze niż piękna Medusa bez opiekuna.
Test na jedno popołudnie
Pięć pytań. Odpowiadaj uczciwie, bo matkę oszukasz, ojca oszukasz, ale rachunku za utrzymanie nie oszukasz.
- Czy klient kupuje u ciebie wyłącznie przez to co kupuje, czy też przez to, jak kupuje? Jeśli „co", to galeria.
- Czy istnieje logika sprzedaży, której nie da się opisać w polach produktu? Cena zależna od kolejki, konfiguracja wielopoziomowa, termin z produkcji, warunki per kontrahent. Jeśli tak, opisz tę logikę jednym zdaniem. Jeśli nie umiesz, nie istnieje.
- Ile kosztuje obejście tej logiki aplikacją na Shoperze i czy to mniej niż trzy lata różnicy w utrzymaniu? Liczba, nie odczucie.
- Kto naprawi sklep w piątek o 22? Nazwisko. Jeśli nie ma nazwiska, nie ma warsztatu.
- Czy twoja marża udźwignie dzień programisty miesięcznie przez pięć lat, zanim sklep zacznie na siebie zarabiać?
Werdykt: Jeśli fizycznie zmieściłbyś sprzedaż w lokalu galerii, to Shoper i nie wracaj do tego tematu przez trzy lata.
Jedno zdanie w pytaniu drugim plus nazwisko w czwartym to warsztat, i budujesz go z otwartymi oczami. Wszystko pomiędzy to Shoper plus aplikacja, i tu powiem wprost: to jest to, co sprzedaję, więc policz sam, czy obejście nie jest droższe niż przyznanie, że masz warsztat.
Zamiast pytania o narzędzie
„Shoper czy dedyk" to pytanie o narzędzie. Narzędzia się nie wybiera, narzędzie wynika z potrzeby. Właściwe pytanie brzmi: Gdyby ten sklep był fizyczny, to czy potrzebowałbyś lokalu w galerii, czy wybudować własny budynek? Czy sklep ma po prostu przyjąć pieniądze, czy ma robić rzeczy, których żaden gotowy sklep wiedzieć nie może?
Lokal się wynajmuje. Warsztat się buduje i buduje się go tylko wtedy, gdy masz w nim co robić.
