Wybór platformy e-commerce rzadko psuje się na etapie kodu. Psuje się wcześniej: gdy nikt nie zapisał, kto kupuje, jak płaci i co ma się zmienić w ciągu 12 miesięcy. Zanim porównasz PrestaShop, WooCommerce, Shoper, IdoSell i Shopify, ustal model sprzedaży i policz warianty produktów — to dwie liczby, które przesądzają o większości decyzji technicznych.
Poniżej znajdziesz kryteria, progi decyzyjne i listę kontrolną, którą można przejść przed podpisaniem umowy z wykonawcą. Punkt startowy i szerszy kontekst znajdziesz w sekcji sklepy internetowe.
Na jednej kartce zapisz cztery zdania: kto kupuje, jak płaci, czy potrzebuje faktury i czy zamawia hurtowo. To nie ćwiczenie strategiczne, tylko specyfikacja — od tych czterech odpowiedzi zależą ustawienia koszyka, cenników i integracji.
B2C. Klient detaliczny. Płatność online (BLIK, karta, Przelewy24), paragon domyślnie, jeden cennik brutto, zakup bez logowania. Koszyk musi być krótki: maksymalnie 3 kroki, bez wymuszonego konta.
B2B. Klient firmowy. Płatność przelewem, często z odroczonym terminem, faktura z NIP-em obowiązkowa, ceny netto, rabaty zależne od grupy. Dochodzi koszyk B2B — zamówienie przez wklejenie listy SKU, ponowne zamówienie z historii, limity zamówień (np. minimum 500 zł netto) i ceny dedykowane dla konkretnego klienta.
Model mieszany to najczęstszy przypadek w praktyce. Wtedy decyzja jest binarna: dwie witryny (B2C i B2B osobno) albo jeden sklep z grupami klientów i cennikiem ukrytym do momentu zalogowania. Druga opcja jest tańsza w utrzymaniu, pierwsza prostsza w komunikacji i w SEO.
Sprawdź, czy platforma robi to w rdzeniu, czy wymaga modułu. PrestaShop ma grupy klientów i ceny specyficzne w standardzie. WooCommerce dokłada to wtyczkami. Shoper i IdoSell mają funkcje B2B, ale zwykle w wyższych planach — pytaj o to przed porównywaniem cenników. Shopify B2B wymaga planu Plus.
Na koniec zapisz cel na 12 miesięcy w liczbach: liczba SKU, docelowy obrót, kanały sprzedaży. Jeśli planujesz hurt, zobacz, jak wygląda sklep internetowy dla hurtowni — tam limity zamówień i ceny grupowe są punktem wyjścia, a nie dodatkiem. Punkt startowy i szerszy kontekst znajdziesz w sekcji sklepy internetowe.
Podział nie idzie o jakość kodu, tylko o to, kto odpowiada za serwer, aktualizacje i bezpieczeństwo. W SaaS płacisz abonament i dostajesz to w pakiecie. W open source płacisz za hosting i serwis, ale decydujesz o każdym module.
SaaS wygrywa, gdy: katalog to kilkaset SKU, nie potrzebujesz nietypowych integracji, nie masz w firmie osoby technicznej, a start potrzebny jest w tygodniach, nie miesiącach. Shoper i IdoSell mają gotowe moduły InPost, DPD, DHL i płatności — konfiguracja to kwestia dni.
Open source wygrywa, gdy: potrzebujesz własnej logiki (konfigurator, wycena, integracja z ERP albo systemem produkcyjnym), chcesz trzymać kod u siebie i skalujesz katalog powyżej kilku tysięcy SKU. PrestaShop ma rozbudowany model kombinacji i dokumentację dla deweloperów, która pozwala pisać moduły bez hackowania rdzenia. WooCommerce daje elastyczność WordPressa, ale wymaga pilnowania wtyczek i wydajności bazy.
Własność danych. Przed podpisaniem umowy zapytaj, w jakich formatach wyeksportujesz produkty, zamówienia, klientów i treści CMS oraz czy dane znikają po rezygnacji. Zrób test na koncie próbnym: eksport 100 produktów i 50 zamówień. Jeśli eksport jest jednorazową, płatną usługą — to koszt wyjścia, nie koszt wejścia.
Ukryte koszty. Limity wywołań API na dobę, limity liczby zamówień w planie, prowizja od transakcji przy zewnętrznej bramce płatniczej, płatne aplikacje (program lojalnościowy, feed na Ceneo), opłaty za dodatkowe konta pracownicze, limit miejsca na pliki. Suma tych pozycji bywa wyższa niż abonament. Jak liczyć koszt całości po stronie open source, opisujemy w materiale ile kosztuje sklep internetowy WooCommerce.
| Platforma | Model | Kiedy sensowna | Na co uważać |
|---|---|---|---|
| Shoper | SaaS | Mały i średni katalog, szybki start, brak zespołu technicznego | Limity planu, płatne aplikacje, ograniczona ingerencja w kod |
| IdoSell | SaaS | Sprzedaż wielokanałowa, integracje z porównywarkami | Koszty wyższych planów, zależność od API przy integracjach |
| Shopify | SaaS | Sprzedaż zagraniczna, szybkie testy nowych rynków | B2B wymaga planu Plus, prowizje, koszty aplikacji w USD |
| PrestaShop | Open source (własny hosting) | Duży katalog, nietypowe integracje, kontrola nad kodem | Konieczne aktualizacje, serwis i kopie zapasowe po Twojej stronie |
| WooCommerce | Open source (WordPress) | Sklep połączony z treściami, blogiem i istniejącą stroną | Wydajność przy dużym katalogu, konflikty wtyczek, aktualizacje |
Każde z tych kryteriów da się sprawdzić w ciągu jednej rozmowy z wykonawcą. Jeśli słyszysz „to zależy”, proś o konkretny przykład z wdrożenia i nazwę modułu.
| Kryterium | Jak sprawdzić | Próg decyzyjny |
|---|---|---|
| Katalog i warianty | Import testowy 1000 SKU na koncie stagingowym | Powyżej 5000 SKU wymagaj testu wydajności filtrów |
| Integracje | Lista modułów z nazwami i cenami | Brak gotowego modułu do ERP = praca na zamówienie |
| SEO techniczne | Audyt URL, canonicali i schema na 20 losowych produktach | LCP, INP i CLS w zielonych progach |
| Koszty 24 miesiące | Wdrożenie + hosting + abonament + moduły + serwis | Porównuj sumy, nie stawki miesięczne |
| Deweloperzy i SLA | Pytanie o czas reakcji i kopie zapasowe | Zapisany czas reakcji na awarię krytyczną |
| Własność kodu | Zapis w umowie o prawach do modułów | Moduły na zamówienie przechodzą na Ciebie |
| Wyjście z platformy | Test eksportu + plan przekierowań 301 | Eksport w CSV/XML dostępny bez opłat |
Zanim porównasz funkcje, policz trzy liczby: liczbę SKU (nie produktów), miesięczny ruch i liczbę osób, które realnie będą obsługiwać sklep. Te trzy wartości wycinają większość opcji taniej niż jakiekolwiek demo.
Uwaga na liczenie SKU: 100 produktów w 6 rozmiarach i 3 kolorach to 1800 wariantów. W PrestaShop kombinacje generują osobne rekordy w bazie, w WooCommerce warianty są lżejsze, ale nadal obciążają filtrowanie i wyszukiwarkę. To jedna liczba, która przesądza o tym, czy wystarczy hosting współdzielony, czy potrzebny jest VPS.
Ruch powyżej 50 tys. wizyt miesięcznie i dominacja mobile oznaczają, że musisz mierzyć TTFB, LCP i INP. Bez tych trzech wskaźników nie wiesz, czy problem jest w hostingu, w szablonie, czy w module. Punkty odniesienia i zakres pomiaru opisuje dokumentacja Web Vitals.
Trzecia liczba — zespół. Jeśli sklep obsługuje jedna osoba, wybierz SaaS. PrestaShop z 15 modułami wymaga kogoś, kto zrobi aktualizację i sprawdzi, czy nic się nie rozjechało po zmianie wersji PHP.
| Wariant | Liczba SKU | Ruch miesięcznie | Zespół | Kierunek |
|---|---|---|---|---|
| Mikro | do 100 | do 10 tys. wizyt | 1–2 osoby | SaaS lub prosty WooCommerce |
| Średni | 100–1000 | 10–50 tys. wizyt | 2–5 osób | WooCommerce / PrestaShop + cache + CDN |
| Duży | 1000–10 000 | 50–200 tys. wizyt | e-commerce + IT | PrestaShop, własne moduły, ERP, wydajny hosting |
| Bardzo duży / B2B | powyżej 10 000 | powyżej 200 tys. wizyt | zespół deweloperski | dedykowane rozwiązanie, headless, integracje API |
Oferty wykonawców porównuje się dziś na jednym poziomie: godzinach i stawce. Poproś o rozbicie na etapy (analiza, konfiguracja katalogu, szablon, integracje, migracja treści, testy, wdrożenie, szkolenie) i o liczbę godzin przy każdym. Jeśli oferta ma jedną pozycję „wdrożenie sklepu — X zł”, nie masz jak jej porównać z konkurencyjną.
Do tego koszty, o których zapomina się w ofercie: prowizje operatora płatności, opłaty kurierskie, licencje na zdjęcia, teksty, audyt SEO, domena i certyfikat.
Przykład: sklep z 500 produktami, sprzedaż krajowa, jedna osoba do obsługi. Łączny koszt trzyletni obejmuje wdrożenie, hosting, moduły, utrzymanie i integracje. Widełki są szerokie i zależą głównie od zakresu integracji — rozpisujemy je w tekstach o tym, ile kosztuje sklep internetowy WooCommerce oraz jaka jest cena za sklep internetowy z 500 produktami. W obu przypadkach kluczowa jest nie kwota, a lista pozycji, które ta kwota pokrywa.
| Kategoria kosztu | Charakter | Uwaga przy porównaniu ofert |
|---|---|---|
| Wdrożenie | jednorazowo | godziny na etapy, nie jedna kwota |
| Hosting/VPS, poczta, backup | miesięcznie, rośnie z ruchem | licz 36 miesięcy z góry |
| Licencje, wtyczki, moduły | mieszany: raz lub rocznie | sprawdź, co się stanie po wygaśnięciu abonamentu |
| CDN | miesięcznie | sens przy katalogu z dużą liczbą zdjęć |
| Utrzymanie i rozwój | rocznie, 15–25% budżetu wdrożenia | kto reaguje na zmianę API dostawcy |
| Prowizje płatności i kurierów, treści, grafiki | stałe lub jednorazowe | zwykle poza ofertą wykonawcy |
Wybór platformy to w praktyce wybór ekosystemu: co ma gotowy connector, a co trzeba dopisać. Standardowy zestaw w polskim sklepie wygląda tak:
Różnica między gotową wtyczką a własnym modułem jest kosztowa i utrzymaniowa. Gotowa wtyczka: szybciej, ale działa w zakresie, jaki przewidział autor, i masz ograniczony wpływ na sposób mapowania pól. Własny moduł: pełna kontrola, ale płacisz za kod, testy i późniejsze zmiany po stronie API. W PrestaShop struktura modułu, hooki i obsługa zamówień są udokumentowane w dokumentacji dla deweloperów PrestaShop — warto sprawdzić, czy wykonawca z niej korzysta, czy „obchodzi” system obejściami.
Pytania, które zadaj przed podpisaniem umowy: czy integracja działa po REST, SOAP czy przez pliki CSV; czy dostawca wysyła webhooki, czy trzeba odpytywać API w pętli; jakie są limity zapytań na dobę; czy jest środowisko testowe; kto zgłasza błędy po stronie producenta API; co się dzieje, gdy dostawca zmieni wersję.
Ryzyka, które kosztują najwięcej: brak wsparcia dla wtyczki po roku, prowizje pośredników przy niejasnym modelu rozliczeń oraz praca ręczna w magazynie. 200 zamówień miesięcznie przepisywanych ręcznie po 3 minuty to 10 godzin pracy — stały koszt, który łatwo przegapić w ofercie. Przy sprzedaży hurtowej dodatkowo sprawdź, jak platforma obsługuje cenniki i zamówienia w modelu B2B, bo tam integracja z ERP jest zwykle warunkiem startu.
SEO techniczne platformy sprawdza się przed wdrożeniem, na kopii testowej, a nie po starcie. Poproś wykonawcę o staging z 50–100 realnymi produktami — tymi samymi zdjęciami i opisami co na produkcji — i przejdź listę kontrolną.
Migracja SEO to osobny projekt: mapa przekierowań 301 dla wszystkich starych adresów, nowa sitemap XML zgłoszona w Search Console, monitoring 404 i pozycji przez 6–12 tygodni. Przykład z wdrożenia: sklep z 1 200 produktami i wariantami wygenerował 4 800 adresów, a bez mapy 301 odbudowa ruchu z fraz długiego ogona zajęła pół roku. Jak wygląda to w praktyce na WordPressie, opisujemy w materiale o sklepie internetowym na WordPress w Gorzowie.
| Element | Co sprawdzić na stagingu | Sygnał ostrzegawczy |
|---|---|---|
| URL | /kategoria/produkt + 301 po zmianie nazwy | adresy z ?id_product= |
| Canonical i filtry | canonical + noindex na filtrach i sortowaniu | tysiące zaindeksowanych filtrów |
| Dane strukturalne | Product/Offer z ceną i dostępnością | brak schematu albo duplikaty z wtyczki |
| LCP | ≤ 2,5 s przy 100 produktach z 5 zdjęciami | powyżej 4 s na stagingu |
| INP i CLS | ≤ 200 ms / ≤ 0,1 | layout skacze po loaderze banerów |
| Dostęp | SSH, Git, szablon child, konfiguracja cache | szyfrowany szablon, brak eksportu |
Sygnały, że czas na migrację, są policzalne. Pierwszy: platforma podnosi abonament o więcej niż 20% rocznie albo uderza w limity (SKU, warianty, konta, liczba zamówień). Drugi: brak API i webhooków — stany magazynowe i faktury wpisujesz ręcznie. Trzeci: wersja po końcu wsparcia, np. PrestaShop 1.6 albo WooCommerce na PHP 7.4; wspierane gałęzie sprawdzisz w dokumentacji dla deweloperów PrestaShop. Czwarty: TTFB powyżej 800 ms przy 500 SKU mimo włączonego cache. Piąty: nie ma kogo zapytać — wykonawca nie odpowiada albo przekazuje zlecenie dalej.
Etapy migracji dla sklepu z 500–2 000 SKU: audyt 2–5 dni, eksport bazy i plików 1 dzień, mapowanie pól, kategorii i klientów 3–10 dni, migracja na staging 2–5 dni, testy 3–7 dni (zamówienie testowe, płatność w sandboxie, maile, faktury, stany), start w oknie niskiego ruchu — np. wtorek 6:00 — i 30 dni opieki powdrożeniowej. Budżet policz jak w materiale o cenie za sklep internetowy z 500 produktami: godziny × stawka, nie cena z sufitu.
SLA. Zapisz w umowie: czas reakcji (np. 4 h dla awarii krytycznej, 1 dzień roboczy dla zwykłego zgłoszenia), kanał zgłoszeń, zakres (aktualizacje, backupy, monitoring, poprawki błędów vs. nowe funkcje), dostępność w weekendy i konsekwencje za przekroczenie.
Własność. Kod w Twoim repozytorium Git, dostępy do serwera, domeny i licencji modułów zapisane na Twoją firmę, eksport bazy na żądanie w CSV/SQL, klauzula wyjścia: co dokładnie dostajesz w 5 dni roboczych po zakończeniu umowy.
| Etap | Czas | Co się dzieje, gdy go pominiesz |
|---|---|---|
| Audyt | 2–5 dni | nie wiesz, ile masz unikalnych adresów i integracji |
| Eksport danych | 1 dzień | brakuje historii zamówień i kont klientów |
| Mapowanie pól | 3–10 dni | kategorie i warianty lądują w złych miejscach |
| Migracja na staging | 2–5 dni | testujesz na produkcji, w ruchu |
| Testy | 3–7 dni | płatności i faktury wysypują się po starcie |
| Start + 30 dni opieki | 1 miesiąc | błędy zgłaszane przypadkowymi kanałami |
Zanim podpiszesz umowę, zadaj dziesięć pytań. Odpowiedzi zapisz w mailu — to Twoja dokumentacja na przyszłość.
Widełki ustalaj w godzinach, nie w złotówkach. Punkt startowy do rozmowy, który warto zweryfikować z dwoma–trzema wykonawcami: sklep na gotowym szablonie z jedną integracją płatności to zwykle 60–120 h; migracja z innej platformy, integracja z ERP i szablon custom to 150–400 h. Pomnóż przez stawkę i masz zakres, a nie cenę zgadywaną. Jeśli oferta nie zawiera godzin, wykonawca nie szacował pracy, tylko strzelał.
Czerwone flagi: brak pytań o Twój proces sprzedaży, brak referencji z dłuższym stażem, faktura od firmy bez zespołu, cena bez zakresu. Opiekę powdrożeniową wyceniaj jak osobny produkt — czas reakcji, zakres, koszt miesięczny. Przy sklepie hurtowym z logiką cenową i wieloma grupami klientów ten zakres jest większy; rozkładamy go w materiale o sklepie internetowym dla hurtowni. Warto porównać też koszt sklepu na WooCommerce, żeby wiedzieć, co w tej kwocie jest standardem, a co dopłatą.
| Pytanie | Dobra odpowiedź | Czerwona flaga |
|---|---|---|
| Doświadczenie | 3–5 adresów sklepów na tej platformie | „robimy wszystko” |
| Zespół | konkretne osoby i role | brak nazwisk, tylko handlowiec |
| Wycena | rozbicie na godziny i etapy | jedna kwota bez zakresu |
| Własność kodu | repozytorium klienta, dostępy na klienta | kod zostaje u wykonawcy |
| Opieka po starcie | SLA w umowie, czas reakcji, zakres | „zgłaszaj, jak coś się stanie” |
| Referencje | sklep prowadzony od 3 lat | wyłącznie świeże wdrożenia |
Wybór platformy na podstawie logo i opinii, a nie modelu sprzedaży. Ktoś polecił Shopify, więc bierzemy Shopify — mimo że połowa zamówień to hurt z fakturą i limitem zamówienia.
Jak wykryć: Zadaj sobie trzy pytania i zapisz odpowiedzi: kto kupuje, jak płaci, czy potrzebuje faktury i cen dedykowanych. Jeśli nie umiesz odpowiedzieć w trzech zdaniach, nie masz jeszcze podstawy do wyboru.
Jak naprawić: Rozpisz model sprzedaży na jednej stronie: B2C, B2B czy mieszany, średnia wartość koszyka, czy klient kupuje hurtowo, czy potrzebuje limitów zamówień. Dopiero do tego dopasuj platformę.
Porównywanie wyłącznie kosztu wdrożenia. Oferty różnią się między sobą, ale nikt nie policzył kosztu utrzymania, licencji i rozwoju w perspektywie trzech lat.
Jak wykryć: Weź ofertę i sprawdź, czy zawiera osobną pozycję na hosting, licencje, moduły, CDN oraz rozwój roczny. Jeśli jest jedna kwota „za sklep”, to nie jest kalkulacja.
Jak naprawić: Poproś wykonawcę o rozbicie TCO na 3 lata: wdrożenie, infrastruktura, dodatki, rozwój i utrzymanie rocznie. Porównuj wyłącznie takie same zakresy.
Założenie, że „wszystko się zintegruje”. ERP, płatności i kurierzy są traktowane jako oczywistość, a wychodzą na etapie testów przed startem.
Jak wykryć: Zapytaj wprost: czy istnieje gotowa wtyczka lub moduł do Twojego ERP i konkretnego kuriera, kto ją utrzymuje i kiedy była ostatnia aktualizacja.
Jak naprawić: Zamów test integracji przed podpisaniem umowy — na kilku realnych zamówieniach i fakturach. Brak wsparcia dla Twojego ERP to nie „drobiazg na potem”, to ryzyko ręcznej pracy magazynu.
Liczenie produktów zamiast wariantów. Sklep „z 500 produktami” może mieć 4000 wariantów i to one obciążają katalog oraz wyszukiwarkę.
Jak wykryć: Policz warianty: rozmiar, kolor, pojemność, opakowanie. Sprawdź, czy każdy wariant ma własny URL i czy platforma nie generuje duplikatów treści.
Jak naprawić: Przelicz warianty jako osobne pozycje w kalkulacji wydajności i hostingu. Zrób test katalogu na docelowym serwerze z realną liczbą wariantów, nie na demo z 20 produktami.
Brak dostępu do kodu i brak planu eksportu danych. Po dwóch latach okazuje się, że nie można wyjść z platformy bez utraty treści i historii zamówień.
Jak wykryć: Zapytaj, kto będzie właścicielem kodu, gdzie jest repozytorium i czy możesz wyeksportować produkty, klientów oraz zamówienia w formacie nadającym się do ponownego importu.
Jak naprawić: Wpisz do umowy własność kodu i prawo do eksportu danych. Ustal, w jakim formacie przekazane zostaną dane przy zakończeniu współpracy.
Decyzja o SEO technicznym podejmowana po wdrożeniu. Wtedy zmiana struktury URL oznacza przekierowania i utratę pozycji.
Jak wykryć: Obejrzyj wersję demonstracyjną lub testową i sprawdź: adresy URL produktów i kategorii, canonical, meta, dane strukturalne oraz dostęp do edycji szablonu.
Jak naprawić: Ustal wymagania SEO przed startem i wpisz je jako punkt odbioru. Testuj je na szablonie, nie na produkcji po uruchomieniu.
Wybór platformy to decyzja organizacyjna, nie technologiczna. Najpierw model sprzedaży, liczba wariantów i cel na 12 miesięcy, potem porównanie SaaS i open source według tych samych kryteriów. Katalogi do 100 produktów i mały ruch spokojnie udźwignie prosty SaaS lub WooCommerce; przy setkach i tysiącach wariantów dochodzi cache, CDN, hosting i ERP. Każdą ofertę porównuj jako TCO na 3 lata, z rozbiciem na wdrożenie i utrzymanie — inaczej porównujesz tylko pierwszą fakturę.
Nie zawsze. SaaS wygrywa przy szybkim starcie, małym zakresie zmian i braku zespołu technicznego. Przy rosnącej skali i niestandardowych integracjach koszty dodatków, limitów API i prowizji potrafią przewyższyć utrzymanie PrestaShop czy WooCommerce. Policz oba warianty na 3 lata, nie na pierwszy rok.
Technicznie nie ma sztywnego limitu, ale o wydajności decyduje liczba wariantów, jakość hostingu, cache i sposób działania wtyczek. Przy kilkuset produktach i przeciętnym ruchu prosty WooCommerce działa poprawnie. Przy tysiącach wariantów trzeba policzyć katalog, wyszukiwarkę i zapytania do bazy — najlepiej testem na docelowym serwerze.
Tak, ale to projekt wdrożeniowy, a nie jedna operacja. Przenosi się produkty, warianty, klientów, zamówienia i — co najtrudniejsze — historię pozycjonowania: adresy URL i przekierowania. Dlatego pytanie o możliwość eksportu danych należy zadać przed wyborem platformy, a nie po dwóch latach.
Gdy klient kupuje hurtowo, potrzebuje faktury, indywidualnych cen i limitu zamówienia, a Ty obsługujesz zamówienia powtarzalne. Wtedy zwykły sklep B2C zwykle wymaga dobudowy modułów albo pracy ręcznej. Model mieszany (B2C i B2B na jednej instalacji) też trzeba sprawdzić pod kątem koszyka i widoczności cen.
Weź wersję testową i przejdź najważniejsze elementy: adresy URL produktów i kategorii, canonical, meta, dane strukturalne zgodne z wytycznymi Google oraz dostęp do edycji szablonu. Zmierz też Core Web Vitals na kategorii i karcie produktu. Wymagania zgłoś jako punkt odbioru, żeby nie poprawiać struktury adresów po uruchomieniu.
Zakres wdrożenia z liczbą godzin, właściciela kodu i repozytorium, listę integracji z nazwami systemów, warunki eksportu danych, SLA wsparcia oraz koszt rozwoju rocznego. Warto dopisać punkt decyzyjny o ewentualnym cofnięciu zmian. Bez tego porównujesz tylko cenę, a nie ryzyko.
Od zapisania modelu sprzedaży, liczby produktów i wariantów oraz celu na 12 miesięcy. Dopiero potem sprawdź progi decyzyjne i kryteria techniczne z tego artykułu. Jeśli chcesz przejść przez to sprawniej, zacznij od przeglądu sklepów internetowych, a kalkulację kosztów oprzyj na osobnym rozbiciu na wdrożenie i utrzymanie.
Jeśli chcesz zweryfikować wybór platformy przed podpisaniem umowy, opisz nam swój model sprzedaży i liczbę wariantów. Powiemy, które progi i integracje trzeba sprawdzić w Twoim przypadku.