Opieka techniczna sklepu to nie hosting i nie jednorazowe wdrożenie — to stały zakres prac, który zaczyna się po odbiorze strony. W praktyce oznacza aktualizację wtyczki z testem na stagingu, naprawę błędu w module płatności i pilnowanie wydajności bazy, gdy rośnie liczba zamówień. Poniżej znajdziesz część organizacyjną tematu: typowe błędy przy podpisywaniu umowy, listę kontrolną zakresu i pytania, które warto zadać dostawcy w Szczecinie przed podpisaniem dokumentów. Punktem wyjścia dla całego zagadnienia jest nasz przegląd utrzymania stron internetowych.
Wdrożenie kończy się odbiorem strony. Opieka zaczyna się po nim. To jedno zdanie warto powiesić nad biurkiem, bo większość sporów z dostawcą bierze się z mieszania trzech różnych rzeczy: hostingu, jednorazowego projektu i bieżącego utrzymania.
Hosting odpowiada za to, że serwer działa, masz miejsce na pliki i bazę oraz certyfikat TLS. Nie zrobi za ciebie trzech rzeczy, które w sklepie zdarzają się co miesiąc:
Zanim podpiszesz umowę, policz koszt przestoju. Wzór: średnia wartość zamówienia × liczba zamówień na godzinę × czas niedostępności koszyka. Sklep z 30 zamówieniami dziennie i średnią 180 zł ma 1,25 zamówienia na godzinę. Cztery godziny awarii koszyka w poniedziałkowe przedpołudnie to około 5 utraconych zamówień, czyli 900 zł przychodu — i to bez kosztu obsługi klientów, którzy w tym czasie piszą na czacie i dzwonią.
Punktem wyjścia dla całego tematu jest nasz przegląd utrzymania stron internetowych — rozkładamy tam zakres prac na części. Jeśli chcesz mieć punkt odniesienia dla wydajności sklepu, progi LCP, INP i CLS opisuje dokumentacja Web Vitals.
Weź ofertę dowolnego dostawcy w Szczecinie i przejedź po niej tą listą. Zasada jest prosta: jeśli w umowie nie ma zapisu, że coś jest objęte, to nie jest. Za brakujący element zapłacisz osobno — zwykle w najgorszym możliwym momencie, czyli wtedy, gdy sklep nie sprzedaje.
Najpierw ustal jedną definicję, bo bez niej każde rozliczenie godzin kończy się sporem. Błąd to sytuacja, w której coś, co działało zgodnie z umową, przestało działać — na przykład koszyk nie przelicza kosztu dostawy po zmianie cennika. Nowe wymaganie to zmiana, której wcześniej nie było: dodatkowe pole w formularzu, nowy próg darmowej dostawy, integracja z kolejnym kurierem. Pierwsze jest objęte opieką, drugie to zlecenie do wyceny.
| Obszar | Minimalny standard zapisany w umowie |
|---|---|
| Aktualizacje rdzenia, wtyczek i motywu | Test na stagingu, test koszyka i płatności przed wypchnięciem na produkcję |
| Kopie zapasowe | Codziennie, retencja min. 30 dni, test odtworzenia co najmniej raz na kwartał |
| Monitoring dostępności i czasu odpowiedzi | Interwał 1 min, alert na maila i SMS, sprawdzanie strony głównej oraz koszyka |
| Certyfikaty TLS | Odnowienie automatyczne plus przypomnienie 14 dni przed wygaśnięciem |
| Poprawki błędów | 24 h na błąd blokujący sprzedaż, 72 h na błąd kosmetyczny |
| Integracje: ERP, InPost ShipX, DPD, DHL, operatorzy płatności | Zapis, kto diagnozuje problem po stronie API i w jakim czasie reaguje |
| Bezpieczeństwo | Skanowanie malware, blokada prób logowania, procedura reakcji na incydent |
| Wydajność i baza danych | Przegląd wolnych zapytań, konfiguracja cache, kontrola LCP, INP i CLS |
| Logi i monitoring błędów | Dostęp do logów PHP, JS i błędów płatności w ramach opieki, bez dopłat |
| Regresja po aktualizacji | Checklista: koszyk, checkout, mail potwierdzający, faktura, statusy zamówień |
| Raport miesięczny | Uptime, liczba incydentów, wykonane aktualizacje, zużycie godzin z pakietu |
| Tryb zgłaszania i priorytetyzacja | Jeden kanał zgłoszeń, kategorie: awaria, drobna zmiana, praca rozwojowa |
Backup, którego nikt nie odtworzył, nie jest backupem — tylko plikiem, o którym ktoś myśli, że działa. Dlatego test odtworzenia musi być w umowie jako osobna pozycja, a nie „w razie potrzeby”. Szczegóły techniczne zmian w kolejnych wersjach systemu znajdziesz w dokumentacji dla deweloperów PrestaShop. Jak cały ten zakres poukładać w procesie od zgłoszenia do raportu, opisujemy w artykule o utrzymaniu i opiece technicznej sklepów.
Stawki za pracę techniczną przy sklepie mieszczą się w Polsce zwykle w przedziale 150–350 zł netto za godzinę. Dolna granica dotyczy prostych wdrożeń na WordPressie i WooCommerce, górna — PrestaShop z modułami własnymi, integracją ERP i niestandardowym checkoutem. Sam przedział mówi jednak niewiele, dopóki nie wiesz, ile godzin miesięcznie realnie zużyjesz.
| Model | Jak działa | Kiedy się opłaca |
|---|---|---|
| Rozliczenie godzinowe | Płacisz za faktycznie wykonane prace, dostajesz ewidencję czasu | Prace doraźne, stabilny sklep, brak potrzeby gwarantowanego czasu reakcji |
| Pakiet godzinowy ważny 3–6 miesięcy | Kupujesz z góry np. 10 h w niższej stawce za godzinę | Znasz przybliżony zakres; pamiętaj, że niewykorzystane godziny przepadają |
| Abonament miesięczny | Stała kwota, gwarantowany zakres i czas reakcji, nadwyżka po stawce godzinowej | Sklep sprzedaje codziennie; to jedyny model z realnym SLA |
Trzy typowe progi abonamentu różnią się nie liczbą godzin, a ryzykiem i liczbą ruchomych części. Sklep do 500 zamówień miesięcznie, z jedną metodą płatności i jednym kurierem, to głównie aktualizacje, backupy i monitoring. Sklep średni z ERP dokłada synchronizację stanów magazynowych i zamówień, mapowanie pól, kolejki oraz testy po każdej zmianie po stronie ERP — problem w ERP potrafi wysypać stany w sklepie w kilka minut. Sklep z modułami pisanymi na zamówienie dokłada utrzymanie własnego kodu: tam nie da się aktualizować „w ciemno”, każda zmiana wymaga regresji koszyka i checkoutu.
Cena rośnie przy integracji z ERP, modułach własnych, wysokim ruchu i przestarzałej wersji PrestaShop wymagającej migracji — na przykład z 1.6 do 8.x, co jest projektem, a nie poprawką. Nie powinno być płatne osobno: monitoring uptime i dostęp do logów. To element opieki, nie dodatek. Niezależnie od tego, czy pracujesz z dostawcą w Szczecinie, czy zdalnie, konkretne stawki dla poszczególnych zakresów znajdziesz w cenniku utrzymania i opieki technicznej sklepów.
SLA bez liczb to nie SLA. Jeśli w ofercie czytasz „reagujemy sprawnie”, nie masz czego porównać z konkurencyjną propozycją. Sensowny zapis zaczyna się od definicji priorytetów.
P1 — koszyk nie działa, bramka płatnicza odrzuca transakcje, składanie zamówienia kończy się błędem 500. Każda minuta to utracone zamówienia. P2 — nie działa jedna metoda dostawy (np. przesyłka kurierska X), nie generują się etykiety. Sklep sprzedaje, ale tracisz część klientów. P3 — literówka w szablonie maila „Zamówienie wysłane”, zły kolor przycisku, brakujący opis w karcie produktu.
Realistyczne czasy w godzinach 8–18: P1 reakcja do 1 h i obejście do 4 h, P2 reakcja do 4 h, P3 do 2 dni roboczych. I tu pierwsza pułapka: dostawcy mieszają czas reakcji z czasem usunięcia awarii. Reakcja do 1 h oznacza, że ktoś odebrał zgłoszenie, przypisał je do osoby i potwierdził przyjęcie. Obejście do 4 h oznacza, że sklep znowu sprzedaje — choćby przez wyłączenie feralnego modułu i przełączenie na zapasową bramkę płatniczą. Naprawa przyczyny może potrwać dwa dni i to musi być osobny zapis w umowie, inaczej dostawca policzy ci P1 jako zamknięte po wyłączeniu wtyczki, a ty dalej nie będziesz wiedział, dlaczego się wysypała.
| Priorytet | Przykład zdarzenia | Czas reakcji | Czas obejścia |
|---|---|---|---|
| P1 | Koszyk nie działa, płatności odrzucają transakcje | do 1 h (8–18) | do 4 h |
| P2 | Nie działa jedna metoda dostawy, brak etykiet kurierskich | do 4 h (8–18) | do 1 dnia roboczego |
| P3 | Literówka w szablonie maila, błędny kolor przycisku | do 2 dni roboczych | najbliższe okno wdrożeniowe |
Biuro w Szczecinie nie jest warunkiem dobrej opieki. Warunkiem jest uporządkowany dostęp i środowisko testowe. Zespół z innego miasta obsłuży sklep w Szczecinie tak samo dobrze, jeśli poniższe rzeczy są ustalone na piśmie przed startem współpracy.
Dostępy do przekazania: SSH/SFTP (klucz publiczny dewelopera, nie hasło), panel hostingu, panel sklepu z rolą administratora, panel DNS domeny, konto w bramce płatniczej, konta w panelach kurierów lub w integratorze wysyłek. Do tego dostęp do Google Search Console i Merchant Center, jeśli prowadzisz kampanie produktowe.
Gdzie trzymać dostępy: wyłącznie w menedżerze haseł z historią zmian i zasadą least privilege — Bitwarden, 1Password albo KeePass. Deweloper nie potrzebuje uprawnień do wystawiania faktur ani zmiany danych bankowych w sklepie. Nigdy w mailu, nigdy na czacie, nigdy w arkuszu Google z linkiem „każdy z linkiem może edytować”. Ustal też 2FA: kody zostają po stronie klienta, a dostawca pracuje na koncie technicznym. Inaczej awaria czyjegoś telefonu blokuje pracę na dwa dni.
Komunikacja: jedna strefa czasowa (Europe/Warsaw), zgłoszenia asynchronicznie przez ticket lub mail, telefon tylko dla P1. Po stronie firmy musi być jedna osoba zatwierdzająca zmiany i jej zastępca — bez tego wdrożenie czeka trzy dni na akceptację właściciela, który jest na urlopie.
Kiedy wizyta na miejscu ma sens: fizyczny serwer stojący w biurze, integracja z magazynem (czytniki kodów, drukarki etykiet, waga), audyt bezpieczeństwa wymagany twoją procedurą wewnętrzną, przekazanie sprzętu lub domeny.
Środowisko testowe to warunek, nie dodatek. Staging na subdomenie (np. staging.twojsklep.pl), kopia plików i bazy, wyłączona wysyłka maili i płatności w trybie sandbox. Bez tego każda aktualizacja wtyczki to ruletka na produkcji. Dokumentację techniczną PrestaShop znajdziesz w oficjalnej dokumentacji dla deweloperów.
| Dostęp | Co przekazać | Gdzie trzymać | Uwaga |
|---|---|---|---|
| SSH/SFTP | klucz publiczny, port, ścieżka katalogu | menedżer haseł | hasła wyłączone, tylko klucze |
| Panel hostingu | konto techniczne o ograniczonej roli | menedżer haseł klienta | ustal, kto odbiera kody 2FA |
| Panel sklepu | konto administratora technicznego | menedżer haseł | rola nadawana na czas prac |
| DNS | dostęp do strefy lub zmiana rekordu przez klienta | panel domeny | rekordy MX zmieniane tylko na zgłoszenie |
| Płatności i kurierzy | konto w panelu merchant / API | menedżer haseł | na stagingu wyłącznie tryb testowy |
Referencje nic nie wnoszą — każdy ma zadowolonego klienta. Poniżej pięć prób, które wykonasz w pół godziny i które realnie odsieją dostawców deklarujących opiekę od tych, którzy ją wykonują.
Brak odpowiedzi na którekolwiek z tych pytań też jest odpowiedzią. Jeśli szukasz sposobu na uporządkowanie tego po swojej stronie, zacznij od materiału o tym, jak utrzymanie i opieka techniczna sklepów powinny być poukładane w umowie i w praktyce.
Opieka techniczna nad sklepem to nie tylko wtyczki. Dostawca dostaje dostęp do bazy zamówień, czyli do danych osobowych: imion, adresów, e-maili i numerów telefonów. Pierwsze pytanie w rozmowie z firmą ze Szczecina nie brzmi więc „ile za miesiąc”, tylko „kto jest administratorem danych i czy podpisujemy umowę powierzenia”.
Administratorem jesteś Ty — właściciel sklepu. Dostawca utrzymania staje się podmiotem przetwarzającym w rozumieniu art. 28 RODO. Umowa powierzenia przetwarzania danych (DPA) musi wskazywać: zakres i cel przetwarzania, kategorie danych, listę podprocesorów (hosting, CDN, monitoring, backup), obowiązek zgłoszenia naruszenia w ciągu 24 godzin od wykrycia oraz termin usunięcia danych po zakończeniu współpracy. Bez listy podprocesorów nie wiesz, kto realnie trzyma kopie bazy Twoich klientów.
Dwuskładnikowe uwierzytelnianie traktuj jako warunek startu, nie dodatek. Dotyczy czterech miejsc: panelu sklepu, panelu hostingu, dostępu SSH/SFTP i skrzynki e-mail administratora — bo reset hasła przychodzi właśnie na maila. W PrestaShop konto pracownika domyślnie nie ma 2FA; trzeba dołożyć moduł albo ograniczyć logowanie do zaplecza po adresach IP lub przez VPN. Konto z hasłem zapisanym w przeglądarce to najczęstsza droga włamania do małego sklepu.
Logi. W PrestaShop widzisz działania pracowników (Zaawansowane → Logi), ale bez logów serwera i panelu hostingowego nie ustalisz, kto podmienił plik w module. Ustal w umowie: retencja logów minimum 90 dni, udostępnienie na żądanie w 2 dni robocze, w formacie CSV. Cały zakres prac warto wpisać w szerszy podział obowiązków — utrzymanie i opieka techniczna sklepów – jak to poukładać.
Płatności to osobny temat, bo zakres PCI DSS zależy od tego, jak technicznie przyjmujesz karty. Różnice pokazuje tabela poniżej.
Backupy: zapytaj, w jakim regionie fizycznie leżą kopie i czy którykolwiek podprocesor nie przechowuje danych poza EOG (wtedy potrzebna podstawa transferu i zapis o standardowych klauzulach umownych). Ustal też, że po zakończeniu umowy dane są kasowane w 30 dni, a dostawca wydaje na piśmie oświadczenie o usunięciu.
| Model płatności w sklepie | Zakres PCI DSS | Kto odpowiada za dane karty |
|---|---|---|
| Przekierowanie do bramki (PayU, Przelewy24, Tpay) | SAQ A – najprostszy | Bramka; numery kart nie trafiają na Twój serwer |
| Formularz karty w iframe/JS bramki | SAQ A-EP | Ty za integralność strony, bramka za dane karty |
| Własny formularz kartowy z zapisem numeru w bazie | SAQ D – pełny zakres | Ty: szyfrowanie, audyty, kontrole. Tego nie robić |
Najdroższy zapis w umowie o utrzymanie to nie stawka miesięczna, a brak planu wyjścia. Sklep, do którego nie masz dostępu do serwera i DNS, jest tyle wart, ile dobra wola obecnego wykonawcy.
Własność kodu. Moduły i wtyczki pisane na zamówienie (np. własna integracja z magazynem czy kurierem, zgodnie z dokumentacją developerską PrestaShop) powinny przechodzić na Ciebie po opłaceniu faktury. Domagaj się zapisu o przeniesieniu autorskich praw majątkowych oraz o przekazaniu repozytorium Git razem z dokumentacją. Klauzula „licencja na czas trwania umowy” oznacza, że po rozstaniu nie możesz legalnie korzystać z tego, za co zapłaciłeś.
Przekazanie dostępów i dokumentacji w konkretnym terminie — realnie 5 dni roboczych od zakończenia umowy, bez uzależniania od dodatkowej opłaty. Lista minimum: hosting, panel DNS i rejestrator domeny, zaplecze sklepu, baza danych, repozytorium, klucze API do bramek płatniczych, kurierów i programu do faktur, GA4, Search Console. Forma: plik do menedżera haseł albo arkusz, nie wiadomość z hasłami w treści maila.
Zakaz blokowania dostępu do serwera, panelu hostingu i DNS. Nawet przy sporze o faktury. W praktyce „karą” za zaległość jest podmiana rekordów DNS albo wyłączenie konta — to nie zabezpieczenie, to zakładnik.
Okres przejściowy, np. 30 dni, z wpisaną stawką godzinową. Zdefiniuj, kto robi eksport (zrzut bazy SQL, archiwum plików i zdjęć, lista cronów), kto odpowiada za testy po przeniesieniu: zamówienie testowe, płatność w trybie sandbox, e-mail wychodzący, dokument sprzedaży. Odpowiedzialność za utratę danych ogranicz do sensownego pułapu (np. 12-krotność miesięcznego wynagrodzenia) i zapisz, że kopie zapasowe są Twoją własnością. Porównaj też zapisy z materiałem o utrzymaniu i opiece technicznej sklepów Zamość.
Automatyczne przedłużenie rozpoznasz po frazie „umowa ulega przedłużeniu na kolejny okres, jeżeli żadna ze stron nie złoży wypowiedzenia”. Zamień to na umowę na czas nieokreślony z miesięcznym okresem wypowiedzenia.
| Zapis, który Cię blokuje | Co wpisać zamiast |
|---|---|
| Moduły autorskie zostają u dostawcy, Ty masz licencję na czas umowy | Przeniesienie praw majątkowych po opłaceniu + repozytorium Git i dokumentacja |
| Dostawca może wstrzymać dostęp do serwera i DNS przy zaległościach | Zakaz blokowania hostingu, DNS i zaplecza; spór o faktury poza infrastrukturą |
| Umowa przedłuża się automatycznie na kolejne 12 miesięcy | Czas nieokreślony z 1-miesięcznym wypowiedzeniem |
| Kopie zapasowe są elementem usługi dostawcy | Kopie są własnością klienta, ostatnia kopia wydana w 5 dni roboczych |
Umowa obejmuje aktualizacje, ale bez testu na kopii sklepu — wtyczki idą od razu na produkcję.
Jak wykryć: Zapytaj dostawcę, jaką dokładnie procedurę stosuje przed aktualizacją i czy istnieje środowisko staging.
Jak naprawić: Wpisz do umowy, że każda aktualizacja rdzenia, wtyczki i motywu przechodzi najpierw test ścieżki zakupu na stagingu, a dopiero potem trafia na produkcję.
Kopie zapasowe są robione, ale nikt nigdy ich nie odtworzył.
Jak wykryć: Poproś o datę ostatniego testu odtworzenia backupu i dokument, który to potwierdza.
Jak naprawić: Ustal w umowie test odtworzenia co najmniej raz na kwartał, na osobnym środowisku, z krótkim protokołem: co sprawdzono, ile trwało, co nie zadziałało.
SLA opisane hasłami typu „szybka reakcja” albo „najwyższy priorytet”, bez liczb i bez tabeli priorytetów.
Jak wykryć: Sprawdź, czy w umowie jest tabela P1/P2/P3 z czasem reakcji i czasem obejścia podanym w godzinach.
Jak naprawić: Zażądaj konkretnych wartości: P1 reakcja do 1 h i obejście do 4 h w godzinach 8–18, P2 i P3 z własnymi widełkami oraz informacją, co dzieje się poza godzinami pracy.
Monitoring dostępności i dostęp do logów są wycenione jako płatny dodatek do pakietu.
Jak wykryć: Przejrzyj cennik dostawcy i poszukaj osobnych pozycji „monitoring” albo „dostęp do logów”.
Jak naprawić: Potraktuj monitoring uptime i wgląd w logi jako element opieki, a nie opcję — bez nich nie zweryfikujesz żadnego incydentu ani czasu reakcji.
Umowa nie rozróżnia błędu od nowego wymagania, więc każde zgłoszenie kończy się sporem o wycenę.
Jak wykryć: Zadaj pytanie: czy zmiana treści bannera albo dodanie nowego pola w formularzu to błąd, czy nowa praca?
Jak naprawić: Zapisz definicję: błąd to coś, co wcześniej działało i przestało działać. Nowe wymaganie to zmiana zakresu, wyceniana osobno i realizowana po akceptacji.
Integracje z ERP, InPost ShipX, DPD, DHL lub operatorem płatności nie są ujęte w zakresie opieki.
Jak wykryć: Zapytaj wprost: kto diagnozuje problem, gdy API zwraca błędy i kto kontaktuje się z operatorem.
Jak naprawić: Wpisz do umowy, że dostawca diagnozuje problem po swojej stronie, zbiera logi i zgłasza sprawę do operatora, a Ty dostajesz informację zwrotną w ustalonym czasie.
Opieka techniczna zaczyna się tam, gdzie kończy się wdrożenie — i nie zastąpi jej sam hosting. Porównuj oferty po zakresie, tabeli priorytetów z liczbami i raporcie miesięcznym, a nie po haśle „kompleksowa opieka”. Jeśli w umowie brakuje testu na stagingu, testu odtworzenia backupu albo obsługi integracji, dopisz to przed podpisaniem. Kolejność działań w całym temacie porządkuje artykuł jak poukładać utrzymanie i opiekę techniczną sklepów.
Hosting odpowiada za to, żeby serwer działał i był dostępny. Opieka techniczna to prace nad samym sklepem: aktualizacja wtyczki z testem na stagingu, naprawa błędu w module płatności, optymalizacja zapytań do bazy, gdy rośnie liczba zamówień. Hosting nie zrobi żadnej z tych rzeczy, bo nie wchodzi w kod Twojej instalacji.
Najczęściej spotkasz trzy modele: rozliczenie godzinowe (typowo 150–350 zł netto za godzinę, zależnie od technologii), pakiet godzinowy ważny 3–6 miesięcy oraz abonament miesięczny z gwarantowanym zakresem. Progi abonamentu różnią się między małym sklepem do 500 zamówień miesięcznie, sklepem średnim zintegrowanym z ERP i sklepem z modułami pisanymi na zamówienie. Szczegółowe przedziały opisaliśmy w artykule o cenniku utrzymania i opieki technicznej.
Kopia zapasowa bez testu odtworzenia nie daje żadnej gwarancji. Bywa, że backup istnieje, ale brakuje w nim plików wgranych modułów albo bazy z ostatniej doby. Dlatego w zakresie opieki powinien być zapis o teście odtworzenia co najmniej raz na kwartał, najlepiej na osobnym środowisku.
Dla błędu P1, czyli niedziałającego koszyka albo odrzucanych płatności, realistyczna jest reakcja do 1 godziny i obejście do 4 godzin w godzinach 8–18. P2, na przykład niedziałająca jedna metoda dostawy, zwykle rozwiązuje się tego samego dnia roboczego. P3, czyli literówka w szablonie maila, trafia do kolejki drobnych poprawek.
Zakres opieki powinien obejmować diagnozę: sprawdzenie logów po Twojej stronie, ustalenie, czy request wychodzi poprawnie i jaki kod błędu wraca z API. Jeśli problem jest po stronie operatora, dostawca zbiera dane i zgłasza sprawę dalej, a Ty dostajesz informację o statusie. Bez tego utkniesz między dwoma firmami, które przerzucają się odpowiedzialnością.
Zwykle nie — to osobny projekt z własnym zakresem i harmonogramem, bo wymaga testów modułów i motywu. Przy platformie warto opierać się na dokumentacji deweloperskiej: PrestaShop Developer Documentation. Abonament utrzymaniowy powinien jednak zawierać plan migracji z terminami, a nie tylko wzmiankę o tym, że kiedyś trzeba to zrobić.
Pomiar i pilnowanie wskaźników wydajności warto mieć w zakresie, bo sklep z czasem naturalnie zwalnia — dochodzą wtyczki, zapytania i rosnąca baza zamówień. Konkretne progi dla LCP, INP i CLS opisuje dokumentacja Web Vitals. Sama optymalizacja to zwykle odrębne zadanie wyceniane godzinowo, ale monitoring wskaźników powinien być częścią raportu miesięcznego.
Jeśli chcesz zestawić swoją obecną umowę z tą listą kontrolną, napisz do nas — powiemy wprost, czego brakuje, bez sprzedażowego wstępu. DropDigital prowadzi utrzymanie sklepów PrestaShop i WooCommerce, w tym integracje, serwery i monitoring.