Decyzja o wyborze platformy e-commerce prawie zawsze trafia w to samo miejsce: na biurko działu IT albo zewnętrznego dostawcy technicznego. Pytanie „na czym postawić sklep" brzmi technicznie, więc naturalnie deleguje się je technikom. To jeden z najkosztowniejszych błędów kategoryzacji, jakie widzimy w mid-market.
„Która platforma" to pytanie pochodne. Wynika z tego, jaki biznes budujesz na najbliższe pięć lat: B2B czy D2C, jeden rynek czy ekspansja, katalog na dwa tysiące czy sześćdziesiąt tysięcy SKU, zespół marketingowy czy techniczny. IT odpowiada na to pytanie inaczej, niż odpowiedziałby biznes — i robi to systematycznie, nie przypadkowo. Poniżej pokazujemy, dlaczego tak się dzieje, trzy zanonimizowane przypadki, w których IT zdecydowało za biznes, oraz prostą ramę, która ustawia tę decyzję we właściwej kolejności.
Dlaczego ta decyzja w ogóle trafia do IT
Wybór platformy wygląda jak problem inżynierski. Trzeba porównać stacki, API, wydajność, model hostingu. Zarząd, który nie czuje się pewnie w tych tematach, chętnie oddaje decyzję ludziom, którzy się w nich czują. Problem w tym, że oddaje w ten sposób również wagi — a to wagi, nie sama lista kryteriów, przesądzają o wyniku.
Najdroższa inwestycja w e-commerce to sklep, który po roku trzeba przepisywać, bo wybrana architektura nie wytrzymała wzrostu biznesu. Platformę wybiera się na 5–7 lat życia produktu, nie na najbliższy launch. A horyzont, na którym najlepiej ocenia się tę decyzję — model przychodowy, roadmapa, dopasowanie do zespołu — jest z definicji biznesowy, nie techniczny.
Co optymalizuje IT (i dlaczego to nie to samo co biznes)
Dobry dział IT nie wybiera źle ze złej woli. Wybiera to, co dział IT ceni — a ceni rzeczy realne i sensowne ze swojej perspektywy:
- Kontrolę i elastyczność. Pełny dostęp do kodu, brak ograniczeń SaaS, możliwość zbudowania czegokolwiek. Open source na własnym serwerze bije zamknięty ekosystem.
- Brak vendor lock-in i opłat licencyjnych. Licencja 2200 USD miesięcznie plus procent od obrotu wygląda dla inżyniera jak marnotrawstwo, skoro „to samo" można postawić na darmowym silniku.
- Znajomy stack. Zespół, który od lat pracuje w WordPressie albo w Symfony, naturalnie ciągnie w stronę tego, co już umie utrzymać.
- Techniczną elegancję. Headless, czysta architektura, nowoczesny front — rzeczy, które dobrze wyglądają w code review.
Każda z tych wartości jest uzasadniona. Żadna nie jest tożsama z tym, co decyduje o przychodzie: czasem wejścia na rynek, kosztem posiadania w trzyletnim horyzoncie i tym, kto realnie obsługuje sklep na co dzień.
W naszym zestawieniu platform oceniamy każdy silnik w sześciu wymiarach: panel administratora, konfiguracja, możliwości rozwoju, wydajność, SEO i bezpieczeństwo. IT instynktownie przywiązuje największą wagę do „możliwości rozwoju", bo to jego świat. Biznes powinien najmocniej ważyć „panel administratora", bo to on rozstrzyga, czy marketing sam odpali kampanię, czy na każdą zmianę będzie zakładał zgłoszenie do programisty. Ten jeden przesunięty ciężar wystarczy, żeby wynik wyszedł inny.
Trzy przypadki, w których IT zdecydowało za biznes
Poniższe historie to złożone, zanonimizowane archetypy, nie konkretni klienci — a numery obrotów są ilustracyjne. Każda z nich to jednak wzorzec, który w mid-market powtarza się regularnie.
Przypadek 1: nadmierna inżynieria dla prostego D2C
Producent kosmetyków naturalnych, około 12 mln zł obrotu rocznie, sprzedaż D2C, prosty katalog do dwóch tysięcy SKU, plany ekspansji na rynki DACH. IT rekomenduje custom na Symfony/Sylius: „pełna kontrola, zero lock-inu, zbudujemy dokładnie to, czego chcemy".
Rzeczywistość biznesu była inna. To marka marketingowa, nie technologiczna — bez wewnętrznego zespołu PHP, za to z ambicją szybkiego wejścia do Niemiec i Austrii. Sylius potrafi wszystko, ale customizacja zajmuje czas: wdrożenie na tym silniku to typowo 16–22 tygodnie, podczas gdy Shopify Plus dowozi produktywny sklep w 8–14. Panel Sylius jest zaprojektowany dla programistów; panel Shopify — dla marketerów. Efekt: każda kampania i każda zmiana na stronie wymagała programisty, a multi-currency i multi-language, które w Shopify Plus są gotowe, trzeba było dobudowywać. Marka straciła sezony, w których powinna już sprzedawać w DACH.
IT zoptymalizowało kontrolę. Biznes potrzebował czasu wejścia na rynek i samodzielności marketingu.
Przypadek 2: sufit SaaS pod ciężarem B2B
Dystrybutor części przemysłowych, około 40 mln zł obrotu, ponad sześćdziesiąt tysięcy SKU, indywidualne cenniki per kontrahent, kredyt kupiecki, katalog napędzany z ERP. Tym razem IT wybrało odwrotnie: Shopify Plus, „bo to SaaS, nie musimy utrzymywać infrastruktury i szybko ruszymy".
Shopify Plus jest znakomity dla D2C, ale B2B to nie jest jego mocna strona. Indywidualne cenniki, limity kredytowe i logika kontraktowa wymagają tam aplikacji i customu — rzeczy, które Sylius ma natywnie. Do tego katalog powyżej pięćdziesięciu tysięcy SKU ociera się o granice komfortu SaaS. Każda reguła B2B stawała się kolejną płatną aplikacją, a rachunek się sumował: 2200 USD miesięcznie licencji, do tego stack aplikacji (dla mid-market typowo 200–800 USD) i prowizje od transakcji. Realny koszt utrzymania sklepu z obrotem rzędu 20 mln zł potrafi wynieść 15–25 tys. zł miesięcznie — a model, który miał być „tańszy, bo bez serwerów", okazał się droższy i kruchy w rdzeniu.
IT zoptymalizowało prostotę operacyjną dla siebie. Biznes był z gruntu B2B i potrzebował platformy, która traktuje cenniki i kredyt kupiecki jako standard, a nie jako wyjątek.
Przypadek 3: znajomy stack zamiast roadmapy
Producent mebli, około 15 mln zł obrotu rocznie, rosnący katalog z konfiguracją produktu (wymiary, tkaniny, warianty), plany wejścia na marketplace'y. IT proponuje WooCommerce na WordPressie: „znamy WordPress, mamy go na innych projektach, na wszystko jest wtyczka".
Na starcie działało. Problem pojawił się wraz ze wzrostem. WooCommerce to najtańsze wejście, ale za elastyczność płaci się utrzymaniem — wydajność i bezpieczeństwo to jego najsłabsze wymiary, a każda nowa potrzeba to kolejna wtyczka i kolejna powierzchnia awarii. Wraz z rosnącym katalogiem i ruchem sklep zwalniał, a lista wtyczek do pilnowania puchła. Po kilkunastu miesiącach biznes dojrzał dokładnie do tego, co najdroższe: do przepisania platformy — bo wybrany silnik pasował do strefy komfortu zespołu IT, a nie do roadmapy na najbliższe lata.
IT zoptymalizowało znajomość narzędzia. Biznes potrzebował platformy dobranej do tego, gdzie będzie za trzy lata, nie do tego, co zespół już umie.
Platforma to nie wybór technologiczny, który ma konsekwencje biznesowe. To wybór biznesowy, który ma konsekwencje technologiczne. Kolejność nie jest kosmetyką — przesądza o wyniku.
Jak ta decyzja powinna wyglądać
Zasada jest prosta: najpierw kryteria i ich wagi, potem nazwy platform. I biznes, i IT przy jednym stole — ale z jasnym podziałem ról. Zanim ktokolwiek wymówi słowo „Shopify" albo „Sylius", odpowiedz na siedem pytań:
- Model biznesowy. B2B, D2C czy hybryda? To rozstrzyga o cennikach, kredycie kupieckim i checkoucie — i najczęściej samo zawęża listę do dwóch platform.
- Roadmapa na 3–5 lat. Ekspansja geograficzna? Nowe kanały i marketplace'y? Do ilu SKU urośnie katalog? Platformę dobiera się do stanu docelowego, nie startowego.
- TCO, nie cena wdrożenia. Licencja plus aplikacje plus utrzymanie plus koszt (i dostępność) deweloperów w horyzoncie trzech lat. Darmowy silnik bywa najdroższy.
- Czas wejścia na rynek. Ile realnie czasu ma biznes, żeby ruszyć i zacząć iterować.
- Kto obsługuje sklep na co dzień. Marketing czy zespół techniczny? To decyduje, czy panel musi być dla marketerów, czy może być dla programistów.
- Dostępność kompetencji. Czy utrzymamy ten stack? Deweloperzy Symfony są w Polsce deficytowi — świetna platforma bez ludzi do jej obsługi to ryzyko, nie atut.
- Odporność na zmianę. Jak bardzo wybór wiąże nam ręce, gdy biznes skręci w bok.
Rola IT w tym procesie jest niezbędna — ale to rola eksperta, nie decydenta. IT ocenia platformy z krótkiej listy pod kątem wykonalności, integracji, wydajności i bezpieczeństwa oraz zgłasza czerwone flagi. Biznes ustala wagi kryteriów i wskazuje zwycięzcę. Kiedy IT dostaje prawo do ustalania wag, decyzja niepostrzeżenie przesuwa się w stronę tego, co IT ceni — i wraca do firmy w postaci trzech historii powyżej.
Dopasowanie platformy do profilu biznesu
Nie ma „najlepszej platformy" — jest platforma najlepiej dopasowana do konkretnego profilu. Tak wygląda mapowanie, którym posługujemy się najczęściej (pełne, sześciowymiarowe porównanie dziewięciu silników znajdziesz w naszych rankingach platform):
| Profil biznesu | Zwykle rekomendujemy | Dlaczego |
|---|---|---|
| D2C, prosty katalog, ekspansja EU, zespół marketingowy | Shopify Plus | Wejście na rynek w 8–14 tygodni, multi-currency i multi-language gotowe, panel dla marketerów |
| B2B, indywidualne cenniki, kredyt kupiecki, ERP, 10–100k SKU | Sylius | Logika B2B i custom natywnie, pełna kontrola nad kodem, tryb headless |
| Mid-market w PL/EU, umiarkowany budżet | PrestaShop | Popularny w Polsce, dobry dla mid-market, niższy koszt niż SaaS enterprise |
| Mały/średni sklep, minimalny budżet startowy | WooCommerce | Najtańsze wejście — ale trzeba liczyć się z kosztem utrzymania i wtyczek |
Dwie nasze realizacje pokazują, jak to działa przy właściwym dopasowaniu: Shopify Plus dla marki D2C — Topeshop, gdzie migracja z PrestaShop podniosła konwersję o 58% — oraz Sylius dla B2B, jak konfigurator produktów w KMK Klinkier. W obu przypadkach o platformie zdecydował profil biznesu, nie preferencja stacku.
Podsumowanie
Wybór platformy e-commerce jest decyzją biznesową, która ma konsekwencje techniczne — nie odwrotnie. IT jest w niej niezbędne jako głos wykonalności i ryzyka, ale kiedy dostaje prawo do ustalania wag, systematycznie optymalizuje kontrolę, znajomy stack i elegancję zamiast czasu wejścia na rynek, TCO i dopasowania do zespołu. Ustaw kryteria przed nazwami platform, posadź biznes i IT przy jednym stole z jasnym podziałem ról — a unikniesz najdroższego scenariusza, czyli przepisywania sklepu po osiemnastu miesiącach.
Jeśli decyzja o platformie jest przed Wami, dobrym pierwszym krokiem jest niezależny audyt i konsultacja platformowa — kończy się dokumentem z rekomendacją dla zarządu, opartym na profilu Waszego biznesu, a nie na preferencji jednej ze stron. Chętnie przejdziemy przez to razem z Wami; napiszcie do nas przez stronę kontaktu.