Czym są niestandardowe moduły i wtyczki w sklepie internetowym

Zanim przejdziemy do wycen, trzeba rozdzielić trzy pojęcia, które w rozmowach z wykonawcami padają zamiennie: moduł, wtyczka i integracja. To nie to samo i inaczej się je wycenia.

Moduł PrestaShop to katalog w /modules/ — np. /modules/mojmodul/ — z plikiem głównym o tej samej nazwie, klasą dziedziczącą po Module i metodą install(), która rejestruje hooki (displayHeader, actionCartSave, actionValidateOrder, displayAdminOrder). Dane trzyma się w tabelach opisanych przez ObjectModel, a panel konfiguracji buduje getContent() z użyciem HelperForm. Struktura katalogów i kolejność wywołań hooków są opisane w dokumentacji deweloperskiej PrestaShop — warto zajrzeć choćby po to, żeby ocenić, czy wykonawca mówi o tym samym systemie.

Wtyczka WooCommerce to plik PHP z nagłówkiem Plugin Name, podpięty przez add_action() i add_filter(), komunikujący się z koszykiem i zamówieniem przez REST API (/wp-json/wc/v3/) albo klasy WC_Order i WC_Cart. Pułapka ostatnich lat: HPOS, czyli własne tabele zamówień w WooCommerce. Wtyczka napisana kilka lat temu, która czyta postmeta zamiast $order->get_meta(), po włączeniu HPOS po prostu przestaje widzieć dane.

Moduł to nie integracja. Integracja to wymiana danych z systemem zewnętrznym: InPost ShipX, DPD, Subiekt, Comarch Optima. Moduł to miejsce, w którym ta logika mieszka. Bez modułu nie ma gdzie zapisać numeru listu przewozowego ani statusu przesyłki; bez integracji moduł nie ma skąd wziąć tych danych.

• Konfiguracja gotowego produktu — 0 godzin kodu: reguły koszyka w PrestaShop (Katalog → Rabaty → Reguły koszyka), strefy wysyłki i przedziały wagowe w WooCommerce.
• Modyfikacja istniejącego modułu — nadpisanie w /override/ ginie przy aktualizacji sklepu, a fork oznacza, że aktualizacje producenta przestają przychodzić.
• Moduł od zera — pełna kontrola nad logiką, ale utrzymanie i zgodność z kolejnymi wersjami PHP leżą po Twojej stronie.

Uczciwa uwaga: nie każdy problem wymaga kodu. Zanim zamówisz moduł „gratis przy trzeciej sztuce”, sprawdź reguły koszyka — to często dwie godziny konfiguracji, nie dwadzieścia godzin pracy.

Kiedy własny moduł wygrywa, a kiedy gotowa wtyczka wystarczy

Decyzja sprowadza się do jednego pytania: czy to, czego potrzebujesz, da się kupić, czy trzeba napisać. Poniżej sygnały, które w praktyce rozstrzygają sprawę.

Pisz własne, gdy: logika jest Twoja i tylko Twoja — ceny B2B zależne od historii zamówień, indywidualne progi rabatowe per kontrahent, harmonogram dostaw ustalany ręcznie; dane muszą trafić do wewnętrznego systemu, do którego nie ma gotowego konektora; na rynku nie ma produktu, który robi choćby połowę tego, czego potrzebujesz.

Kup gotowe, gdy: wysyłka i płatności są standardowe, nie ma nietypowych reguł, a koszt wtyczki jest niższy niż 20 godzin pracy dewelopera. Oficjalne wtyczki bramek (Przelewy24, PayU, Stripe) i kurierów są aktualizowane po zmianach API — Ty tego nie utrzymujesz.

Sygnał ostrzegawczy: gotowa wtyczka robi 80% tego, czego potrzebujesz, a ostatnie 20% wymaga forka. Od tego momentu nie dostajesz aktualizacji producenta, a każda aktualizacja WooCommerce lub PrestaShop to ryzyko, że coś się rozsypie.

Przed zakupem sprawdź trzy rzeczy: datę ostatniej aktualizacji, liczbę aktywnych instalacji i deklarowane wsparcie (PHP 8.x, HPOS w WooCommerce).

Liczba godzin to najprostszy filtr: poniżej 20 h zwykle wygrywa gotowe rozwiązanie, 20–60 h to strefa modułu dedykowanego, powyżej 60 h warto najpierw zawęzić zakres do MVP. Jeśli pracujesz z zespołem w regionie, organizacja pracy przy niestandardowych modułach i wtyczkach w Lublinie wygląda podobnie — brief, etapy, odbiór.

Przykłady z praktyki: integracja z InPost ShipX (30–60 h), eksport i import ofert do ERP (40–80 h), konfigurator produktu B2B (60–120 h).

Ile to realnie kosztuje: widełki godzinowe i model rozliczenia

Rozliczaj za godziny pracy, nie za „wdrożenie”. Pozycja „wdrożenie modułu — 8000 zł” nie mówi nic o zakresie ani o tym, co się stanie, gdy po testach okaże się, że trzeba dopisać obsługę zwrotów.

Stawka godzinowa dewelopera w regionie lubelskim to realnie 120–170 zł/h netto przy mniejszych firmach i 200–250 zł/h netto przy specjalizacji (integracje ERP, moduły płatnicze). Widełki rynkowe domykają się w przedziale 120–250 zł/h netto.

Trzy typowe wyceny, które można porównać:

Doliczaj koszty ukryte: 10–20% budżetu na testy, dokumentację i wdrożenie na produkcji. Jeśli ktoś tego nie wpisał w ofertę, wpisze w fakturę później — jako „prace dodatkowe”.

TCO w praktyce. Subskrypcja wtyczki 300–900 zł/rok przez 5 lat to 1500–4500 zł, ale dostajesz aktualizacje i wsparcie. Moduł dedykowany za 45 h × 150 zł = 6750 zł to koszt jednorazowy plus utrzymanie raz na 2–3 lata — zwykle 5–15% wartości modułu rocznie, na samo utrzymanie zgodności z nową wersją PrestaShop lub PHP.

Kiedy zapłacisz podwójnie: gdy moduł został napisany bez dokumentacji i bez repozytorium. Kolejny wykonawca nie analizuje cudzego kodu za darmo — wycenia przepisanie od zera. Dlatego w umowie zapisz: repozytorium Git przekazane na Twoje konto, README z instalacją i konfiguracją, opis hooków i tabel, dane dostępowe w Twoim menedżerze haseł, płatność w etapach (np. 30/40/30) i zapis, że kod przechodzi na Twoją własność po zapłacie. Jak to wygląda krok po kroku poza Lublinem, opisujemy przy okazji organizacji pracy przy niestandardowych modułach i wtyczkach w Biłgoraju.

Jak wygląda proces: od briefu do wdrożenia modułu

Wdrożenie modułu do PrestaShop albo wtyczki do WooCommerce da się zamknąć w pięciu krokach. Każdy ma konkretny produkt na wyjściu — jeśli wykonawca go nie dostarcza, to sygnał ostrzegawczy.

Krok 1 — warsztat i brief. Dwie–trzy godziny z ludźmi, którzy realnie pracują w sklepie: handlowiec, magazyn, księgowość. Wypisujecie przypadki użycia („zamówienie powyżej 5 000 zł trafia do ręcznej weryfikacji"), dane wejściowe (ID zamówienia, status, kwota, metoda dostawy), dane wyjściowe (zapis do tabeli, e-mail, wpis w logu) i osoby decyzyjne po stronie klienta. Efekt: zakres MVP na jednej stronie A4. Bez tego każde „a dodajmy jeszcze" rozjeżdża budżet. Zasady porządkującej prace przy takich wdrożeniach trzymamy zwykle tak samo niezależnie od miasta — zobacz, jak opisujemy to na przykładzie organizacji pracy przy niestandardowych modułach w Lublinie.

Krok 2 — wycena w godzinach. Nie w dniach roboczych i nie w widełkach „od–do". Rozbicie na etapy plus osobna lista rzeczy poza zakresem: migracja starych danych, drugie API kurierskie, tłumaczenia, panel dla klienta.

Krok 3 — środowisko testowe. Kopia sklepu na stagingu z tymi samymi wersjami PHP (np. 8.1), MySQL/MariaDB, motywu i modułów co produkcja. Baza skopiowana z produkcji, ale z anonimizacją danych klientów. Bez tego test wydajności nic nie znaczy.

Krok 4 — krótkie iteracje. Demo co 1–2 tygodnie na stagingu, na realnych danych. Kod trafia do repozytorium Git należącego do klienta — nie wykonawcy. Jeśli deweloper wyjdzie z projektu, nie zostajesz z niczym.

Krok 5 — odbiór i wdrożenie. Deploy na produkcję poza godzinami ruchu, zawsze po kopii zapasowej plików i bazy. Dokumentacja powdrożeniowa: co robi moduł, jakie hooki obsługuje (np. actionValidateOrder, actionOrderStatusPostUpdate), gdzie leżą logi i jak go wyłączyć bezpiecznie. Nazwy hooków i sposoby ich rejestracji opisuje dokumentacja dla deweloperów PrestaShop.

Pułapki, które najczęściej psują wdrożenie i jak je wykryć

Sześć problemów wraca w niestandardowych modułach najczęściej. Każdy ma jednoznaczny sposób wykrycia — wystarczy zadać właściwe pytanie albo zajrzeć w logi.

• Forkowanie gotowej wtyczki zamiast rozszerzenia. Wykonawca kopiuje cudzy plugin i dopisuje swoje. Pytanie kontrolne: „skąd bierzemy aktualizacje bezpieczeństwa?". Odpowiedź „będziemy ręcznie mergować" oznacza, że przy najbliższej łatce w oryginale zostajesz z dziurą. Lepiej: własny moduł korzystający z hooków oryginału.
• Brak zgodności z PHP 8.x. Objaw: białe ekrany i ostrzeżenia deprecated. Wykrycie: staging na PHP 8.1/8.2, włączone raportowanie błędów, log deprecated i error_log przejrzany po każdym scenariuszu.
• Konflikt z cache i kompilacją szablonów. Jeśli moduł działa po odświeżeniu strony, a przestaje działać po wyczyszczeniu cache, to problem z hookami albo z kompilacją Smarty/Twig — nie z danymi.
• Zapytania do bazy w pętli (N+1). Objaw: kategoria z 300 produktami generuje się o 3–4 s dłużej po włączeniu modułu. Wykrycie: profilowanie (Xdebug, Query Monitor w WooCommerce) i slow_query_log z long_query_time = 0.5.
• Brak obsługi błędów API zewnętrznego. Co się dzieje, gdy kurier zwraca 429 albo timeout 30 s? Zamówienie nie może zawisnąć w połowie. Potrzebny retry z backoffem i status „do ponowienia" widoczny w panelu.
• Hardkodowane dane. ID kategorii, klucze API, adresy e-mail wpisane w kod. Test: zmień ID kategorii w panelu — jeśli potrzebny jest deweloper, moduł jest źle napisany. Kolejność prac porządkujemy podobnie jak w projekcie niestandardowych modułów i wtyczek w Krasnobrodzie.

Testy i odbiór: jak sprawdzić, czy moduł jest gotowy na produkcję

Odbiór „na słowo" to najdroższy scenariusz. Poniższe testy możesz zlecić wykonawcy albo przejść sam na stagingu — każdy ma kryterium zaliczenia.

Scenariusze brzegowe. Puste pole wymagane, błędny kod pocztowy (00-000), zamówienie z 30 pozycjami, kod rabatowy 100%, zamówienie anulowane już po nadaniu etykiety, płatność odrzucona przez bramkę. Każdy przypadek zapisz w protokole z wynikiem „OK / błąd" i zrzutem ekranu.

Wydajność. Zmierz czas ładowania strony produktu i koszyka przed włączeniem modułu i po. Cel: różnica poniżej 100 ms. Powtórz pomiar trzy razy po wyczyszczeniu cache, a nie raz na rozgrzanym sklepie. Sposób mierzenia realnego doświadczenia użytkownika opisuje web.dev — Web Vitals. Jeśli moduł sam zaciąga dane z zewnątrz, sprawdź też, czy nie blokuje renderowania.

Aktualizacja platformy. Na kopii stagingu wykonaj aktualizację PrestaShop/WooCommerce do kolejnej wersji i przejdź te same scenariusze. Moduł napisany na hookach zwykle przeżyje — ten oparty na nadpisywaniu plików rdzenia prawie nigdy.

Test wyłączenia. Moduł musi dać się wyłączyć jednym kliknięciem bez błędów 500 w kolejce i bez psucia złożonych zamówień. Sprawdź to na stagingu: wyłącz, złóż zamówienie, włącz z powrotem.

Odbiór formalny. Protokół z listą przypadków testowych i wynikami, przekazane repozytorium Git, dokumentacja i dane dostępowe. Bez tego nie masz czego reklamować. Standard porządkowania tych kroków opisujemy też przy niestandardowych modułach i wtyczkach w Zwierzyńcu.

Utrzymanie po wdrożeniu: aktualizacje, monitoring i SLA

Moduł, który działa w dniu odbioru, nie działa wiecznie. PrestaShop i WooCommerce wydają nowe wersje, a hosting podnosi wersję PHP — kod napisany pod starsze środowisko potrafi wywalić błąd 500 przy pierwszej aktualizacji. Dlatego roczny koszt utrzymania modułu przyjmuje się na 10–20% wartości wdrożenia. Moduł za 6 000 zł to 600–1 200 zł rocznie: aktualizacje pod nowe wersje platformy i PHP, testy na kopii sklepu, poprawki po zmianach w API zewnętrznym.

• Aktualizacje. Przed każdą wgrywamy kopię bazy (dump .sql) i katalog /modules lub /wp-content/plugins. Najpierw staging, potem produkcja. Retencja kopii minimum 30 dni i trzymanie ich poza serwerem produkcyjnym — kopia na tym samym dysku nie jest kopią.
• Monitoring. Log błędów sklepu (w PrestaShop katalog /var/logs, dodatkowo error_log PHP) plus cron pilnujący kolejki synchronizacji z ERP lub kurierem. Alert mailem albo SMS-em, gdy zadanie zwróci błąd lub API odpowie kodem 4xx/5xx.
• Healthcheck. Raz na dobę sprawdzenie, czy ostatnia synchronizacja faktycznie się wykonała, a nie tylko „nie zgłosiła błędu”. Brak błędu w logu i brak danych w sklepie to dwie różne sytuacje.

Zakres SLA zapisujemy w umowie, nie w mailu — to najczęstszy punkt sporny przy awarii.

Zmiany zakresu po wdrożeniu. Nowa funkcja to nowa wycena godzinowa, a nie „drobna poprawka” robiona po godzinach. Bez tego po pół roku nikt nie wie, ile moduł naprawdę kosztował. Jeśli koszt łatanie modułu pod nową architekturę platformy przekracza 30–40% pierwotnego wdrożenia, taniej jest przepisać go od zera niż poprawiać co kwartał. Zakres zmian śledzimy w dokumentacji dla deweloperów PrestaShop, a schemat organizacji pracy przy takich projektach opisujemy w materiale o organizacji pracy przy niestandardowych modułach.

Bełżec i okolice: jak zamówić moduł bez spotkań w Warszawie

Bełżec, Tomaszów Lubelski, Zamość — odległość nie zmienia procesu. Moduł zamawia się tak samo zdalnie, o ile na starcie jest brief na piśmie: cel, użytkownicy, przebieg procesu, integracje, kto odbiera pracę. Do tego demo online na działającym stagingu i jedno miejsce na zgłoszenia, zamiast wątku mailowego z dziesięcioma odpowiadającymi.

• Demo online 30–45 minut. Deweloper klika po stagingu z danymi testowymi: zamówienie testowe, konto sandbox kuriera. Slajdy nie pokazują, czy moduł zapisuje dane.
• Wspólny staging od pierwszego dnia. Kopia sklepu z produktami i zamówieniami testowymi. Tam klient sprawdza działanie, zanim cokolwiek trafi na produkcję.
• Dostępy bezpiecznym kanałem. Hasła przez menedżer haseł, nie mailem ani komunikatorem. Konto techniczne z minimalnymi uprawnieniami, nie główny administrator. Po wdrożeniu dostępy są odbierane, a klucze API trzymane w pliku .env poza repozytorium.
• Repozytorium po stronie klienta. Kod w Git (GitHub/GitLab), własne konto klienta i pełna historia zmian. To warunek, żeby móc zmienić wykonawcę bez zaczynania od zera.

Kiedy warto spotkać się na miejscu: warsztat zbierający wymagania (2–4 h), szkolenie pracowników z panelu modułu, odbiór przy sklepie z osobami, które będą go używać na co dzień. Poza tymi trzema sytuacjami dojazd nie wnosi nic poza kosztem.

Rozmowa bezpośrednio z deweloperem, bez pośredników, skraca drogę od zgłoszenia do poprawki — problem nie jest tłumaczony trzeci raz przez kolejną osobę.

Realistyczne terminy: prosty moduł 1–2 tygodnie, średni 3–5 tygodni, integracja z ERP 6–10 tygodni. Podobnie pracujemy z firmami z Józefowa i z Krasnobrodu — proces jest identyczny, różni się tylko miejsce odbioru.

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

Lista kontrolna do odklikania

• Spisany zakres i kryteria akceptacji — Przed podpisaniem umowy — jeden dokument z listą funkcji, przypadków brzegowych i punktów odbioru.
• Estymacja godzinowa zamiast ceny za wdrożenie — Na etapie oferty — poproś o rozbicie na zadania i stawkę godzinową netto.
• Dostęp do repozytorium Git — Przed startem prac — repo po stronie klienta albo zapis w umowie o przekazaniu dostępu.
• Środowisko staging z kopią bazy — Przed pierwszym wdrożeniem — żeby nie testować zmian na działającym sklepie.
• Zgodność wersji silnika i PHP — Na starcie i przed każdą aktualizacją — sprawdź wersję PrestaShop lub WooCommerce oraz wersję PHP na serwerze.
• Backup plików i bazy przed wgraniem — Bezpośrednio przed wdrożeniem — z potwierdzoną możliwością szybkiego przywrócenia.
• Lista hooków i miejsc w szablonie — W briefie — które hooki modyfikujesz, czy nadpisujesz szablon, czy dodajesz własny.
• Scenariusze testowe zamówienia — Przed odbiorem — nowe zamówienie, płatność, etykieta, anulowanie, zwrot, zamówienie B2B z indywidualnym rabatem.
• Wpływ na czas ładowania — Po wdrożeniu — zmierz Core Web Vitals na stronie produktu i w koszyku, porównaj z pomiarem sprzed zmiany.
• Dokumentacja powdrożeniowa — Przy odbiorze — README: co robi moduł, gdzie są ustawienia, jak go bezpiecznie wyłączyć.
• Osoba decyzyjna po stronie firmy — Przed startem — jedna osoba zatwierdza zakres i odbiera prace, żeby uniknąć sprzecznych uwag.
• Koszt utrzymania w budżecie — Przy planowaniu — dolicz 10–20% budżetu na testy i wdrożenie oraz przegląd modułu raz na 2–3 lata.
• Plan wyjścia — Przy odbiorze — kod, baza, dostępy i dokumentacja zostają po Twojej stronie, niezależnie od dalszej współpracy.

Najczęściej zadawane pytania

Źródła i materiały

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