Moduł czy wtyczka – co dokładnie zamawiasz i czym to się różni

Połowa nieporozumień w wycenach bierze się z tego, że klient mówi „wtyczka” o module PrestaShop. To dwa różne światy technicznie i dwa różne modele wsparcia.

Moduł to rozwiązanie dla PrestaShop. Fizycznie dostajesz katalog /modules/nazwa_modulu, w nim plik główny nazwa_modulu.php z klasą dziedziczącą po klasie Module, metodę install(), która rejestruje hooki (displayHeader, actionValidateOrder, actionOrderStatusPostUpdate), oraz plik config.xml. Instalacja idzie przez panel: Moduły → Menedżer modułów → Wyślij moduł.

Wtyczka to WordPress i WooCommerce: katalog /wp-content/plugins/nazwa-wtyczki, plik z nagłówkiem Plugin Name, własne tabele zakładane przez dbDelta() albo typy treści przez register_post_type(). Instalacja: Wtyczki → Dodaj nową → Wyślij wtyczkę.

Osobna sprawa to override. W PrestaShop to plik w katalogu /override/, który nadpisuje klasę rdzenia, np. Cart.php lub Product.php. Działa, ale po każdej aktualizacji PrestaShop trzeba go weryfikować — zmiana w rdzeniu potrafi wywalić sklep błędem 500. Dobry moduł rozwiązuje ten sam problem hookiem i nie dotyka rdzenia. W WordPressie odpowiednikiem jest child theme z filtrami, który też trzeba sprawdzać po aktualizacji motywu nadrzędnego.

Moduł płatny z Marketplace to inny produkt niż moduł pisany na miarę. Przy gotowcu płacisz licencję co roku i zwykle nie masz prawa zmienić logiki. Przy module na miarę kod jest twój, a wsparcie dotyczy konkretnie tego wdrożenia.

Co fizycznie dostajesz na koniec:

• repozytorium Git z historią commitów i dostępem do odczytu,
• plik ZIP gotowy do instalacji w panelu,
• dokumentację konfiguracji: gdzie włączyć moduł, jakie ustawienia, jakie zadania cron,
• changelog z numeracją wersji i informacją, jaką wersję PrestaShop/WooCommerce oraz PHP testowano.

Zanim zamówisz, uporządkuj zakres i etapy — pomoże w tym materiał o organizacji pracy przy niestandardowych modułach i wtyczkach. Dokumentacja techniczna PrestaShop jest publiczna i warto zajrzeć do niej przed rozmową z wykonawcą: PrestaShop Developer Documentation.

Kiedy niestandardowy moduł się opłaca – 6 sygnałów i próg opłacalności

Decyzja sprowadza się do jednego porównania: roczny koszt obejścia problemu kontra koszt modułu. Poniżej sześć sygnałów, że obejście przestaje się opłacać.

Sygnał 1: proces, którego żaden gotowy moduł nie odwzorowuje. Przykład: cennik B2B zależny od limitu kredytowego kontrahenta. Klient ma limit 20 000 zł, wykorzystał 18 000 zł — koszyk ma pokazać inne ceny lub zablokować zamówienie na termin płatności. Modułu o nazwie „limit kredytowy z ERP” w Marketplace nie kupisz.

Sygnał 2: proces działa, ale wymaga wyjątków poza standardem — trzy grupy klientów, dwa cenniki, osobna ścieżka faktury bez VAT.

Sygnał 3: kumulacja 4–6 płatnych wtyczek. Policz 12 miesięcy: cztery wtyczki po 600 zł/rok to 2400 zł, sześć po 400 zł to 2400 zł, a często schodzi się do 3000–5000 zł rocznie. Gdy ta suma plus roboczogodziny zbliża się do kosztu modułu, abonamenty przestają być oszczędnością.

Sygnał 4: gotowiec działa, ale wymusza ręczną pracę. Trzy godziny tygodniowo na eksport i import zamówień do ERP to 156 godzin rocznie (52 tygodnie). Przy koszcie pracy 60 zł/h daje to 9360 zł.

Sygnał 5: integracja z systemem bez gotowego konektora: Subiekt GT, WF-Mag, Comarch Optima, autorski ERP.

Sygnał 6: wymagania, których gotowiec nie spełni — dane klientów nie mogą opuszczać serwera, a wtyczka wysyła je do SaaS; albo katalog 50 000 SKU i listing generujący setki zapytań SQL na stronę.

Twardy próg: jeśli roczny koszt obejścia (abonamenty + roboczogodziny) przekracza 1,5–2× koszt modułu, moduł zwraca się w pierwszym roku. Moduł za 12 000 zł przy obejściu 20 000 zł/rok daje wskaźnik 1,67 — jesteś w progu.

Kiedy NIE pisać modułu: proces zmieni się w ciągu 6 miesięcy (moduł trafi do kosza szybciej, niż się zwróci), problem dotyczy jednego zamówienia miesięcznie (12 zamówień rocznie zrobisz ręcznie), gotowa wtyczka pokrywa 80% potrzeb. Dorobienie brakujących 20% bywa droższe niż cały gotowiec — więcej o tym w tekście o organizacji pracy z modułami i wtyczkami.

Ile kosztuje moduł na miarę – widełki godzinowe i przykładowe wyceny

Stawka dewelopera PrestaShop i WooCommerce w Polsce to 130–220 zł/h netto przy pracy bezpośrednio z programistą. W agencji, gdzie po drodze jest handlowiec, project manager i tester, licz 250–400 zł/h netto. Różnica nie jest kaprysem — płacisz za koordynację i to, że ktoś dopilnuje terminu, gdy deweloper zachoruje.

Widełki poniżej dotyczą pracy bezpośrednio z deweloperem i są pokazane netto. Traktuj je jako punkt odniesienia do weryfikacji każdej oferty, którą dostaniesz.

Moduł prosty — dodatkowe pole w formularzu, walidacja NIP/REGON, własny sposób dostawy, dopisek do faktury — to 6–16 godzin, czyli około 900–3200 zł netto. Taki moduł zwykle wdraża się w ciągu jednego-dwóch dni roboczych.

Moduł średni — konfigurator produktu, kalkulator kosztu dostawy liczony z wagi i strefy, integracja z jednym API zewnętrznym — to 20–60 godzin, czyli około 2800–11 000 zł netto.

Integracja z ERP (Subiekt, Optima, WF-Mag: stany, ceny, zamówienia, faktury) to 60–200 godzin, czyli około 9000–38 000 zł netto. Tu zakres puchnie najszybciej, bo dochodzi ustalenie, kto jest źródłem prawdy dla stanów magazynowych.

Moduł B2B — ceny indywidualne, limity kredytowe, terminy płatności, zatwierdzanie zamówień przez opiekuna — to 100–250 godzin.

Po wdrożeniu dolicz utrzymanie: 10–20% wartości wdrożenia rocznie (aktualizacje pod nowe wersje PrestaShop, poprawki, monitoring). Moduł za 12 000 zł to 1200–2400 zł rocznie. To nie jest ukryty koszt — to koszt tego, że sklep żyje.

Dlaczego ryczałt bez rozbicia na godziny jest ryzykiem? Bo nie wiesz, co siedzi w zakresie. Pierwsza zmiana wymagania kończy się aneksem, a ty nie masz punktu odniesienia, czy 40 000 zł to dużo czy mało za tę funkcję. Żądaj rozbicia na etapy z godzinami i osobną ceną, płatności po odbiorze każdego etapu oraz zapisu, kto robi testy regresji po aktualizacji sklepu. Szczegóły wyceny i sposób jej rozpisania znajdziesz w artykule o cenniku i organizacji pracy nad niestandardowymi modułami.

Jak przygotować brief, który obniża wycenę o 20–30%

Wycena modułu to w 60–70% koszt analizy i testów, nie samego pisania kodu. Brief skraca analizę o połowę. Bez briefu: 12–18 h analizy i 2–3 rundy poprawek. Z briefem: 6–8 h i jedna runda. Przy stawce 120–180 zł/h różnica to 1500–2500 zł.

Zacznij od ośmiu pytań:

• Kto używa funkcji — magazynier, dział sprzedaży, klient w sklepie?
• Jaki proces zastępuje — przepisywanie zamówień, wysyłka paczek, aktualizacja stanów?
• Co ma się stać przy błędzie — zatrzymać proces, e-mail do obsługi, wpis w logu, ponowienie próby?
• Jakie dane wchodzą — CSV/XML, API, FTP, formularz w panelu?
• Jakie dane wychodzą — PDF, e-mail, zmiana statusu zamówienia, numer listu przewozowego?
• Jak często to działa — raz na dobę o 3:00, przy każdym zamówieniu, na żądanie z panelu?
• Ile rekordów przetwarza — 50 czy 50 000 dziennie, jaki szczyt w Black Friday?
• Kto odbiera efekt — właściciel, księgowość, magazynier, klient końcowy?

Do briefu dołącz trzy rzeczy materialne. Zrzuty ekranu obecnego procesu — pięć–osiem obrazków mówi więcej niż akapit opisu. Przykładowy plik CSV/XML dokładnie w takim formacie, w jakim go dostajesz, plus próbka 5 realnych zamówień (dane osobowe zamaskowane). Oraz dokumentacja API systemu docelowego: ERP, kuriera, fakturowania. Jeśli dostawca jej nie udostępnia, to nie drobiazg, a ryzyko projektu — wykonawca musi je wycenić osobno, często +8–16 h na rozpoznanie i testy.

Kryteria akceptacji spisz przed startem językiem zdarzeń: „moduł wysyła paczkę do InPost i zapisuje numer listu przewozowego w zamówieniu” da się sprawdzić w 10 minut. „Integracja z kurierem” da się interpretować na pięć sposobów i kończy się sporem przy odbiorze.

Podaj wersje środowiska: PrestaShop 1.7.x czy 8.x, PHP 7.4 czy 8.1+, MySQL czy MariaDB i w jakiej wersji, multistore tak/nie, nazwa motywu, istniejące override. Dorzuć listę aktywnych modułów i wtyczek z wersjami — konflikt z gotowym modułem nadpisującym ten sam hook to najczęstsza przyczyna godzin nieujętych w wycenie.

Jak ułożyć z tego dokument i przypisać odpowiedzialności, opisujemy w tekście o organizacji pracy nad modułami dla firmy z Zamościa.

Wdrożenie krok po kroku – 6 etapów od analizy do odbioru

Poniżej realny przebieg projektu modułu w sklepie, w którym brief jest już gotowy.

1. Analiza i brief techniczny — 2–6 h. Efekt: dokument z zakresem, listą hooków i kryteriami akceptacji. Bez tego etapu każdy kolejny punkt się rozjeżdża.
2. Wycena z rozbiciem na etapy i godziny — 1–2 dni. Widełki ±15% i zapisany warunek zmiany zakresu: każda nowa funkcja po akceptacji wyceny to aneks z osobną liczbą godzin.
3. Development na kopii sklepu (staging) — nigdy na produkcji. Kopia z tymi samymi wersjami PHP i bazy, z danymi nieprodukcyjnymi. Praca bezpośrednio na produkcji to najkrótsza droga do sklepu offline w środku dnia handlowego.
4. Testy — 20–30% czasu projektu. Scenariusze podstawowe plus brzegowe: pusty koszyk, błąd API, brak odpowiedzi serwera, podwójne kliknięcie „Zamawiam”. Wydajność sprawdzana przy 100 równoczesnych zapytaniach, jeszcze na staging.
5. Wdrożenie na produkcję w oknie serwisowym — 30–90 min. Punkt przywrócenia (backup plików i bazy) przed zmianą, wdrożenie w godzinach najmniejszego ruchu, po zmianie 3–5 realnych zamówień testowych.
6. Przekazanie — repozytorium, dokumentacja konfiguracji, changelog, 30-dniowy okres gwarancyjny na błędy. Gwarancja obejmuje błędy, nie nowe funkcje.

Realistyczne terminy: moduł prosty 1–2 tygodnie, średni 3–6 tygodni, integracja z ERP 6–12 tygodni. Największe poślizgi nie wynikają z kodowania, a z czekania na dokumentację API i decyzje po stronie klienta. Ustal z góry, kto po Twojej stronie odpowiada na pytania w ciągu 24 h — inaczej każdy tydzień zwłoki przesuwa odbiór.

Praktyczne podejście do organizacji etapów — kto co podpisuje, kiedy i na jakim środowisku testujemy — znajdziesz w materiale o organizacji etapów wdrożenia modułów dla firmy ze Szczebrzeszyna.

Jakość kodu – jak sprawdzić, czy moduł przetrwa najbliższą aktualizację

Zanim podpiszesz umowę, zadaj wykonawcy dziewięć pytań technicznych. Odpowiedzi widać w kodzie po pierwszych 15 minutach przeglądu — poproś o dostęp do repozytorium jeszcze na etapie wyboru oferty.

1. Czy modyfikujecie pliki rdzenia? Każda zmiana w /classes, /controllers czy functions.php motywu to bomba zegarowa. Przy aktualizacji PrestaShop z 1.7.8 na 8.1 plik zostanie nadpisany i sklep padnie. Kod ma siedzieć w module, rdzeń zostaje nietknięty.

2. Jakich hooków używacie? displayHeader, actionValidateOrder, actionPaymentConfirmation — te nazwy pokazują, czy deweloper zna platformę. Implementacja przez override kontrolera zamiast hooka to zwykle 3–5 h dodatkowej pracy przy każdej aktualizacji.

3. Czy override’y są ograniczone do minimum i zapisane w module, nie w motywie? Override w motywie przepada przy zmianie szablonu i nikt o tym nie pamięta do momentu, gdy funkcja przestaje działać.

4. PHP 8.1/8.2 — deklaracja w composer.json i faktyczne testy, nie „powinno działać”.

5. Zapytania SQL poza pętlami, z cache i indeksami. Zapytanie w pętli po 5000 produktów to +1–2 s na stronie kategorii.

6. Obsługa błędów API: timeout, ponowienie, log zdarzeń. Brak odpowiedzi serwera kuriera nie może wywalić koszyka.

7. Klucze API i hasła w konfiguracji modułu lub zmiennych środowiskowych, nie w kodzie źródłowym na repozytorium.

8. Multistore i tłumaczenia, jeśli sklep ma więcej niż jedną wersję językową.

9. README, changelog, numeracja semver — brak tych plików oznacza, że nikt nie pamięta, co zmieniono pół roku temu.

Dokumentacja hooków i standardów platformy jest publiczna — PrestaShop Developer Documentation — więc „tak się przyjęło” nie jest argumentem. Ustal też, kto robi code review i kto odpowiada za testy regresji po aktualizacji. Sposób uporządkowania tej odpowiedzialności opisujemy przy okazji organizacji pracy nad modułami dla firm ze Zwierzyńca.

9 pułapek w zamówieniach modułów i jak je wykryć przed podpisaniem umowy

Większość przepłaconych wdrożeń nie wynika ze złego kodu, tylko z zapisów umowy i sposobu przekazania projektu. Poniżej dziewięć sytuacji, które widzimy najczęściej — każda z jednym pytaniem albo próbą techniczną, którą wykonasz jeszcze przed podpisem. Kolejność zapisów w umowie i podział prac na etapy opisujemy szerzej w materiale o organizacji pracy przy modułach dla Krasnobrodu.

• Pułapka 1 – brak dostępu do repozytorium. Weryfikacja: zażądaj adresu repozytorium Git jeszcze przed startem. W pierwszym tygodniu mają być widoczne pojedyncze commity, nie jeden zbiorczy wrzut na koniec prac.
• Pułapka 2 – „kod pozostaje własnością wykonawcy”. Weryfikacja: w umowie musi być zapis o przeniesieniu majątkowych praw autorskich na zamawiającego wraz z przekazaniem kodów źródłowych. Bez tego nie zlecisz rozwoju nikomu innemu.
• Pułapka 3 – brak okresu gwarancyjnego. Weryfikacja: minimum 30 dni na błędy powstałe w wyniku prac, z definicją błędu i trybem zgłaszania. Zapisz, od kiedy liczy się okres — od odbioru czy od wdrożenia na produkcję.
• Pułapka 4 – ryczałt bez widełek godzinowych. Weryfikacja: poproś o wycenę rozbitą na etapy (analiza, kod, testy, wdrożenie, dokumentacja) z liczbą godzin przy każdym. Jeśli wykonawca nie potrafi rozbić, nie potrafi też kontrolować zakresu.
• Pułapka 5 – hasła i klucze API wprost w kodzie. Weryfikacja: zapytaj, gdzie trafią dane dostępowe. Poprawna odpowiedź: plik konfiguracyjny poza repozytorium albo zmienne środowiskowe na serwerze.
• Pułapka 6 – brak testów na kopii sklepu. Weryfikacja: w harmonogramie musi być osobna pozycja „wdrożenie na staging i testy” przed produkcją, z listą scenariuszy do sprawdzenia (zamówienie, płatność, mail, stany magazynowe).
• Pułapka 7 – dane osobowe klientów wysyłane do zewnętrznego serwisu bez podstawy prawnej. Weryfikacja: zażądaj wykazu odbiorców danych oraz potwierdzenia, że moduł jest opisany w polityce prywatności; przy RODO potrzebna jest podstawa przetwarzania i umowa powierzenia.
• Pułapka 8 – brak dokumentacji konfiguracji. Weryfikacja: dokument z opisem każdego pola w panelu i przykładowymi wartościami jest częścią odbioru. Wpisz to do zakresu, nie zostawiaj „do ustalenia po wdrożeniu”.
• Pułapka 9 – brak SLA po wdrożeniu. Weryfikacja: przed podpisem ustal czasy reakcji i stawkę za godziny po gwarancji. Inaczej każda poprawka staje się osobnym, pilnym zleceniem po stawce interwencyjnej.

Utrzymanie i SLA po wdrożeniu – co powinno znaleźć się w umowie

Wdrożenie to moment, w którym zaczynasz ponosić koszty utrzymania. Bez zapisanych czasów reakcji każda usterka jest „pilna”, a Ty płacisz za każdą godzinę z osobna. Minimalny zestaw, który powinien znaleźć się w umowie, wygląda tak:

Waga zgłoszenia	Przykład	Czas reakcji	Czas naprawy
Krytyczny	Sklep nie przyjmuje zamówień, błąd 500 na koszyku	4 h w godzinach pracy (np. 8–16)	do 1 dnia roboczego
Wysoki	Nie działa jeden operator płatności, błędne stany magazynowe	1 dzień roboczy	do 3 dni roboczych
Standardowy	Literówka w mailu, kosmetyka w panelu	3 dni robocze	wg uzgodnionego planu

Dopisz, co się dzieje z czasem reakcji poza godzinami pracy — albo jest osobna stawka interwencyjna, albo zgłoszenie czeka do rana. Oba warianty są w porządku, byle były zapisane.

Aktualizacje przy zmianach wersji. Ustal, kto wykonuje aktualizację modułu, gdy zmienia się wersja PrestaShop, WooCommerce lub PHP. Tryb powinien być zawsze ten sam: najpierw kopia sklepu, potem produkcja, w oknie serwisowym poza szczytem ruchu. Zakres zmian w kolejnych wydaniach PrestaShop sprawdzisz w dokumentacji dla deweloperów PrestaShop — wykonawca powinien wskazać, które wersje wspiera.

Backupy. Minimum jeden dziennie, przechowywanie 30 dni, a raz na kwartał test odtworzenia na osobnym środowisku. Backup, którego nigdy nie odtworzono, nie jest backupem.

Monitoring. Dostępność sklepu i czas odpowiedzi z alertem, gdy serwer nie odpowiada lub zwraca błędy 5xx. Alert ma dotrzeć do wykonawcy, zanim zadzwoni klient.

Pakiet godzin rozwojowych. Abonament np. 10 h miesięcznie wychodzi 10–20% taniej niż pojedyncze zlecenia. Ustal, czy niewykorzystane godziny przechodzą na kolejny miesiąc — porównanie stawek znajdziesz w materiale o cenniku i organizacji prac przy modułach. Zasada jest prosta: brak opieki po wdrożeniu oznacza, że pierwsza aktualizacja platformy może unieruchomić sklep na kilka dni.

Lokalnie czy zdalnie – Krasnobród, Zamość, Lublin i co realnie z tego wynika

Bliskość wykonawcy ma znaczenie w trzech konkretnych sytuacjach. Pierwsza: analiza procesu, którego nie da się opisać mailem — przyjęcie towaru, strefy w magazynie, korekty stanów, sposób pakowania zamówień zbiorczych. Spotkanie na miejscu w Krasnobrodzie czy Zamościu i przejście przez halę zajmuje pół dnia. To samo ustalane zdalnie potrafi ciągnąć się tygodniami. Druga: fizyczny dostęp do serwera, jeśli trzymasz go u siebie, a nie w chmurze. Trzecia: awaria w środku dnia — dojazd i naprawa na miejscu bywa szybsza niż zdalne diagnozowanie przez kogoś, kto nie zna Twojej infrastruktury.

Czego bliskość nie zastąpi: pracy nad kodem, integracji API (płatności, kurierzy, ERP, fakturowanie), aktualizacji modułu czy zmian w szablonie. To praca zdalna z definicji. Wykonawca z Lublina nie napisze integracji lepiej tylko dlatego, że ma bliżej. Jeśli ktoś sprzedaje lokalność jako argument za wyższą stawką przy czysto kodowym zadaniu, to marketing, nie wartość.

Realna różnica pojawia się w modelu współpracy. Praca bezpośrednio z deweloperem, bez pośrednika, skraca ścieżkę decyzyjną: brief trafia do osoby, która pisze kod, więc nie gubi się w tłumaczeniu między handlowcem a wykonawcą. Płacisz jedną stawkę, a nie trzy marże. Jak wygląda rozbicie kosztów na etapy i co warto porównać w ofertach, opisaliśmy w materiale o koszcie i organizacji projektu modułu. Podobny case z regionu znajdziesz też w tekście o modułach dla firmy ze Zwierzyńca.

Formalności przy zamówieniu w regionie są takie same jak wszędzie: faktura w PLN, umowa o świadczenie usług IT, klauzula poufności i powierzenie danych osobowych w rozumieniu RODO, jeśli moduł dotyka danych klientów. Nie zakładaj, że „swój” wykonawca załatwi to na słowo.

Jak weryfikować wykonawcę z okolicy: portfolio konkretnych modułów, aktywne konto na GitHubie z historią commitów, referencje sklepów, które otworzysz online i sprawdzisz, czy działają. Trzy działające wdrożenia mówią więcej niż dziesięć opinii w internecie.

Najczęstsze błędy i jak je wykryć

Lista kontrolna do odklikania

• Policz koszt obejścia — Abonamenty wtyczek × 12 miesięcy plus roboczogodziny × stawka godzinowa Twojego zespołu. Zrób to przed pierwszym telefonem do wykonawcy.
• Sprawdź pokrycie gotowca — Wypisz na kartce wymagania i zaznacz, ile z nich spełnia istniejąca wtyczka. Powyżej 80% pokrycia zwykle nie warto pisać modułu od zera.
• Sprawdź trwałość procesu — Jeśli w ciągu 6 miesięcy zmieni się regulamin, model sprzedaży albo system księgowy, moduł trzeba będzie przepisać. Poczekaj z decyzją.
• Ustal właściciela i budżet — Jedna osoba, która zna kwotę, zatwierdza zakres i odbiera pracę. Bez tego projekt stoi tygodniami na pytaniu „kto to akceptuje”.
• Zbierz wymagania w jednym pliku — Lista funkcji, przykładowe dane wejściowe i wyjątki (np. co zrobić, gdy API ERP nie odpowiada). Rozproszone ustalenia z maili to główne źródło dopłat.
• Sprawdź integrację z systemem — Subiekt GT, WF-Mag, Comarch Optima, autorski ERP – ustal, czy istnieje gotowy konektor i czy producent systemu udostępnia API oraz dokumentację.
• Wymagaj rozbicia na etapy — Każdy etap z liczbą godzin i stawką, płatność po odbiorze etapu. Tak kontrolujesz budżet i możesz przerwać bez płacenia za całość.
• Ustal format przekazania — Repozytorium Git, plik ZIP do instalacji, dokumentacja konfiguracji, changelog. Sprawdź to w umowie, zanim ruszy kodowanie.
• Ustal prawa do kodu i licencję — Kto jest właścicielem kodu, czy możesz go modyfikować u innego wykonawcy, na ilu instalacjach działa. Zapisz to punktem w umowie.
• Sprawdź środowisko testowe — Kopia sklepu z danymi zbliżonymi do produkcji. Wdrożenie bezpośrednio na działający sklep to prosta droga do utraty zamówień.
• Ustal wymagania wydajnościowe i bezpieczeństwa — Ile zapytań na sekundę, jaki czas odpowiedzi, czy dane klientów mogą opuszczać serwer. Gotowe wtyczki często wysyłają dane do zewnętrznych usług.
• Ustal wsparcie po wdrożeniu — Zakres poprawek w cenie, czas reakcji na błąd krytyczny, kanał zgłaszania. Ustal to przed podpisaniem, nie po pierwszej awarii.
• Zaplanuj budżet utrzymania — 10–20% wartości wdrożenia rocznie na aktualizacje, poprawki i monitoring. Wpisz to do budżetu na kolejny rok.
• Zaplanuj przegląd po aktualizacji platformy — Każda nowa gałąź PrestaShop lub nowa wersja WordPress to test modułu na kopii przed wdrożeniem na produkcję.

Najczęściej zadawane pytania

Źródła i materiały

• Google Search Central – Core Web Vitals
• Google Search Central – tworzenie treści dla ludzi
• Google Search Central – dane strukturalne
• web.dev – Core Web Vitals
• PrestaShop – dokumentacja dla deweloperów