Większość ludzi zlecających sklep internetowy ocenia oferty po cenie i wyglądzie portfolio. To błąd — i dość kosztowny. Moje doświadczenie w budowania e-commerce'ów (w tym pełnoprawnego marketplace'u z własnym systemem rozliczeń) widzę te same problemy, które pojawiają się po wdrożeniu, nie przed nim.
Poniżej pięć pytań, które powinieneś zadać zanim podpiszesz umowę — i czego tak naprawdę szukasz w odpowiedzi.
1. Na jakiej platformie to będzie zbudowane i dlaczego akurat tej?
To jest pytanie, na które każdy developer powinien mieć konkretną, przemyślaną odpowiedź. Nie "bo tak" i nie "bo zawsze tak robimy".
Różnica między Shopify, WooCommerce i rozwiązaniem headless (np. Medusa.js) to nie tylko cena wdrożenia — to różnica w tym, co możesz zrobić za rok, dwa, pięć. Shopify świetnie sprawdza się przy prostej sprzedaży, ale każda niestandardowa logika kosztuje prowizję, plugin albo całkowity refaktoring. WooCommerce jest elastyczny, ale pod dużym ruchem zaczyna się sypać i utrzymanie staje się osobnym projektem.
Medusa.js to open-source'owy backend e-commerce — modularny, bez opłat licencyjnych, z pełną kontrolą nad kodem. Połączony z Next.js na froncie daje architekturę, którą możesz rozwijać bez ograniczeń narzuconych przez platformę. Ale to też oznacza, że developer musi wiedzieć, co robi — bo nie ma tu gotowych wtyczek do wszystkiego.
Jeśli developer nie potrafi wyjaśnić Ci tej różnicy w języku korzyści dla Twojego biznesu — a nie w żargonie technicznym — to sygnał ostrzegawczy.
2. Jak wygląda system płatności — kto faktycznie trzyma pieniądze i kiedy do mnie trafiają?
Brzmi banalnie. Nie jest.
Przy budowie Artovnii (marketplace dla artystów) kwestia rozliczeń okazała się jednym z najtrudniejszych elementów całego projektu. Platforma obsługuje wielu sprzedawców w ramach jednej transakcji — środki muszą być rozdzielone, opóźnione do zakończenia okresu zwrotów, a prowizja naliczana automatycznie. To nie jest "dodajemy Stripe" — to dedykowany system finansowy.
W Medusa.js integracja z Stripe jest wbudowana, ale obsługa split payments, Stripe Connect czy opóźnionych wypłat wymaga już własnej logiki po stronie backendu. Warto zapytać, czy developer rozumiał to zanim zaczął projekt, czy dopiero odkryje to w trakcie.
W przypadku zwykłego sklepu pytanie jest prostsze, ale wciąż ważne: czy płatności przechodzą bezpośrednio do Ciebie czy przez pośrednika? Czy są opóźnienia? Jakie są koszty transakcji przy różnych wolumenach? Czy obsługiwane są lokalne metody płatności jak BLIK czy P24?
Zły system płatności odkryjesz dopiero przy pierwszych zwrotach albo pierwszym konflikcie z klientem.
3. Czy po wdrożeniu będę mógł zarządzać sklepem sam — bez dzwonienia do programisty?
To pytanie dotyczy panelu administracyjnego i CMS-u. Brzmi oczywisto, ale wiele sklepów jest oddawanych klientom z takim panelem, że zmiana opisu produktu wymaga "małej poprawki" za kilkaset złotych.
Medusa.js ma własny panel admina — funkcjonalny, ale domyślnie ograniczony do zarządzania produktami, zamówieniami i klientami. Jeśli potrzebujesz czegoś więcej (np. edycji treści na stronie, zarządzania blogiem, landing pages), to wymaga albo rozszerzenia panelu Medusy, albo osobnego CMS-u (np. Sanity, Contentful).
Zapytaj konkretnie: czy mogę sam dodawać produkty? Tworzyć promocje i kody rabatowe? Zmieniać zdjęcia i opisy? Zarządzać stanami magazynowymi? Wysyłać newsletter do klientów?
W Artovnii panel sprzedawcy dostali m.in. rich text editor z opisami SEO, system promocji (rabaty, darmowa dostawa, oferty dla konkretnych klientów), wykrywanie porzuconych koszyków i tryb urlopowy. Taki zakres nie jest standardem — ale warto wiedzieć, czego oczekujesz, zanim zatwierdzisz zakres projektu.
4. Co się stanie, kiedy sklep zacznie rosnąć?
Niemal każdy developer powie Ci, że "sklep jest skalowalny". Zapytaj jak.
Konkretne pytania: jak wygląda cachowanie? Co się stanie, gdy wejdzie na sklep 1000 osób jednocześnie? Gdzie jest hostowany backend i jak reaguje na skoki ruchu (np. Black Friday)? Czy wyszukiwarka produktów nadal działa sprawnie przy katalogu 10 000 produktów?
Medusa.js działa jako Node.js backend — można go hostować na Railway, Render, AWS czy własnym VPS. Ale sama platforma nie rozwiązuje za Ciebie problemów ze skalowalnością. Potrzebujesz przemyślanej architektury: Redis do cachowania sesji i danych, ISR (Incremental Static Regeneration) w Next.js dla stron produktowych, Algolia lub Meilisearch dla wyszukiwania przy dużym katalogu.
Przy Artovnii przeszedłem przez optymalizację backendu, gdzie niektóre requesty trwały kilka sekund — i doprowadzenie ich do poziomu <100ms wymagało konkretnych decyzji architektonicznych: Redis, warstwowe cachowanie, ISR w Next.js, Algolia dla wyszukiwania. Efekt: LCP ~1,4s na desktopie, p99 dla ciężkich zapytań ~300ms.
To nie są szczegóły dla entuzjastów. To różnica między sklepem, który zarabia podczas promocji, a sklepem, który pada właśnie wtedy, kiedy powinien zarabiać.
5. Kto jest właścicielem kodu i co się dzieje po wdrożeniu?
Dwa pytania w jednym, bo są ze sobą powiązane.
Własność kodu: czy po zakończeniu projektu otrzymujesz pełny dostęp do repozytorium? Czy kod jest pisany tak, że możesz go oddać innemu developerowi do dalszego rozwijania? Czy jesteś uzależniony od tej jednej osoby lub firmy?
Medusa.js jako open-source daje Ci tu przewagę — nie ma vendor lock-in na poziomie platformy. Ale vendor lock-in może pojawić się na poziomie implementacji: jeśli developer napisał niestandardowe moduły bez dokumentacji, w praktyce jesteś od niego zależny tak samo jak od zamkniętej platformy.
Co po wdrożeniu: kto zarządza hostingiem? Kto aktualizuje zależności? Co się dzieje, gdy pojawi się błąd krytyczny w sobotę o 22:00, kiedy akurat masz kampanię? Czy jest support i na jakich zasadach?
Brak jasnych odpowiedzi na te pytania to przepis na zależność, która po roku staje się droższa niż sam projekt.
Dobry developer nie będzie miał problemu z odpowiedzią na żadne z tych pytań — wręcz przeciwnie, ucieszy się, że klient zadaje właściwe pytania. To oznacza, że rozmawia z kimś, kto traktuje projekt poważnie.
Osobiście w swoich implementacjach e-commerce wybieram Medusa.js jako bazę do dedykowanej implementacji.