Wdrożenie PrestaShop to nie jedna usługa, a trzy różne projekty: nowy sklep od zera, migracja ze starej platformy albo rozbudowa działającego sklepu. Dlatego pytanie „ile to kosztuje” bez podania liczby SKU, integracji i wariantu projektu nie ma sensu.
Poniżej rozkładamy temat na części, które da się porównać między ofertami: terminy w tygodniach, model rozliczenia w godzinach, siedem etapów projektu, lista błędów popełnianych przy wyborze wykonawcy i checklista odbioru.
To materiał organizacyjny — dla osoby, która ma ocenić, czy oferta jest wiarygodna, i rozliczyć wykonawcę z kolejnych kroków.
Wdrożenie PrestaShop to nie „instalacja sklepu”. To sekwencja prac, która zaczyna się od przygotowania serwera, a kończy kilka tygodni po uruchomieniu — na poprawkach i opiece. W praktyce zakres obejmuje: instalację na serwerze spełniającym wymagania (PHP 8.1 lub 8.2, MySQL 8, limity pamięci i czasu wykonania — aktualną listę trzyma dokumentacja dla deweloperów PrestaShop), konfigurację sklepu (waluty, podatki, strefy, reguły cen i rabatów), wdrożenie szablonu, integracje, migrację danych, testy i uruchomienie produkcyjne.
Kluczowe rozróżnienie: „wdrożenie” oznacza trzy różne projekty i miesza je niemal każdy zapytanie ofertowe.
Niezależnie od wariantu, w każdym porządnym wdrożeniu PrestaShop powtarza się ten sam rdzeń: domena i certyfikat SSL, środowisko staging (kopia produkcyjnej bazy i plików, na której testujesz zmiany przed wypchnięciem), automatyczne kopie zapasowe bazy i plików z harmonogramem, konfiguracja płatności i kurierów. Integracje kurierskie warto zaplanować osobno — przykład: organizacja wdrożenia InPost w PrestaShop 9 to nie „włączenie modułu”, a mapowanie statusów zamówień i generowanie etykiet.
Czego wdrożenie nie obejmuje: copywritingu opisów produktów, sesji zdjęciowych, kampanii Google Ads i Meta, treści blogowych. Jeśli oferta zawiera te pozycje w cenie, porównujesz dwa różne zakresy.
| Element | W zakresie wdrożenia | Komentarz |
|---|---|---|
| Instalacja, konfiguracja, szablon | Tak | Wariant gotowego szablonu vs. szablon custom to różnica tygodni |
| Integracje płatności i kurierów | Tak | Każda bramka ma własny proces onboardingu |
| Migracja produktów, klientów, zamówień | Tak, w wariancie migracji | Historia zamówień bywa najdroższym elementem |
| Domena, SSL, staging, kopie zapasowe | Tak | Bez tego nie ma czego odbierać |
| Opisy produktów i zdjęcia | Nie | Dane po stronie klienta — to główne źródło opóźnień |
| Kampanie Ads i treści blogowe | Nie | Osobna usługa, osobny budżet |
Terminy podajemy w tygodniach kalendarzowych, bo projekt rzadko stoi na kodzie — stoi na materiałach i akceptacjach. Dla orientacji, jak rozkłada się praca w najprostszym scenariuszu: instalacja i konfiguracja 3–5 dni, wdrożenie i układanie gotowego szablonu 5–10 dni, integracje płatności i kurierów 3–5 dni, testy zamówień 3–5 dni. Reszta to wprowadzanie produktów i decyzje.
Migracja z WooCommerce, Shopera albo autorskiego CMS to 6–12 tygodni. Rozpiętość wynika z trzech liczb: ile jest SKU, ilu klientów i jak długa jest historia zamówień. Eksport 5 tys. produktów to godziny. Eksport 200 tys. zamówień z pozycjami to projekt sam w sobie — trzeba przeliczyć ceny, podatki i statusy, a potem zestawić sumy kontrolne ze starym systemem.
Sklep B2B z ERP i cennikami indywidualnymi: 10–16 tygodni. Synchronizacja stanów magazynowych, cenniki per kontrahent, dokumenty i terminy płatności — każde z tych zadań wymaga uzgodnienia z działem księgowości klienta.
Co realnie wydłuża kalendarz: brak gotowych opisów i zdjęć, integracja z niestandardowym ERP (albo z systemem, do którego nie ma dokumentacji API), oczekiwanie na certyfikację bramki płatniczej i weryfikację KYC, a także decyzje po stronie klienta — pojedyncza akceptacja potrafi zająć dwa tygodnie.
Dlatego rozdzielaj dwie rzeczy: czas pracy dewelopera (np. 90 godzin) i czas kalendarzowy projektu (np. 8 tygodni). Pierwsze jest w ofercie, drugie zależy od Ciebie. Jak wygląda harmonogram krok po kroku, opisujemy w materiale o wdrożeniach i migracjach PrestaShop dla firm.
| Scenariusz | Typowy termin | Główne ryzyko opóźnienia |
|---|---|---|
| Nowy sklep do ok. 500 SKU, gotowy szablon | 3–6 tygodni | Brak opisów i zdjęć produktów |
| Migracja z WooCommerce / Shopera / autorskiego CMS | 6–12 tygodni | Jakość danych w starym systemie, historia zamówień |
| Sklep B2B z integracją ERP i cennikami indywidualnymi | 10–16 tygodni | Niestandardowe API ERP, uzgodnienia cen z klientem |
| Zakres dodatkowy: certyfikacja bramki płatniczej | +1–3 tygodnie | Weryfikacja KYC i regulaminy po stronie operatora |
Uczciwa wycena wdrożenia to iloczyn: liczba godzin × stawka godzinowa. W Polsce stawki agencji i doświadczonych freelancerów mieszczą się zwykle w przedziale 120–200 zł netto za godzinę. Sztywny „cennik za sklep” oznacza albo ukryty bufor na nieprzewidziane prace, albo zakres ucięty tak, żeby się domknął.
Punkt odniesienia na podstawie typowych projektów: prosty sklep 60–120 godzin, migracja 150–300 godzin, wdrożenie B2B z ERP 300–600 godzin. Rozpiętość w każdym przedziale to efekt konkretów, nie widzimisię wykonawcy.
Co podnosi koszt najbardziej: integracje niestandardowe (moduł pisany od zera to 20–60 godzin, gotowy moduł z Marketplace to zwykle 2–8 godzin konfiguracji), migracja historii zamówień, wielojęzyczność i wielowalutowość (tłumaczenia, podatki, reguły zaokrągleń) oraz wielosklepowość w PrestaShop. Zanim zaakceptujesz ofertę, sprawdź, czy wykonawca policzył modyfikacje szablonu — to pozycja, która najczęściej wypada z estymacji.
Koszty poza wdrożeniem, o których zapomina większość zestawień: licencje płatne (szablon jednorazowo, moduły — czasem subskrypcja roczna), hosting lub VPS (zwykle 100–400 zł netto miesięcznie dla sklepu z ruchem), certyfikat SSL (darmowy lub płatny), prowizje i ewentualne opłaty aktywacyjne bramki płatniczej. Wybór i konfigurację modułów po stronie PrestaShop warto wpisać do zakresu, bo „dokupimy później” kończy się dublowaniem funkcji.
Dlaczego wycena „na oko” się rozjeżdża? Bo bez audytu nikt nie wie, ile w starym sklepie jest pól niestandardowych, zmodyfikowanych modułów i wyjątków w cenach. Poprawny proces jest dwuetapowy: (1) płatny audyt lub analiza 4–8 godzin, zakończona dokumentem zakresu i listą integracji; (2) oferta z estymacją godzinową rozbitą na etapy, z buforem 10–15% i rozliczeniem w sprintach wraz z raportem godzin.
| Wariant | Szacowane godziny | Widełki netto przy 120–200 zł/h |
|---|---|---|
| Prosty sklep, gotowy szablon | 60–120 h | 7 200–24 000 zł |
| Migracja z innej platformy | 150–300 h | 18 000–60 000 zł |
| B2B z integracją ERP i cennikami | 300–600 h | 36 000–120 000 zł |
Kolejność etapów jest w każdym projekcie podobna — różni się ich długość i to, ile pracy przypada po Twojej stronie. Po każdym etapie powinien powstać artefakt, który da się odebrać. Jeśli wykonawca nie umie go pokazać, etap się nie skończył.
| Etap | Rezultat do odbioru | Widełki czasu (sklep do 500 SKU) |
|---|---|---|
| 1. Audyt i wymagania | Lista funkcji, integracji, szablonów dokumentów | 1–2 tygodnie |
| 2. Środowisko | Staging, SSL, kopie zapasowe, dostęp do panelu | 2–3 dni |
| 3. Instalacja i konfiguracja | Działający sklep z podatkami i wysyłkami | 3–5 dni |
| 4. Dane | Produkty, kategorie, zdjęcia, stany, klienci | 1–2 tygodnie |
| 5. Integracje | Płatności, kurierzy, ERP na stagingu | 1–3 tygodnie (zależne od zewnętrznych) |
| 6. Testy | Lista testów z wynikami, zgłoszone błędy | 1–2 tygodnie |
| 7. Go-live i opieka | Produkcja, monitoring, umowa SLA | 2–3 dni + opieka |
Etap 5 harmonogramu najczęściej się rozjeżdża nie z winy wykonawcy, a z powodu dokumentów i dostępów po stronie firmy. Realnie: kurierzy — InPost (ShipX API) wymaga podpisanej umowy, danych organizacji do API oraz konfiguracji Punktów Pakurowania widocznych w koszyku i na mapie; DPD i DHL wymagają numerów klienta, danych nadawcy i dostępu do ich usług webowych. Samo oczekiwanie na nadanie danych dostępowych to zwykle 3–10 dni roboczych. Praktyczne rozwinięcie tematu znajdziesz w materiale o integracji InPost z PrestaShop 9.
Płatności — bramka kartowa, BLIK, Przelewy24 lub PayU. Weryfikacja firmy (NIP, KRS, rachunek firmowy, czasem adres strony) i aktywacja to zwykle 1–5 dni roboczych. Uwaga na limity transakcyjne na start i na to, że zmiana rachunku bankowego uruchamia weryfikację ponownie.
ERP i księgowość — tu najdroższy jest nie kod, a ustalenie zasad. Do ustalenia przed pierwszym commitem:
Zasada: każdą integrację uruchamiasz na stagingu na danych testowych. Nigdy prosto na produkcji.
Gotowa wtyczka czy własny moduł? Trzy płatne rozszerzenia, które dublują funkcje i kłócą się przy aktualizacjach, potrafią kosztować więcej w utrzymaniu niż jeden moduł pisany pod Twój proces. Policz koszt roczny (licencje + godziny na aktualizacje), nie tylko zakup.
| Integracja | Co musi dostarczyć firma | Typowe oczekiwanie |
|---|---|---|
| InPost ShipX | Umowa, dane organizacji do API, dane nadawcy | 3–10 dni roboczych |
| DPD / DHL | Umowa, numery klienta, dane nadawcy i płatnika | 3–10 dni roboczych |
| Płatności (P24/PayU, karta, BLIK) | Weryfikacja firmy, rachunek bankowy, dane strony | 1–5 dni roboczych |
| ERP | Specyfikacja pól, statusy, decyzja o kierunku synchronizacji | 1–2 tygodnie ustaleń |
Migrację zaczynasz od inwentaryzacji adresów, nie od importu produktów. Zbierz dwie listy: wszystkie URL-e z crawla (Screaming Frog, Xenu) oraz adresy z eksportu Google Search Console — osobno strony z wyświetleniami z ostatnich 12 miesięcy. Suma tych dwóch zbiorów to Twoja lista kontrolna. Adresy bez wyświetleń i bez linków można świadomie porzucić.
Następnie mapowanie 1:1: produkt → produkt, kategoria → kategoria, wpis lub strona CMS → nowa strona, strona informacyjna → nowa strona. Przekierowania 301 ustaw w .htaccess lub w module przekierowań, ale pilnuj dwóch rzeczy: żadnych łańcuchów (A→B→C) i żadnych 302 w miejscu trwałych przenosin. Parametry filtrowania i sortowania (np. ?orderby=, ?page=) zostaw poza indeksem — mają znacznik canonical lub noindex, a nie przekierowanie na kategorię.
Metadane przenosisz przed startem, nie „po”: title i description dla produktów i kategorii, nagłówki H1, teksty kategorii. To one odpowiadają za dopasowanie do zapytań. Na nowym sklepie zadbaj też o dane strukturalne produktu i okruszków — Google opisuje obsługiwane formaty w galerii danych strukturalnych.
Czego nie przenosić bezpośrednio: starych ID produktów bez mapowania na nowe, wpisów przypisanych do nieistniejących kategorii (osierocone produkty wypadają z nawigacji), parametrów filtrowania w indeksie, pustych stron tagów.
Po starcie: raport „Nie znaleziono (404)” w Search Console przez pierwsze 4–6 tygodni, kontrola sitemap.xml i robots.txt, ponowne zgłoszenie mapy witryny. Nie zmieniaj jednocześnie struktury URL i treści — przy spadku nie odróżnisz przyczyn. Cały proces organizacyjny opisujemy szerzej przy wdrożeniach i migracjach PrestaShop.
| Element | Przed startem | Po starcie |
|---|---|---|
| Adresy URL | Crawl + eksport z Search Console, mapa przekierowań 301 | Raport 404 w Search Console, korekty przekierowań |
| Metadane | Title, description, H1, teksty kategorii | Kontrola przypadkowych duplikatów |
| Indeks | Sitemap.xml, robots.txt, canonicale, noindex na filtrach | Ponowne zgłoszenie mapy witryny |
| Dane strukturalne | Product, BreadcrumbList na szablonach | Test wyników z witryny |
Większość problemów nie wychodzi w dniu oddania sklepu, tylko trzy tygodnie później — przy pierwszej aktualizacji albo szczycie sprzedaży. Poniżej siedem rzeczy, które warto sprawdzić jeszcze przed podpisaniem odbioru. Każda ma konkretny test, który zajmuje kilka minut.
php -v na koncie. PrestaShop 9 nie uruchomi się na starym PHP 7.x — dokładną tabelę wymagań dla konkretnej wersji znajdziesz w dokumentacji dla deweloperów PrestaShop. Uwaga na rozjazd: sklep działa, ale moduły płatności już nie.Te punkty to też dobra lista pytań na rozmowę o wdrożeniach PrestaShop — wykonawca z realnym zapleczem odpowie na nie bez przygotowania.
Dzień startu to najgorszy moment na odkrywanie, że maile idą do spamu, a płatność nie wraca do sklepu po anulowaniu. Poniższą listę przechodzi się na stagingu, a potem powtarza najważniejsze punkty na produkcji — po przełączeniu DNS i wyłączeniu trybu „w budowie”.
| Obszar | Test | Co uznajemy za zaliczone |
|---|---|---|
| Płatności | Zamówienie na 1 zł realną kartą, potem anulowanie | Pieniądze wracają, status w sklepie się zgadza |
| Wysyłka | Nadanie paczki do siebie | Etykieta się generuje, tracking trafia do klienta |
| Maile | Reset hasła i potwierdzenie na Gmail/Outlook | Brak w spamie, poprawny nadawca i linki |
| Wydajność | Mobile, 4G, karta produktu i koszyk | Karta ładuje się akceptowalnie, brak skoków layoutu |
| Bezpieczeństwo | Wejście jako gość, próba /admin | Brak komunikatów błędów, HTTPS wszędzie |
Samodzielny start ma sens w wąskim przypadku: katalog rzędu stu–kilkuset SKU, jeden język i waluta, gotowy szablon, brak integracji z magazynem i księgowością, ograniczony budżet i czas. Wtedy instalacja PrestaShop z panelu hostingu, konfiguracja kilku modułów i wpisanie produktów to realny scenariusz na kilka dni pracy. Cena: robisz też za staging, backupy i aktualizacje.
Deweloper jest potrzebny, gdy pojawia się migracja z danymi (tysiące SKU, klienci, historia zamówień, zachowanie starych adresów przez przekierowania 301), integracja z ERP lub systemem magazynowym, moduły pisane pod proces firmy albo wydajność przy dużym katalogu z wariantami. To prace, w których błąd kosztuje więcej niż stawka godzinowa.
| Sytuacja | Samodzielnie | Z deweloperem |
|---|---|---|
| Nowy sklep, mały katalog, gotowy szablon | Tak | Opcjonalnie |
| Migracja z innej platformy z danymi | Nie | Tak |
| Integracja ERP, magazyn, wiele języków | Nie | Tak |
| Aktualizacje i bezpieczeństwo po starcie | Własne godziny | Ustalane w SLA |
Cztery pytania, które odsieją pośredników bez zaplecza:
Dorzuć pytanie o dostępy: repozytorium, panel hostingu i licencje modułów powinny być po Twojej stronie albo przynajmniej w Twojej dyspozycji. Praca bezpośrednio z deweloperem skraca drogę decyzyjną i sprawia, że ktoś realnie odpowiada za utrzymanie — a nie tylko za fakturę za wdrożenie. Więcej o samej platformie znajdziesz w sekcji PrestaShop.
Porównywanie ofert o różnym zakresie — jedna zawiera migrację danych i integracje, druga tylko instalację z szablonem. Kwoty wyglądają podobnie, ale dotyczą różnych projektów.
Jak wykryć: Poproś każdego wykonawcę o rozbicie wyceny na etapy i wypisanie integracji z nazwy. Jeśli oferta to jedna kwota bez zakresu, nie da się jej porównać z żadną inną.
Jak naprawić: Ustal wspólny minimalny zakres dla wszystkich ofert: domena, SSL, staging, kopie zapasowe, konfiguracja płatności i kurierów, migracja danych, testy. Dopiero na tym samym zakresie porównuj stawki i liczbę godzin.
Wycena „na oko” bez audytu. Wykonawca rzuca kwotę przez telefon, nie pytając o liczbę SKU, historię zamówień ani system ERP.
Jak wykryć: Jeśli nikt nie zadał Ci pytań o dane, integracje i wersję platformy, z której migrujesz, to nie była wycena, tylko szacunek orientacyjny.
Jak naprawić: Przejdź proces dwuetapowy: najpierw audyt i zbieranie wymagań (płatny lub wliczony w projekt), potem wycena z liczbą godzin i spisanymi założeniami. Założenia są ważniejsze niż sama kwota — to na ich podstawie rozliczasz rozjazdy.
Brak środowiska staging i planu kopii zapasowych. Prace idą od razu na produkcji, a rollback nie istnieje.
Jak wykryć: Jedno pytanie do wykonawcy: „na czym będziemy testować przed wdrożeniem na produkcję?”. Odpowiedź „na produkcji, po godzinach” oznacza ryzyko przestoju sklepu.
Jak naprawić: Wymagaj stagingu odseparowanego od produkcji oraz kopii zapasowej przed każdą większą zmianą, z jasno opisaną procedurą przywrócenia.
Zlecający nie ma gotowych danych produktowych, a harmonogram zakłada, że ma. Import stoi, termin się przesuwa, a faktura za godziny rośnie.
Jak wykryć: Sprawdź, czy masz produkty w sensownym CSV, zdjęcia w jednym miejscu i kto jest właścicielem opisów. Opisy w mailach i zdjęcia w wątkach to sygnał ostrzegawczy.
Jak naprawić: Ustal format pliku wejściowego z wykonawcą, wskaż jedną osobę odpowiedzialną po swojej stronie i wpisz przygotowanie danych jako zadanie z datą — nie jako „do ogarnięcia po drodze”.
Migracja bez ustalonego zakresu: produkty idą, a klienci i historia zamówień zostają na starej platformie. Nikt nie wie, co z hasłami klientów.
Jak wykryć: Zapytaj wprost, czy po starcie klient będzie musiał resetować hasło i czy stare zamówienia będą widoczne w panelu. Brak odpowiedzi to brak decyzji projektowej.
Jak naprawić: Spisz zakres migracji pozycja po pozycji: produkty, kategorie, zdjęcia, klienci, adresy, zamówienia. Osobno opisz sposób obsługi haseł — to element, który najczęściej umyka.
Testy ograniczone do przeklikania strony głównej. Płatność, zwroty, maile transakcyjne i wydajność sprawdzają się dopiero u pierwszych klientów.
Jak wykryć: Poproś o listę scenariuszy testowych jeszcze przed startem prac. Jeśli jej nie ma, testy będą uznaniowe.
Jak naprawić: Ustal testy akceptacyjne z punktami: pełna ścieżka zakupowa, płatność testowa i realna na symboliczną kwotę, zwrot, wysyłka, maile transakcyjne, wydajność i SEO techniczne po wdrożeniu.
Wdrożenie PrestaShop da się porównywać tylko wtedy, gdy zestawiasz te same elementy: zakres, terminy, liczbę godzin i stawkę. Bez tego dwie oferty różniące się o 30% mogą dotyczyć zupełnie innych projektów.
Poproś o rozbicie wyceny na etapy, listę integracji z nazwami i spisane założenia. To trzy dokumenty, które pozwalają rozliczyć wykonawcę z efektów, a nie z deklaracji.
Największe ryzyko nie leży w kodzie, a w braku danych po stronie klienta i nieustalonym zakresie migracji. One odpowiadają za większość przesunięć terminów.
Zależy od wariantu. Nowy sklep do około 500 SKU na gotowym szablonie to zwykle 3-6 tygodni. Migracja z WooCommerce, Shoper lub autorskiego CMS to 6-12 tygodni, w zależności od liczby SKU, klientów i historii zamówień. Sklep B2B z integracją ERP i cennikami indywidualnymi to 10-16 tygodni.
Te widełki dotyczą pracy dewelopera. Czas oczekiwania na Twoje materiały i akceptacje liczy się osobno i potrafi wydłużyć projekt bardziej niż samo kodowanie.
Rozliczenie opiera się na liczbie godzin pomnożonej przez stawkę — typowo 120-200 zł netto za godzinę w Polsce. Prosty sklep to około 60-120 godzin, migracja 150-300 godzin, wdrożenie B2B z ERP 300-600 godzin.
Do tego dochodzą koszty poza wdrożeniem: płatne szablony i moduły, hosting lub VPS, certyfikat SSL, ewentualne opłaty bramki płatniczej. Dlatego oferta podana jako jedna kwota bez rozbicia na godziny jest trudna do zweryfikowania.
Tak, pod warunkiem że migracja obejmuje mapę przekierowań 301 ze starych adresów na nowe, aktualną sitemapę i poprawne robots.txt. Bez tego tracisz część ruchu bezpowrotnie.
Przekierowania przygotowuje się przed przełączeniem DNS i testuje na stagingu. Warto też sprawdzić dane strukturalne i Core Web Vitals po wdrożeniu — Google opisuje te zależności w swojej dokumentacji.
Sam silnik jest open source i nie wymaga licencji. Płacisz za pracę wdrożeniową, hosting, szablony i moduły — część z nich jest płatna jednorazowo, część w modelu subskrypcji.
Uważaj na moduły „wszystko w jednym”, które dublują funkcje i utrudniają późniejsze aktualizacje. Lepiej mieć mniej rozszerzeń, ale zgodnych z wersją, na której startujesz.
Nie musisz mieć wszystkich, ale musisz mieć ustalony format i osobę odpowiedzialną. Import techniczny wymaga pliku CSV z polami, które da się zmapować — nie opisów rozrzuconych po mailach.
Najczęstszy scenariusz opóźnienia to właśnie brak danych produktowych. Wpisz przygotowanie treści jako zadanie z datą po Twojej stronie, inaczej termin wdrożenia nie ma pokrycia.
Najbezpieczniej etapami, powiązanymi z rezultatami: audyt i wymagania, środowisko, konfiguracja i dane, integracje, testy, uruchomienie. Każdy etap ma konkretny efekt, który da się sprawdzić.
Płatność z góry za całość utrudnia reakcję, jeśli projekt się rozjeżdża. Jeśli wykonawca proponuje taki model, poproś przynajmniej o harmonogram z kamieniami milowymi.
Powinno obejmować co najmniej krótki okres wsparcia po starcie — zwykle kilka dni lub kilkanaście godzin w cenie projektu. To czas na reakcję, jeśli coś wyjdzie dopiero u pierwszych klientów.
Zapytaj wprost, ile godzin wsparcia jest w ofercie i kto odbiera zgłoszenia po odbiorze. Długoterminowa opieka to zwykle osobna usługa, ale granica musi być jasno opisana.
Jeśli chcesz sprawdzić, jak Twoja sytuacja wygląda na tle tych widełek, opisz nam zakres: liczbę SKU, platformę, z której migrujesz, i integracje. Odpowiemy konkretem — ile godzin, w jakich etapach i co musi być gotowe po Twojej stronie. Punktem wyjścia może być nasza strona o wdrożeniach PrestaShop.