Rozmowa o nowym sklepie prawie zawsze zaczyna się tak samo. Klient ma otwarte trzy karty z cennikami i pyta, która platforma jest tańsza. Tylko że pyta o coś zupełnie innego – czy jego sposób sprzedaży da się w tym narzędziu odwzorować bez sklejania całości taśmą i ręcznych eksportów do arkusza.
Cennik przejmuje uwagę, bo to jedyne, co widać przed startem. Reszta wychodzi później: przy pierwszej integracji z księgowością, przy pierwszym sezonie wyprzedaży, przy pierwszym zwrocie, którego nie da się rozliczyć zgodnie z procedurą firmy.
Dlatego wybór platformy e-commerce traktujemy jako decyzję o procesach, nie o abonamencie. Zamówienie, magazyn, rozliczenie, obsługa reklamacji – to one wyznaczają granice tego, co da się sensownie zbudować. Sklep B2C z jednym magazynem i hurtownia z indywidualnym cennikiem dla każdego kontrahenta zadają identyczne pytanie, a powinny usłyszeć dwie różne odpowiedzi.
Spis treści
Zacznij od mapy procesów, nie od listy funkcji
Pytanie “czy platforma ma funkcję X” prowadzi donikąd. Każda odpowie twierdząco, tyle że na innym poziomie szczegółowości. Lepiej opisać drogę zamówienia od kliknięcia do faktury i ewentualnego zwrotu, zaznaczając każdy punkt, w którym wkracza człowiek albo inny system.
Z naszego doświadczenia o wyborze przesądza kilka obszarów:
- Model cenowy i rabatowanie – ceny widoczne po zalogowaniu, progi ilościowe, indywidualne warunki handlowe.
- Warianty i konfiguratory – produkty składane z opcji, wycena zależna od parametrów.
- Stany magazynowe i rezerwacje – wiele magazynów, blokada towaru na czas płatności, zamówienia zwrotne.
- Dokumenty sprzedaży i zgodność podatkowa – faktury, korekty, stawki dla różnych krajów.
- Logistyka i zwroty – etykiety kurierskie, punkty odbioru, obieg reklamacji.
- Wiele rynków i języków – odrębne katalogi, waluty, treści.
- Uprawnienia zespołu – kto widzi marże, kto może zmienić cenę.
Najczęstszy błąd? Decyzja podjęta na demie. Tam wszystko wygląda podobnie, bo każde rozwiązanie potrafi wrzucić produkt do koszyka. Prawdziwy sygnał ostrzegawczy jest inny: jeśli proces żyje dziś w arkuszu i skrzynce mailowej, żadna platforma nie naprawi go sama. Najpierw trzeba go opisać.
Gdzie kończy się konfiguracja, a zaczyna kod
Każde z trzech rozwiązań stawia tę granicę gdzie indziej. Shopify zamyka backend i wypycha nietypową logikę do aplikacji oraz funkcji uruchamianych w chmurze dostawcy, dlatego wdrożenia na platformie Shopify planujemy inaczej niż resztę. WooCommerce i PrestaShop oddają dostęp do warstwy serwerowej, więc zmiana zachowania sklepu bywa kwestią jednego haka w kodzie.
Konsekwencja jest architektoniczna, nie estetyczna. W modelu zamkniętym płacisz elastycznością – pewnych rzeczy po prostu nie zrobisz, a obejścia muszą mieścić się w cudzych limitach. W otwartym płacisz odpowiedzialnością: za aktualizacje, za bezpieczeństwo, za to, że po wgraniu poprawki koszyk nadal działa.
Weźmy nietypowe ceny dla zalogowanego kontrahenta. W jednym świecie to wtyczka i kilka linii w kodzie liczącym cenę. W drugim – dedykowana aplikacja, kolejne wywołania API i pytanie, czy zdąży odpowiedzieć przed renderowaniem strony. Ale uwaga: model zamknięty bywa realną zaletą dla małego zespołu bez działu IT, który nie chce się budzić z niedziałającym sklepem po nocnej aktualizacji.
Integracje decydują częściej niż sam sklep
Sklep rzadko stoi sam. Obok pracuje ERP, magazyn, system fakturowy, bramki płatnicze, kurierzy, czasem CRM i narzędzia marketingowe. I to te połączenia, a nie szablon graficzny, generują większość ryzyka w projekcie.
Pytanie, które zadajemy przed wyborem, brzmi tak: czy wymiana danych ma być synchroniczna, czy kolejkowana, i co się dzieje, gdy druga strona milczy. “Spróbujemy ponownie” nie wystarcza, jeśli w międzyczasie klient kupił towar, którego już nie ma.
Limity API i ograniczenia webhooków w platformach chmurowych potrafią wywrócić masową synchronizację stanów, której nikt nie policzył na etapie oferty. Katalog aktualizowany co kwadrans z systemu magazynowego wygląda niewinnie. Do momentu zderzenia z twardym budżetem zapytań. Po stronie otwartej najczęściej trafiamy na sklepy na PrestaShop spięte z ERP, gdzie kolejkowanie da się ustawić po swojemu.
Drugi klasyk to gotowy konektor do ERP kupiony bez sprawdzenia, czy mapuje wszystkie pola używane przez księgowość. Zwykle kończy się warstwą pośrednią, którą i tak trzeba napisać. Tyle że później i pod presją.
Struktura kosztów: co naprawdę napędza rachunek
Rachunek za sklep składa się z licencji lub abonamentu, prowizji od transakcji, wtyczek i aplikacji, hostingu, wdrożenia, integracji oraz stałego utrzymania. Cennik pokazuje pierwszy z tych składników i milczy o reszcie. Żeby rozmowa o budżecie miała punkt zaczepienia, publikujemy orientacyjne wyceny wdrożeń.
Model chmurowy rozkłada koszt w czasie i wiąże go z obrotem: im więcej sprzedajesz, tym więcej płacisz, za to nie martwisz się serwerem. Self-hosted przesuwa wydatek na start i na zespół, który potem aktualizuje, testuje i pilnuje bezpieczeństwa.
Otwarte platformy mają ukryty koszt w zależnościach. Każda wtyczka to cudzy kod, który może przestać być rozwijany i zablokować aktualizację całego sklepu, łącznie z łatkami bezpieczeństwa. Zamknięte mają swój: obejście brakującej funkcji bywa droższe niż napisanie jej wprost, bo trzeba je wcisnąć w ograniczenia, na które nie masz wpływu.
Skalowanie, bezpieczeństwo i dane, czyli życie po starcie
Skalowanie w handlu internetowym rzadko dotyczy ruchu na stronie. Prawie zawsze chodzi o bazę danych. Katalog z dużą liczbą wariantów, rosnąca historia zamówień, zapytania filtrujące po atrybutach – to potrafi spowolnić sklep, który na starcie chodził bez zarzutu.
Odpowiedzialność za bezpieczeństwo dzieli się w obu modelach zupełnie inaczej. W chmurze aktualizuje dostawca i to jego problem. W wersji instalowanej u siebie robi to konkretna osoba w zespole albo – co widujemy najczęściej – nikt. Aż do incydentu.
Dane klientów i zamówień to aktywo, nie efekt uboczny. Muszą dać się wyeksportować w surowej postaci, inaczej analityka opiera się na wykresach dostawcy, a przyszła migracja zamienia się w projekt archeologiczny. Utrzymanie planuje się przed startem: kto aktualizuje, gdzie leży backup, jak wygląda środowisko testowe i procedura wdrożenia zmiany.
Jak wygląda dobra decyzja w praktyce
Dobra decyzja jest odwracalna. Zakłada, że za dwa lata warunki mogą się zmienić, więc integracje projektuje się z myślą o wymianie, a dane trzyma tak, żeby dało się je przenieść bez przepisywania połowy firmy.
Profile układają się dość czytelnie. Prosty katalog i szybki start – model chmurowy. Sklep mocno zrośnięty z treścią i istniejącym WordPressem naturalnie ciąży ku rozwiązaniu, jakim jest sklep na WooCommerce. Rozbudowana sprzedaż z własną logiką biznesową i wieloma rynkami wymaga pełnej kontroli nad kodem.
Przed podpisaniem umowy polecam prosty sprawdzian: opisz trzy najtrudniejsze scenariusze swojego procesu i poproś wykonawcę, żeby pokazał, jak zrealizuje je w proponowanym rozwiązaniu. Udane wdrożenie zaczyna się od procesu i kończy na platformie. Nieudane idzie dokładnie odwrotnie.
Podsumowanie
Platforma jest narzędziem do obsługi procesu sprzedaży, więc kolejność jest jedna: najpierw opisz proces, potem porównuj narzędzia. Cennik nabiera wtedy sensu, bo wreszcie wiadomo, co dokładnie kupujesz.
Ze spotkania z wykonawcą zabierz trzy pytania kontrolne. Gdzie kończy się konfiguracja, a zaczyna programowanie. Jak zachowają się integracje pod obciążeniem i przy awarii drugiej strony. Kto utrzymuje ten sklep za rok. Odpowiedzi powiedzą o projekcie więcej niż lista funkcji.
W Web Systems od 2006 roku projektujemy aplikacje webowe, systemy B2B i integracje, więc na sklep patrzymy jak na element większej układanki. Jeśli stoisz przed wyborem platformy, planujesz połączenie sprzedaży z ERP, migrację, automatyzację procesów albo modernizację działającego sklepu, odezwij się – zaczniemy od twojego procesu, nie od gotowej rekomendacji.
