Wpisując „PrestaShop company”, trafiasz na dwa różne światy. PrestaShop SA to francuski producent oprogramowania, który udostępnia platformę na licencji open source. Firma wdrożeniowa PrestaShop to podmiot, który instaluje, konfiguruje, integruje i utrzymuje Twój sklep. Jeśli szukasz wykonawcy dla swojego sklepu, interesuje Cię druga kategoria — zobacz, jak podchodzimy do wdrożeń PrestaShop. Ten tekst porządkuje, kto za co odpowiada, czego od kogo wymagać i jak ocenić oferenta, zanim podpiszesz umowę.
Fraza „PrestaShop company” prowadzi do dwóch różnych światów i to jest źródło większości nieporozumień przy zamawianiu sklepu. PrestaShop SA to francuski producent oprogramowania, właściciel platformy udostępnianej na licencji open source. Firma wdrożeniowa PrestaShop to podmiot, który instaluje, konfiguruje, integruje i utrzymuje Twój sklep.
Różnica jest praktyczna, nie językowa. PrestaShop SA nie odbierze od Ciebie zgłoszenia „nie działa mi płatność BLIK”, nie zmigruje bazy z WooCommerce i nie sprawdzi, dlaczego koszyk gubi rabat. Producent odpowiada za kod platformy i jego rozwój. Wykonawca odpowiada za wszystko, co dzieje się w Twojej instalacji: hosting, konfigurację, szablon, moduły, integracje i wsparcie po uruchomieniu.
Jeśli szukasz wykonawcy dla swojego sklepu, interesuje Cię druga kategoria — zobacz, jak podchodzimy do wdrożeń PrestaShop. Zanim wyślesz zapytanie ofertowe, warto rozdzielić obowiązki, żeby nie wymagać od dostawcy platformy rzeczy, których nie robi nigdy, i nie płacić agencji za to, co robi producent.
Poniższa tabela to najkrótsze możliwe zestawienie obu stron.
| Kryterium | PrestaShop SA (producent) | Firma wdrożeniowa PrestaShop |
|---|---|---|
| Czym jest | Właściciel i twórca platformy, open source | Podmiot, który buduje i utrzymuje Twój sklep |
| Co dostajesz | Kod platformy, aktualizacje rdzenia, dokumentację | Działającą instalację, konfigurację, integracje, szablon |
| Za co odpowiada | Rozwój rdzenia, bezpieczeństwo, zgodność wersji | Hosting, migracja danych, płatności, kurierzy, wsparcie |
| Czego wymagać | Changeloga, poprawek błędów rdzenia, dokumentacji API | Zakresu prac na piśmie, czasu reakcji, kosztu utrzymania |
| Kiedy się zgłosić | Błąd rdzenia, praca deweloperska na API | Budowa, migracja, rozbudowa i utrzymanie sklepu |
Za PrestaShop stoi PrestaShop SA — francuska spółka rozwijająca platformę od 2007 roku, z siedzibą w Paryżu. W 2021 roku została przejęta przez MBE Worldwide. Praktyczny skutek jest taki, że nad produktem czuwa dziś podmiot korporacyjny, a nie wyłącznie społeczność deweloperów — co z jednej strony oznacza stabilniejsze wydania, z drugiej dłuższą drogę decyzji produktowych.
Licencja to OSL-3.0. Kod platformy jest darmowy, możesz go modyfikować, wdrażać i hostować gdzie chcesz, bez opłaty licencyjnej. To ważne dla planowania budżetu: nie zapłacisz za samo prawo do korzystania z PrestaShop. Zapłacisz za wszystko wokół: hosting lub VPS, domenę, certyfikat SSL, szablon, płatne moduły z marketplace, pracę wdrożeniową i późniejsze utrzymanie. Darmowa licencja nie znaczy więc „darmowy sklep” — znaczy „brak abonamentu za oprogramowanie”.
Kto realnie wspiera produkt w praktyce:
Z open source wynikają dwa konkretne przywileje. Po pierwsze, nie jesteś przywiązany do wykonawcy: kod możesz zabrać i przekazać innej firmie. Po drugie, możesz ingerować w rdzeń — ale to najkrótsza droga do bólu przy aktualizacji. Standardem jest nadpisywanie zachowań bez ruszania plików rdzenia; mechanikę opisujemy w tekście PrestaShop override: jak nadpisywać kod bez błędów.
Typowy zakres prac firmy wdrożeniowej w PrestaShop wygląda tak:
Czego firma wdrożeniowa nie zrobi za Ciebie: nie ustali asortymentu i cen, nie napisze opisów produktów, nie zrobi zdjęć, nie wymyśli regulaminu ani polityki zwrotów (odpowiedzialność prawna zostaje po Twojej stronie), nie poprowadzi strategii marketingowej i nie zdecyduje, na jakich kanałach sprzedajesz. Wykonawca dostarcza narzędzie i pilnuje, żeby działało — decyzje biznesowe są Twoje.
Pytania, które rozdzielają „robimy PrestaShop” od „robimy Twój sklep”: kto pisze moduły, gdy brakuje funkcji — Wy, podwykonawca czy gotowy moduł? Kto robi aktualizacje i co dzieje się z modyfikacjami po nich? Kto odpowiada po starcie — czy jest SLA i jaki czas reakcji? Kto jest właścicielem kodu i czy dostanę repozytorium? Co się stanie, gdy zmieni się API kuriera lub bramki płatniczej? Dobre wdrożenie InPosta opisaliśmy osobno w tekście InPost w PrestaShop: wdrożenie krok po kroku, bo to element, który najczęściej wraca jako „awaria” już po odbiorze prac.
PrestaShop SA prowadzi katalog agencji i freelancerów deklarujących współpracę z platformą. Poziomy partnerskie i kryteria przydziału zmieniają się w czasie — aktualny regulamin czytasz na stronie PrestaShop, nie we wpisie blogowym z 2019 roku. Najważniejsze: status potwierdza relację handlową i deklarację, a nie audyt kodu.
Dlatego wpis w katalogu traktuj jako punkt wyjścia, nie punkt końcowy. Dwie firmy z tym samym statusem mogą różnić się jakością o klasę — jedna wdraża 8 sklepów rocznie z zespołem 12 osób, druga to jednoosobowa działalność z podwykonawcą od frontu.
Ryzyko jednoosobowe jest konkretne: urlop w środku wdrożenia, wypalenie, brak przekazania wiedzy. Zadaj pytanie o ciagłość: kto ma dostępy, gdzie leży dokumentacja, co się dzieje, gdy wykonawca zachoruje na dwa tygodnie.
Weryfikacja podmiotu zajmuje godzinę:
Zobacz też, jak wyglądają wdrożenia PrestaShop u nas — od analizy po przekazanie dostępu.
| Co status potwierdza | Czego nie gwarantuje |
|---|---|
| Wpis w katalogu i prawo do logo | Jakości kodu i kultury pracy z override |
| Zgłoszenie i akceptację regulaminu | Terminowości i realnych terminów realizacji |
| Zwykle deklarowane doświadczenie | SLA, czasu reakcji, dyżuru w weekend |
| Kontakt handlowy do firmy | Tego, kto realnie pisze kod — bywa podwykonawca |
Wydrukuj tę listę i wypełnij ją dla 2–3 oferentów. Różnice widać po pierwszym pytaniu, jeszcze przed podpisaniem umowy.
1. Repozytorium Git i własność kodu. Pytanie numer jeden, o które prawie nikt nie pyta: „czy kod będzie mój?”. Żądaj repo na własnym koncie (GitHub, GitLab, Gitea) od pierwszego commita, z historią i podziałem na gałęzie. W umowie zapis, że po zapłacie prawa majątkowe przechodzą na Ciebie. Bez tego przy zmianie wykonawcy płacisz drugi raz za to samo.
2. Override i aktualizacje. Zapytaj, ile plików leży w /override i czy to override szablonu, czy modułów. Wdrożenie, które przy przejściu z PrestaShop 8 na 9 wymaga przepisania połowy sklepu, kosztuje więcej niż samo wdrożenie. Zasady pracy z override opisujemy w tekście o tym, jak nadpisywać kod bez błędów. PrestaShop udostępnia też dokumentację dla deweloperów — warto sprawdzić, czy wykonawca ją zna.
3. SLA na piśmie. Czas reakcji (np. 4 h w oknie 9:00–17:00), czas naprawy, kanał zgłoszeń (helpdesk z numerem, nie WhatsApp), okno serwisowe. I pytanie kontrolne: kto realnie odbiera zgłoszenie w piątek o 17:00?
4. Staging, kopie i rollback. Środowisko testowe w standardzie, kopia bazy i plików przed każdą aktualizacją, test odtworzenia raz na kwartał. Rollback = tag w repo + zrzut bazy + kopia plików.
5. Referencje. Dwa sklepy o podobnej skali (liczba SKU, zamówień miesięcznie). Pytaj nie „jak było miło”, a o sytuację kryzysową: co się zepsuło, jak długo trwało, kto komunikował.
| Kryterium | Pytanie do wykonawcy | Dobra odpowiedź |
|---|---|---|
| Repozytorium i własność kodu | Czy kod będzie mój? Gdzie leży repo? | Repo na moim koncie, umowa o prawach majątkowych |
| Override | Ile plików w /override i czego dotyczą? | Krótka lista, wersjonowana, z uzasadnieniem |
| Aktualizacja 8 → 9 | Ile to zajmie i co trzeba przepisać? | Konkretny zakres w roboczogodzinach |
| SLA | Czas reakcji, czas naprawy, kanał, okno serwisowe | Zapis w umowie, nie w mailu |
| Dyżur | Kto odbiera zgłoszenie w piątek o 17:00? | Imię lub rola, nie „zespół” |
| Staging i backupy | Kiedy ostatnio testowaliście odtworzenie kopii? | Data i wynik testu |
| Rollback | Jak wycofujecie nieudaną aktualizację? | Tag, zrzut bazy, kopia plików |
| Referencje | Dwa sklepy o podobnej skali i opis awarii | Kontakt i konkretna historia |
Nie ma jednej ceny wdrożenia. Jest liczba godzin pomnożona przez stawkę. Godziny szacujesz sam, po opisie zakresu.
Policz to jawnie: jeśli oferent podaje 180 zł/h, a szacunek to 180 h, wychodzi 32 400 zł netto. To przykład rachunku, nie cennik rynkowy — stawkę wpisz swoją i porównaj oferty na tej samej liczbie godzin.
Stawka godzinowa czy abonament? Sklep robiący 100 zamówień miesięcznie rzadko przekracza kilka godzin prac serwisowych — rozliczenie ad hoc zwykle wychodzi taniej niż pakiet. Sklep z 2000 zamówień miesięcznie potrzebuje pakietu z gwarantowanym czasem reakcji, bo jedna godzina przestoju w szczycie sprzedaży kosztuje więcej niż miesięczna opłata. Abonament kupuje się nie po to, żeby było taniej, ale po to, żeby mieć zabezpieczony czas.
Co podnosi koszt:
Zasada: wycena w godzinach z rozbiciem na etapy — analiza, serwer, instalacja, szablon, moduły, integracje, migracja, testy, odbiór, szkolenie — z limitem na etap i zapisem, co się dzieje przy przekroczeniu. Po pierwszym tygodniu, po etapie analizy, powinieneś wiedzieć dokładnie, gdzie budżet ucieka i dlaczego.
| Typ wdrożenia | Orientacyjny zakres | Co siedzi w godzinach |
|---|---|---|
| Prosty sklep na gotowym szablonie | 60–150 h | Instalacja, szablon, płatności, 2–3 moduły, podstawowa konfiguracja |
| Wdrożenie z modułami i integracjami | 150–400 h | ERP, kurierzy, logika cenowa, wielojęzyczność, poprawki szablonu, testy |
| Migracja z WooCommerce lub PrestaShop 1.6 | 120–300 h | Eksport i mapowanie danych, zdjęcia, przekierowania 301, weryfikacja cen |
Siedem testów, które możesz wykonać przed podpisaniem umowy. Każdy zajmuje maksymalnie kwadrans i nie wymaga wiedzy technicznej — wystarczy zadać pytanie i sprawdzić, czy odpowiedź jest konkretna.
Jeśli na dwa z siedmiu pytań nie ma odpowiedzi w ciągu dnia, to nie sygnał ostrzegawczy — to odpowiedź.
| Sygnał | Jak to sprawdzić | Czerwona flaga w odpowiedzi |
|---|---|---|
| Brak dostępu do repo | Poproś o read-only do GitLab/GitHub lub eksport modułów przed startem | „Kod jest u nas, dostaniesz go na koniec” |
| Wszystko na płatnych wtyczkach | Zapytaj o listę licencji zewnętrznych i koszt roczny w zł | Brak listy albo „to są drobne kwoty” |
| Modyfikacje w rdzeniu | Poproś o listę plików nadpisanych w istniejącym sklepie | „Nie wiemy, trzeba by sprawdzić” przy własnym sklepie |
| Brak SLA i kanału zgłoszeń | Wyślij ticket testowy i zmierz czas odpowiedzi | Odpowiedź po trzech dniach lub tylko telefon do handlowca |
| Ryczałt bez zakresu | Poproś o rozbicie na etapy z liczbą godzin | „Zrobimy wszystko, cena jest końcowa” |
| Brak planu przekazania | Zapytaj, co dostajesz w dniu zakończenia współpracy | Brak dokumentacji, wdrożenia „ręcznie przez FTP” |
| Cisza przy aktualizacjach | Zapytaj o politykę testowania nowych wydań PrestaShop | „Aktualizujemy od razu na produkcji” |
Kolejność prac jest stała: inwentaryzacja, kopia i staging, mapowanie danych, przekierowania 301, testy, przełączenie DNS. Każdy krok, który przeskoczysz, wraca przy pierwszej aktualizacji.
Inwentaryzacja. Spisz moduły z folderu /modules i tabeli ps_module, nadpisania z /override, integracje zewnętrzne, wersję PHP, wersję PrestaShop i silnik bazy. To dokument, który powinien istnieć także wtedy, gdy przejmujesz projekt bez dokumentacji.
Kopia i staging. Pełna kopia plików i bazy na osobnym hostingu, z wyłączoną indeksacją do czasu testów. Pracujesz na kopii, nie na produkcji — to jedyna różnica między migracją a awarią.
Mapowanie danych. Klienci, zamówienia, stany magazynowe, zdjęcia, treści CMS i pola SEO (meta title, description, aliasy). Przed importem ustal, czy identyfikatory kategorii i produktów zostają, czy zmieniają się — od tego zależy mapa przekierowań.
Przekierowania 301. Eksportuj adresy z Google Search Console (raport indeksowania), z sitemap.xml oraz z logów serwera. Mapuj 1:1 albo na najbliższy odpowiednik tematyczny. Unikaj łańcuchów przekierowań i masowego kierowania starych URL-i na stronę główną — to najczęstszy sposób na utratę ruchu transakcyjnego.
Testy i przełączenie. Zamówienie testowe, płatności, kurierzy, maile transakcyjne, faktury. TTL domeny obniż 24–48 godzin wcześniej, samo przełączenie zrób w oknie nocnym. Sprawdzony scenariusz organizacji takiego wdrożenia bez przestojów opisujemy przy okazji integracji InPost z PrestaShop 9.
Po migracji wróć do Search Console: zgłoś nową sitemapę, sprawdź błędy 404 i 301 po 7, 14 i 30 dniach.
| Etap | Co konkretnie robisz | Czym to kontrolujesz |
|---|---|---|
| Inwentaryzacja | Lista modułów, nadpisań, hooków, integracji, wersji środowiska | Folder /modules, tabele ps_module, ps_hook, plik konfiguracyjny z danymi bazy |
| Kopia i staging | Kopia plików i bazy na osobnym hostingu, indeksacja wyłączona | Dostęp do kopii, testowy adres |
| Mapowanie danych | Klienci, zamówienia, stany, zdjęcia, treści, pola SEO | Skrypt mapujący, klucze ID produktów i kategorii |
| Przekierowania 301 | Mapa stary URL → nowy URL, bez łańcuchów | Eksport z Search Console, sitemap.xml, logi serwera |
| Testy | Zamówienie testowe, płatności, wysyłka, maile, faktury | Staging przed przełączeniem |
| Przełączenie DNS | Obniżony TTL 24–48 h wcześniej, okno nocne | Certyfikat SSL, poczta, dostępność sklepu |
| Kontrola po migracji | Błędy 404, indeksacja, wydajność, pozycje | Raporty Search Console po 7, 14 i 30 dniach |
Traktowanie darmowej licencji jako dowodu, że wdrożenie będzie tanie.
Jak wykryć: Oferta zawiera wyłącznie kwotę za „postawienie sklepu”, bez pozycji na hosting, moduły płatne, migrację danych, szablon i utrzymanie.
Jak naprawić: Poproś o kosztorys na 12 miesięcy: licencja (0 zł), hosting lub VPS, moduły i subskrypcje, wdrożenie, migracja, aktualizacje, wsparcie. Dopiero suma pokazuje realny budżet.
Uznanie statusu partnera PrestaShop za gwarancję jakości kodu i terminowości.
Jak wykryć: Oferent podaje logo i poziom partnerski jako główny argument, ale nie pokazuje repozytorium, standardów code review ani zapisów SLA.
Jak naprawić: Status to punkt wyjścia, nie dowód. Poproś o trzy żywe sklepy z linkami, sprawdź wiek domen i opinie poza stroną agencji, zapytaj o osoby, które realnie będą pracować nad projektem.
Brak zapisu o własności kodu i dostępu do repozytorium.
Jak wykryć: W umowie nie ma słowa o Git, a na pytanie „czy kod będzie mój?” pada odpowiedź „a po co Panu kod”.
Jak naprawić: Wpisz do umowy: repozytorium Git przekazywane klientowi, dostęp dla minimum dwóch osób po stronie zamawiającego, pełne prawa do autorskich modyfikacji i szablonu po opłaceniu prac.
Nadpisywanie (override) połowy rdzenia bez polityki aktualizacji.
Jak wykryć: Zapytaj, ile plików w override i kto prowadzi ich rejestr. Jeśli odpowiedź brzmi „nie wiemy, tak wyszło”, problem jest już w kodzie.
Jak naprawić: Ustal zasadę: najpierw moduł, override tylko gdy nie ma innej drogi. Każdy override w wersjonowanym repozytorium z opisem celu. Szczegóły rozkładamy w tekście o override w PrestaShop.
Umowa bez SLA i bez wskazania, kto realnie odbiera zgłoszenia.
Jak wykryć: W ofercie jest „reagujemy na bieżąco” i „wsparcie w cenie”, ale nie ma liczb, kanału zgłoszeń ani godzin pracy.
Jak naprawić: Wymagaj na piśmie: czas pierwszej reakcji, czas naprawy dla błędów krytycznych i zwykłych, kanał zgłoszeń, okno serwisowe oraz osobę lub zespół dyżurujący — także w piątek o 17:00.
Aktualizacje i zmiany wdrażane bezpośrednio na produkcji, bez stagingu i testu odtworzenia kopii.
Jak wykryć: Pytanie „jak wrócicie do poprzedniej wersji, jeśli aktualizacja padnie?” kończy się odpowiedzią ogólnikową albo „mamy backupy na serwerze”.
Jak naprawić: Wymagaj środowiska staging zgodnego z produkcją, kopii przed każdą zmianą, okresowego testu odtworzenia kopii na osobnym środowisku i spisanej procedury rollbacku z szacowanym czasem powrotu.
„PrestaShop company” to dwa podmioty: producent platformy i firma, która wdraża Twój sklep. Producent daje oprogramowanie na licencji open source, ale nie odpowiada za Twój hosting, moduły ani utrzymanie. O wyborze wykonawcy nie decyduje logo partnera, tylko własność kodu, polityka override, SLA na piśmie i przetestowany rollback. Te cztery rzeczy sprawdzisz w ciągu jednej rozmowy — i to one najczęściej decydują o tym, czy sklep działa spokojnie przez kolejne lata.
PrestaShop SA to producent oprogramowania — tworzy i rozwija platformę oraz prowadzi marketplace modułów i katalog partnerów. Firma wdrożeniowa to niezależny podmiot, który instaluje i konfiguruje sklep, migruje dane, buduje szablon, podłącza płatności i kurierów oraz utrzymuje całość po starcie. Producent nie prowadzi Twojego wdrożenia, a agencja nie zmienia kodu rdzenia platformy.
Oprogramowanie jest udostępniane na licencji open source, więc nie płacisz za samo prawo do korzystania z platformy. Płatne są natomiast rzeczy wokół niej: hosting lub VPS, część modułów, szablon, praca wdrożeniowa, migracja danych, integracje oraz utrzymanie i aktualizacje. Budżet liczy się więc od kosztu całkowitego w skali roku, nie od ceny licencji.
Nie. Status w katalogu partnerów mówi o obecności w programie, a nie o jakości kodu, terminowości czy poziomie wsparcia. Poziomy partnerskie mogą być powiązane z aktywnością i liczbą projektów, ale nie zastępują SLA. Realną weryfikacją są żywe sklepy z linkami, opinie poza stroną agencji i zapisy w umowie.
Freelancer sprawdzi się przy prostym sklepie, standardowym szablonie i kilku popularnych modułach. Zespół z osobą od utrzymania i kompetencjami serwerowymi potrzebny jest wtedy, gdy masz integrację z ERP lub magazynem, wysoki ruch, własne moduły albo wymóg szybkiej reakcji w razie awarii. Przy sklepie, który generuje przychód codziennie, brak dyżuru jest ryzykiem biznesowym, nie oszczędnością.
Zacznij od danych rejestrowych: numer KRS lub CEIDG, adres, wiek domeny. Potem obejrzyj portfolio z linkami do działających sklepów i oceń ich szybkość oraz sprawność koszyka. Na końcu przeczytaj umowę pod kątem własności kodu, SLA, kopii zapasowych i procedury rollbacku. Jeśli któryś z tych elementów jest „do ustalenia później”, potraktuj to jako brak odpowiedzi.
Zakres prac z listą integracji i nazwami dostawców, termin przekazania repozytorium Git, prawa do kodu, zasady nadpisywania rdzenia, środowisko staging, polityka kopii zapasowych, procedura rollbacku oraz SLA z czasami reakcji i naprawy. Warto dopisać, na czyim koncie stoi hosting i co się dzieje z dostępami po zakończeniu współpracy.
Jeśli chcesz porównać swoją sytuację z tym, jak wygląda wdrożenie po naszej stronie, opisz krótko sklep i napisz do nas. Odpowiemy konkretnie, co da się zrobić w istniejącym kodzie, a co wymaga przebudowy.