Wdrożenie sklepu PrestaShop we Wrocławiu to projekt organizacyjny, a nie jedna instalacja. Najwięcej opóźnień nie wynika z kodu, tylko z braku decyzji, dostępów do paneli i jasnej listy integracji. Poniżej porządkujemy część organizacyjną: kolejność prac, podział odpowiedzialności między deweloperem a właścicielem sklepu oraz sygnały, że projekt zaczyna się ślizgać. Zakres, koszty i integracje omawiamy w pozostałych sekcjach artykułu.
Instalacja PrestaShop to kwestia godziny: wgranie paczki, baza MySQL, katalog z prawami zapisu, dane administratora. Wdrożenie to projekt, w którym tę instalację trzeba doprowadzić do stanu, w którym sklep przyjmuje realne pieniądze i nie generuje pracy ręcznej.
Minimum, bez którego nie ma wdrożenia:
Specyfika Wrocławia bierze się z rynku, nie z kodu. Lokalna logistyka to InPost i duże sortownie pod miastem – klient w mieście oczekuje dostawy next-day, a punkt odbioru bywa argumentem sprzedażowym. Firmy B2B chcą cen netto, rabatów grupowych i płatności z terminem; PrestaShop domyślnie tego nie ma, potrzebne są grupy klientów i moduły. Bliskość rynków czeskiego i niemieckiego sprawia, że wielojęzyczność (CZ, DE) planuje się na starcie, a nie dokłada po roku.
Migracja ma sens, gdy masz bazę klientów, historię zamówień i pozycje w Google. Budowa od zera – gdy stara platforma nie generuje sprzedaży albo katalog jest mały i nie ma czego ratować.
| Zakres | Instalacja | Wdrożenie gotowe do sprzedaży |
|---|---|---|
| Czas | 30–60 minut | 6–12 tygodni |
| Kto pracuje | jedna osoba technicznie | deweloper + właściciel sklepu + księgowość/ERP |
| Efekt | panel i pusty sklep | sklep przyjmujący zamówienia i płatności |
| Koszt | 0 zł poza hostingiem | 6–80+ tys. zł netto |
Wycena wdrożenia PrestaShop nie istnieje jako jedna liczba. Poniższe widełki to zakresy, które przyjmujemy w wycenach na 2026, przy stawce 120–180 zł/h netto. Wariant zależy od liczby integracji, nie od liczby produktów.
Rozbicie na godziny, na podstawie typowego projektu standardowego:
Suma daje 113–286 h i realnie ląduje w przedziale 15–35 tys. zł. Starter to zwykle 40–80 h, rozbudowany – 300 h i więcej.
Co podnosi cenę najbardziej: moduły pisane od zera pod nietypowy proces (20–60 h każdy), integracja z ERP (mapowanie pól, stany, faktury, korekty), migracja z WooCommerce lub Magento razem z przekierowaniami i hasłami klientów, wielojęzyczność (osobne tłumaczenia, podatki, ceny), konfiguracja B2B (limity kredytowe, ceny grupowe, zamówienia na zapytanie).
Dlaczego rozliczenie godzinowe z widełkami jest bezpieczniejsze niż cennik z sufitu? Bo cena „15 000 zł za sklep” zawsze kończy się albo dopłatami, albo niedokończonym zakresem. Umów stawkę, widełki godzinowe i rejestr czasu (Harvest, Toggl) z raportem co tydzień – widzisz, że projekt zbliża się do górnej granicy, i decydujesz o zakresie, zanim skończą się pieniądze.
Opieka po wdrożeniu: 500–2500 zł/mies. netto. 500–800 zł to aktualizacje i kopie bez gwarancji czasu reakcji. 1200–1800 zł to SLA reakcji w kilka godzin i pula drobnych zmian. 2000–2500 zł dotyczy sklepów z ERP i sezonem szczytowym – z dyżurem i szybką reakcją na błąd płatności.
| Wariant | Zakres | Czas prac | Widełki netto |
|---|---|---|---|
| Starter | 1 język, gotowy szablon, 3–4 płatności, InPost i DPD, bez ERP | 40–80 h | 6–12 tys. zł |
| Standard | szablon po adaptacji, ERP lub magazyn, GA4, feedy, B2B w podstawie | 120–250 h | 15–35 tys. zł |
| Rozbudowany | moduły pisane pod proces, wielojęzyczność, ERP, migracja, integracje niestandardowe | 300 h i więcej | 40–80+ tys. zł |
Kolejność etapów jest ważniejsza niż tempo. Poniżej wersja, która sprawdza się w projektach 6–12-tygodniowych.
Lista testów przed startem – bez tego nie ma go-live:
Raport w piątek, demo na stagingu, płatności przypisane do kamieni milowych. Jeśli w dwóch kolejnych raportach ten sam punkt jest „w toku”, projekt się ślizga – reaguj wtedy, nie po terminie startu.
| Etap | Czas | Deweloper | Właściciel sklepu |
|---|---|---|---|
| Analiza | 3–5 dni | brief, wycena godzinowa | decyzje o kurierach, płatnościach, ERP, językach; dostępy |
| Staging | 1–2 dni | subdomena, kopia bazy, noindex | hasło dostępowe, akceptacja środowiska |
| Konfiguracja | 1–2 tyg. | ustawienia, VAT, szablon | treści, zdjęcia, regulaminy |
| Integracje | 1–3 tyg. | płatności, kurierzy, ERP, GA4 | dane API, konta, decyzje o mapowaniu |
| Migracja | 3–10 dni | import danych, przekierowania 301 | lista starych adresów URL, weryfikacja cen |
| Testy | 3–7 dni | checklista i poprawki | zakupy testowe, akceptacja |
| Start | 1 dzień + 30 dni | DNS, monitoring, wsparcie | obsługa zamówień, faktury |
Zacznij od liczb, nie od nazw platform. Trzy pytania wystarczą, żeby zawęzić wybór: ile masz produktów razem z wariantami, ile systemów zewnętrznych musi wymieniać dane ze sklepem i kto po wdrożeniu będzie dodawał opisy oraz zdjęcia.
W skrócie: duży katalog, B2B z cennikami po zalogowaniu, ERP i wiele sklepów na jednym zapleczu — PrestaShop. Prosty sklep do kilkuset produktów, mocny content i marketing oparty o WordPressa — WooCommerce.
Jeśli nadal się wahasz, rozłóż decyzję na tabelę kryteriów i oceń je punktowo: PrestaShop czy WooCommerce: przewodnik dla początkujących 2026.
| Kryterium | WooCommerce | PrestaShop |
|---|---|---|
| Liczba SKU | do ok. 300, prosty katalog | 1000+, warianty, rozbudowane filtry |
| ERP i B2B | integracje częściej szyte na miarę | więcej gotowych modułów |
| Wielojęzyczność | przez pluginy, osobne licencje | natywnie w jednej instalacji |
| Edycja treści | mocna strona: blog, landingi | słabsza, wymaga przyzwyczajenia |
| Hosting | często wystarcza zwykły hosting | potrzeba więcej RAM i tuningu |
Integracje to miejsce, w którym wdrożenie najczęściej się rozjeżdża. Każda ma dwa kierunki przepływu danych i własne pułapki.
Zapisz kierunek przepływu raz i trzymaj się go: stany magazynowe i ceny płyną z ERP do sklepu, a zamówienia i dane klienta ze sklepu do ERP. Najczęstsze pułapki: duplikaty stanów, gdy produkt jest edytowany równolegle w ERP i w panelu PrestaShop, mapowanie statusów jeden do jednego bez stanów pośrednich oraz brak webhooków, przez co synchronizacja chodzi raz na 15 minut i ktoś przepisuje zamówienia ręcznie.
Szczegóły techniczne modułów i hooków znajdziesz w dokumentacji dla deweloperów PrestaShop. Po wdrożeniu sprawdź, czy zdarzenia zakupowe nie liczą się podwójnie: PrestaShop GA4: wdrożenie bez dublowania danych.
| Obszar | Co ustalić przed wdrożeniem | Typowa pułapka |
|---|---|---|
| Płatności | webhook i mapowanie statusów | zamówienia bez potwierdzenia płatności |
| InPost | mapa punktów, API etykiet | brak wybranego punktu w zamówieniu |
| DPD / DHL | kto generuje etykiety, skąd tracking | statusy ustawiane ręcznie |
| ERP | kierunek przepływu danych | duplikaty stanów i błędne statusy |
| Feed hurtowni | częstotliwość i mapowanie pól | nadpisywanie ręcznych opisów |
Migracja to nie kopiowanie bazy. Najpierw zbierz adresy URL ze starego sklepu: sitemap.xml, logi serwera z ostatnich 3–6 miesięcy i eksport z Search Console. Na tej podstawie powstaje tabela mapowania URL → nowy adres. Bez niej Google zobaczy 404 na stronach, które zarabiały.
Testy po migracji: wydajność (czas odpowiedzi serwera i Core Web Vitals), indeksacja (sitemap, brak 404, kontrola w Search Console), GA4 (czy transakcje nie dublują się w raportach), płatności (transakcja testowa i zwrot), e-maile transakcyjne oraz etykiety kurierskie.
Najczęściej niedoszacowanym elementem jest hosting — VPS dla e-commerce zamiast taniego hostingu. Sprawdź też, co po przenosinach nadal spowalnia sklep: PrestaShop: krytyczne błędy spowalniające sklep.
| Etap | Co przenosimy | Na co uważać |
|---|---|---|
| URL i SEO | mapowanie adresów, przekierowania 301 | jedno przejście, brak masowych przekierowań na stronę główną |
| Treści | tytuły, meta, opisy kategorii | import CSV bez meta kasuje pozycje |
| Dane | produkty, kategorie, klienci, zdjęcia | reset haseł klientów |
| Zamówienia | historia zakupów i statusów | utrata kontekstu reklamacji |
| Testy | płatności, GA4, etykiety, wydajność | dublowane transakcje i wolny serwer |
Zanim wybierzesz hosting, sprawdź, czy spełnia twarde wymagania PrestaShop 8: PHP 8.1 lub nowsze, MySQL 8.0 albo MariaDB 10.6+, memory_limit minimum 256M (realnie 512M), max_execution_time 300 s przy importach, upload_max_filesize 64M, włączony OPcache i HTTPS. Aktualne widełki i uwagi do wersji znajdziesz w dokumentacji dla deweloperów PrestaShop. Jeśli hosting nie pozwala zmienić tych parametrów w panelu, nie podpisuj rocznej umowy — zmiana PHP to najczęstsza przyczyna „sklep działał, a dziś się wywala”.
Shared hosting przestaje wystarczać w trzech momentach: gdy importujesz katalog powyżej ok. 1000 pozycji i cron się urywa, gdy ruch z kampanii powoduje chwilowe blokady procesów PHP, oraz gdy potrzebujesz SSH, Composera i własnego tuningu MySQL. Wtedy wchodzi VPS 4 vCPU / 8 GB RAM na dyskach NVMe (rząd 150–300 zł miesięcznie; ceny zmieniają się, weryfikuj u dostawcy) z Nginx, PHP-FPM i własnym MySQL. Powyżej kilku tysięcy zamówień miesięcznie rozdziela się bazę i aplikację na osobne maszyny.
Jeśli przenosisz sklep z taniego planu, kolejność ma znaczenie: najpierw kopie, potem środowisko docelowe, na końcu DNS i przekierowania. Opisujemy to w artykule o migracji na VPS dla e-commerce. A jeśli strona już działa wolno, zanim zmienisz serwer, przejrzyj listę typowych błędów zebranych w tekście PrestaShop: krytyczne błędy spowalniające sklep — część z nich to konfiguracja, nie sprzęt.
| Wariant | Dla kogo | Kiedy przestaje wystarczać |
|---|---|---|
| Shared hosting | do ok. 300–500 SKU, kilkanaście zamówień dziennie | importy przez cron, brak Redis, brak zmiany php.ini |
| VPS 4 vCPU / 8 GB RAM / NVMe | 1 000–20 000 SKU, ruch kampanijny | brak przy bardzo dużym ruchu na jednej bazie |
| Dedykowany lub rozdzielone serwery | od kilku tysięcy zamówień miesięcznie | gdy i tak potrzebny CDN i osobna baza |
Wrocław to dobry rynek, ale liczba firm, które „robią sklepy”, nie mówi nic o jakości. Zanim podpiszesz umowę, zadaj dziesięć pytań i zapisz odpowiedzi — będą podstawą zakresu prac.
Czerwone flagi. Brak widełek i zakresu („wycena po rozmowie, na końcu”). Brak etapu testów i odbioru — kod idzie od razu na produkcję. Znikający kontakt po wdrożeniu i faktury za każdy telefon. Nieprzekazanie dostępów: domeny, hostingu, panelu PrestaShop, konta GA4. Płatność 100% z góry przy harmonogramie bez etapów.
Czy praca zdalna z zespołem spoza Wrocławia jest OK? Tak, jeśli są: umowa z SLA, dostęp do stagingu, ustalony kanał komunikacji i godziny odpowiedzi, repozytorium z historią zmian oraz osoba decyzyjna po Twojej stronie. Problemem nie jest odległość, ale brak przekazania wiedzy. Zapytaj też, kto wdroży pomiar — jeśli analitykę robi ktoś inny niż deweloper, ustal to przed startem, żeby nie dublować zdarzeń; opisujemy to w materiale PrestaShop GA4: wdrożenie bez dublowania danych. W umowie wpisz okres gwarancyjny 3–6 miesięcy na wdrożone funkcje i wyłącz winę klienta (zmiany w kodzie poza wykonawcą).
Wdrożenie kończy się odbiorem, a sklep zaczyna pracować. SLA powinno być spisane w godzinach, nie w ogólnikach.
Kampanie to osobny rozdział. Przy Black Friday zamroź wdrożenia na 7 dni przed startem. Na 2 tygodnie wcześniej: test obciążeniowy, weryfikacja limitów u operatora płatności, sprawdzenie kolejki e-maili i progów darmowej dostawy. W dniu wyprzedaży ktoś musi być pod telefonem — to punkt w SLA, nie uprzejmość.
Optymalizacja szybkości ma sens tylko mierzona. Ustal punkt odniesienia (Core Web Vitals z web.dev — LCP, INP, CLS) i wracaj do niego co kwartał; bez pomiaru nie wiesz, czy nowy moduł nie zjadł zysku z cache. Ten sam porządek pracy — etapy, odbiory i opieka — opisaliśmy na przykładzie innego rynku w tekście o wdrożeniu sklepu WooCommerce bez opóźnień. Warto przeczytać, jeśli porównujesz platformy przed wyborem kierunku.
| Priorytet | Przykład zgłoszenia | Czas reakcji | Czas naprawy |
|---|---|---|---|
| P1 | sklep nie odpowiada, brak zamówień | 30 min, 24/7 | do 4 h |
| P2 | nie działa płatność lub kurier | 2 h w godzinach pracy | do 1 dnia |
| P3 | błąd w module, zła cena promocyjna | 1 dzień roboczy | do 3 dni |
| P4 | zmiana treści, nowy banner | 3 dni robocze | wg kolejki |
Traktowanie instalacji PrestaShop jako wdrożenia sklepu. Klient dostaje działające demo i zakłada, że sprzedaż ruszy po wgraniu zdjęć.
Jak wykryć: Po instalacji nie ma skonfigurowanych stref wysyłki, podatków, maili transakcyjnych, regulaminów i płatności. Testowe zamówienie nie przechodzi od początku do końca.
Jak naprawić: Ustalić zakres wdrożenia na piśmie: hosting, SSL, szablon, moduły, płatności, kurierzy, ERP, SEO techniczne, treści prawne. Instalacja to punkt pierwszy tej listy, nie cała lista.
Praca bezpośrednio na produkcji. Każda zmiana szablonu lub modułu od razu trafia do sklepu, w którym są zamówienia.
Jak wykryć: Brak środowiska testowego albo staging jest kopią sprzed kilku miesięcy. Po aktualizacji modułu pojawiają się błędy tylko u części klientów.
Jak naprawić: Postawić staging z aktualną bazą i plikami, wdrażać zmiany najpierw tam. Na produkcję wypuszczać paczkę po testach, w oknie o niskim ruchu.
Zamawianie modułów bez analizy procesu. Lista życzeń rośnie, a po wdrożeniu połowa funkcji jest nieużywana lub dubluje się.
Jak wykryć: Na pytanie „jak dziś obsługujecie zwroty i faktury” nikt nie potrafi odpowiedzieć w trzech krokach. Moduły kupowane są „na zapas”.
Jak naprawić: Najpierw opisać procesy: zamówienie, płatność, wysyłka, faktura, zwrot, stany magazynowe. Dopiero do procesów dobierać moduły i integracje.
Brak osoby decyzyjnej po stronie sklepu. Pytania do dewelopera krążą między działami i wracają po dwóch tygodniach.
Jak wykryć: Status projektu nie zmienia się między spotkaniami. Dostępy do paneli płatności i ERP przekazywane są fragmentami.
Jak naprawić: Wyznaczyć jedną osobę kontaktową z prawem decyzji i budżetem. Ustalić stały rytm: krótkie spotkanie raz w tygodniu plus pisemne podsumowanie.
Testy płatności, kurierów i maili dopiero w dniu startu, i to na produkcji.
Jak wykryć: Smoke test wypada na dzień przed startem. Nikt nie sprawdził skrzynki, na którą lecą maile o nowym zamówieniu.
Jak naprawić: Testy na staging z trybem testowym bramki płatniczej, etykietą próbną u kuriera i realnym adresem e-mail. Po starcie powtórzyć na produkcyjnym kluczu API za kwotę 1 zł.
Migracja ze starej platformy bez mapowania adresów URL i przekierowań 301.
Jak wykryć: Po migracji w Google Search Console rosną błędy 404, a ruch na kategoriach spada. Stare linki z kampanii prowadzą do „nie znaleziono”.
Jak naprawić: Przed migracją zrobić mapowanie stary URL → nowy URL dla produktów, kategorii i wpisów, wdrożyć 301 i po starcie monitorować indeksację oraz 404 w Search Console.
Wdrożenie sklepu PrestaShop we Wrocławiu wygrywa lub przegrywa na organizacji, nie na samym kodzie. Najważniejsze są trzy rzeczy: opisany zakres, staging przed produkcją i wyznaczona osoba decyzyjna po stronie sklepu. Reszta — moduły, integracje, migracja — jest wykonalna, jeśli ma właściciela i termin. Bez tego nawet dobry deweloper dowiezie demo, a nie sklep.
Orientacyjnie: prosty sklep 2–4 tygodnie, standardowy z płatnościami, kurierami i migracją 6–10 tygodni, rozbudowany z ERP i wielojęzycznością 3–6 miesięcy. Termin wyznacza zwykle nie liczba modułów, a czas na decyzje i dostępy po stronie klienta.
Nie. Instalacja zajmuje godziny, ale sklep gotowy do sprzedaży wymaga hostingu, SSL, szablonu, konfiguracji podatków i stref wysyłki, płatności, kurierów, maili transakcyjnych oraz treści prawnych. Do tego dochodzi SEO techniczne, czyli adresy URL, dane strukturalne i szybkość ładowania.
Od inwentaryzacji: co przenosimy (produkty, klienci, zamówienia, treści, zdjęcia) i jak mapujemy stare adresy na nowe. Dopiero potem wybieramy hosting i planujemy przekierowania 301. Praktyczne uwagi o przenoszeniu sklepu i doborze serwera opisujemy w artykule o VPS dla e-commerce.
PrestaShop wygrywa przy dużym katalogu, B2B, integracji z ERP i wielosklepowości. WooCommerce jest sensowny przy prostym sklepie opartym o WordPressa, gdzie liczy się łatwość edycji treści. Szersze porównanie z kryteriami decyzyjnymi znajdziesz w naszym przewodniku dla początkujących.
Typowo 500–2500 zł miesięcznie, zależnie od zakresu i SLA. Tańsze pakiety obejmują aktualizacje, kopie zapasowe i monitoring, droższe dodają czas reakcji liczony w godzinach, wsparcie przy kampaniach i rozwój funkcji.
Deweloper testuje technikę, ale ścieżkę zakupu musi przejść właściciel sklepu lub osoba obsługująca zamówienia. To ona zauważy, że brakuje pola na numer paczkomatu albo że mail do klienta nie zawiera numeru przesyłki. Testy po stronie biznesu są obowiązkowym etapem, nie uprzejmością.
Zmierzyć Core Web Vitals na produkcyjnym hostingu i porównać z wytycznymi Google oraz web.dev. Równolegle sprawdzić, czy analityka nie dubluje zakupów i czy dane strukturalne są poprawne. Jeśli po wdrożeniu sklep zwalnia, warto przejrzeć typowe błędy wydajnościowe w PrestaShop.
Jeśli chcesz przejść przez wdrożenie bez zgadywania, napisz do DropDigital — przejrzymy Twój proces i powiemy wprost, co ma sens, a co tylko zwiększy koszt.