Czym są niestandardowe moduły i wtyczki, a czym nie są

Zacznijmy od rozróżnienia, bo od niego zależy cena. Moduł w PrestaShop to katalog w /modules/ z plikiem głównym (np. mojmodul.php) i klasą dziedziczącą po Module, która podpina się pod hooki (actionValidateOrder, displayShoppingCart). Wtyczka WooCommerce to katalog w /wp-content/plugins/ z nagłówkiem Plugin Name i własnymi hookami, np. woocommerce_checkout_order_processed. W obu przypadkach mówimy o kodzie rozszerzającym logikę sklepu. Modułem nie jest szablon (theme), nie jest nim też wtyczka SEO ani bramka płatnicza pobrana z marketplace.

Zlecenia realnie dzielą się na trzy kategorie:

• drobna modyfikacja istniejącego zachowania — dodatkowa walidacja NIP w checkout, zmiana kolejności pól, inny format numeru zamówienia. Zwykle 4–16 h.
• nowa funkcja od zera — konfigurator produktu, cennik B2B z progami, panel do masowej edycji. Zwykle 40–160 h.
• integracja z systemem zewnętrznym — ERP, płatności, kurier, marketplace. Zwykle 60–200 h, bo dochodzi czytanie dokumentacji API i obsługa błędów.

Kiedy moduł nie jest potrzebny. Trzy sytuacje zdarzają się najczęściej. Pierwsza: funkcja już istnieje w panelu — PrestaShop ma wbudowane grupy klientów, przedziały cenowe i reguły podatkowe, WooCommerce — kupony z warunkami. Druga: wystarczy reguła w posiadanej wtyczce, np. ukrycie ceny dla gości ustawiane w opcjach. Trzecia: problem jest po stronie serwera, nie kodu — „sklep wolno działa” to często memory_limit, stary PHP albo brak indeksów w bazie. Jeśli wykonawca proponuje płatny moduł na pierwszą lub drugą sytuację, zapytaj o uzasadnienie.

Sygnały, że czas na moduł własny: powtarzalna praca ręczna (codzienne przepisywanie zamówień do Subiekta), wymóg procesowy (indywidualne ceny dla kontrahentów B2B, limity kredytowe) albo zewnętrzny system bez gotowego łącznika. Strukturę katalogu i hooki opisuje dokumentacja dla deweloperów PrestaShop — warto zajrzeć przed rozmową z wykonawcą, żeby wiedzieć, o co pytać. Jeśli rozszerzasz sklep poza standard, sprawdź też, jak podchodzimy do modułów PrestaShop.

Własny moduł czy płatna wtyczka z marketplace: policz to na 3 lata

Policzmy to na trzy lata, bo na tym horyzoncie różnice przestają być teoretyczne. Założenia: stawka 150 zł/h, kurs 4,30 zł/EUR. Podstaw własne liczby i przelicz ponownie — chodzi o metodę, nie o konkretne widełki.

W wariancie marketplace zakładasz, że wtyczka robi dokładnie to, czego potrzebujesz. Każde odstępstwo kosztuje. Nie da się „dopisać” czegoś do cudzego kodu bez forka, a fork oznacza, że tracisz aktualizacje i bierzesz na siebie odpowiedzialność za bezpieczeństwo.

Wariant własny: 3 200 zł jednorazowo za moduł, który robi jedną rzecz i nic poza tym, plus ok. 2 h rocznie na utrzymanie — głównie sprawdzenie po aktualizacji PrestaShop i poprawki pod nową wersję PHP. Po trzech latach: 3 200 zł + 3 × 300 zł = 4 100 zł. Marketplace: 3 × 258 zł licencji + 12 h wdrożenia (1 800 zł) + 3 × 3 h obejść (1 350 zł) = ok. 3 924 zł.

Wniosek jest niewygodny dla obu stron: na trzech latach jest remis. Przewaga własnego modułu rośnie w czwartym i piątym roku oraz wtedy, gdy wtyczka zaczyna kolidować z aktualizacjami.

Marketplace wygrywa, gdy funkcja jest standardowa, działa u setek sklepów, autor żyje ze wsparcia i nie potrzebujesz żadnych zmian.

Własny moduł wygrywa, gdy proces jest specyficzny dla Twojej firmy, wtyczka nadpisuje szablony (a Ty masz własny), produkt ma współpracować z Twoim ERP/B2B albo potrzebujesz dostępu do kodu.

Ryzyko ukryte: brak dostępu do kodu to brak możliwości naprawy. Gdy autor porzuci wtyczkę albo nie wyda wersji pod nowe PHP lub nowy sposób przechowywania zamówień w WooCommerce (HPOS), zostajesz z niedziałającym elementem checkoutu. Przed zakupem sprawdź datę ostatniej aktualizacji i listę wspieranych wersji — szczegóły znajdziesz w dokumentacji WooCommerce. Więcej o łączeniu gotowych komponentów z kodem pod proces piszemy przy okazji aplikacji dedykowanych.

Co firmy zamawiają najczęściej — 9 typowych zleceń

Poniżej dziewięć zleceń, które wracają najczęściej. Czasy są orientacyjne i zakładają, że masz dostęp do dokumentacji API oraz środowiska testowego. Rozrzut wynika z jakości API partnera, nie z widzimisię wykonawcy — integracja z dobrze udokumentowanym API to dolna granica, z API „na maila” — górna.

Trzy pułapki, które podnoszą koszt niezależnie od punktu z listy. Pierwsza: brak środowiska testowego po stronie systemu zewnętrznego — kod trzeba wtedy pisać „na produkcji”, co wydłuża pracę i zwiększa ryzyko. Druga: brak zdefiniowanego pliku produkcyjnego (DXF, PDF, CSV) przed startem konfiguratora — zmiana formatu po wdrożeniu to zwykle powtórka połowy pracy. Trzecia: limity kredytowe i indywidualne rabaty B2B wymagają uzgodnienia z księgowością, bo moduł tylko pokazuje decyzję, a nie podejmuje jej za Ciebie. Ten sam schemat zleceń wraca w różnych miastach — zobacz np. niestandardowe moduły i wtyczki dla firm w Krasnobrodzie, żeby porównać zakres.

Proces wdrożenia krok po kroku: od briefu do przekazania kodu

Zamówienie modułu ma sześć etapów. Poniżej rozkład, który stosujemy w projektach dla firm — z punktami kontrolnymi po drodze.

1. Warsztat 30–60 min. Zamiast listy życzeń („chcę jak w Allegro”) opisujesz proces: kto wystawia fakturę, skąd idą stany magazynowe, co się dzieje przy zamówieniu towaru, którego nie ma. Wynik: jednostronicowy opis procesu i lista systemów do integracji.
2. Specyfikacja funkcjonalna. Każda pozycja z liczbą godzin i jawnym „poza zakresem”. Przykład zapisu: „Eksport zamówień do ERP — 18 h; poza zakresem: faktury korygujące, obsługa wielu magazynów”. Bez tego zdania każdy spór o zakres kończy się sporem o pieniądze.
3. Środowisko testowe i working demo. Pracujemy na kopii sklepu z odizolowaną bazą i wyłączonymi płatnościami produkcyjnymi. Link do demo dostajesz na starcie, nie na końcu. Jeśli wykonawca nie potrafi podać adresu stagingu, to go nie ma. Strukturę modułu i hooki opisuje dokumentacja dla deweloperów PrestaShop.
4. Testy na scenariuszach. Zamówienie w trzech wariantach (przedpłata, pobranie, płatność odroczona), błąd API zwracający 500, brak stawki kuriera, plik 40 MB wgrywany przez klienta. Do tego przypadki brzegowe: rabaty łączone, druga waluta, stan magazynowy zero, przerwana płatność.
5. Wdrożenie produkcyjne w oknie serwisowym — np. wtorek 6:00–8:00 — plus plan wycofania: kopia bazy i plików przed zmianą oraz procedura przywrócenia w 15 minut.
6. Przekazanie: repozytorium Git z tagiem wersji, dokumentacja instalacji krok po kroku, 30–60 min nagranego instruktażu, okres wsparcia na błędy (typowo 30 dni).

Jeśli pracujesz na PrestaShop, zakres typowych wdrożeń modułowych znajdziesz w sekcji PrestaShop – moduły i integracje.

Ile to kosztuje: wycena godzinowa i realne widełki

Wycena bez godzin to wycena bez pokrycia. Kwota zawsze wynika z prostego mnożenia: godziny × stawka. Poniżej widełki, które w praktyce się sprawdzają przy typowych zamówieniach.

7 pułapek przy zamawianiu modułu i jak je wykryć przed umową

Każda pułapka ma jedno pytanie i jeden sygnał ostrzegawczy. Zadaj pytanie mailem — odpowiedź „na piśmie” jest dowodem.

• 1. Brak przekazania kodu źródłowego. Pytanie: „Czy po zapłacie prawa majątkowe przechodzą na mnie, a kod trafia do mojego repozytorium?” Sygnał ostrzegawczy: „Damy dostęp do panelu, kod zostaje u nas” albo brak repozytorium w umowie.
• 2. Modyfikacje w rdzeniu sklepu. Pytanie: „Zmiany idą w override/ i moduł, czy w pliki core?” Sygnał: „Zrobimy na szybko w core, to działa” lub nadpisywanie classes/Cart.php.
• 3. Praca prosto na produkcji. Pytanie: „Podaj adres stagingu i kopię bazy, na której będę testować.” Sygnał: „Testujemy na produkcji, ruch jest mały”.
• 4. Dane zapisane nietypowo, bez migracji. Pytanie: „W jakich tabelach zapisujecie dane i co się stanie przy aktualizacji platformy oraz przy odinstalowaniu modułu?” Sygnał: „Wrzucimy to w istniejące pole”, brak skryptu migracji i brak uninstall().
• 5. Brak dokumentacji i kontakt po zakończeniu. Pytanie: „Ile dni wsparcia po odbiorze i jak zgłaszam błędy?” Sygnał: „Proszę dzwonić, jak coś nie działa” bez numeru zgłoszenia i bez terminu reakcji.
• 6. Wycena po jednej rozmowie, bez analizy. Pytanie: „Ile godzin na pozycję i co jest poza zakresem?” Sygnał: „Stała cena 3000 zł za wszystko” — porównaj z widełkami godzinowymi powyżej; brak godzin oznacza brak podstawy.
• 7. Klucze API w kodzie lub pliku tekstowym. Pytanie: „Gdzie będą przechowywane sekrety i dane dostępowe?” Sygnał: „W config.php w module” albo klucz wklejony w treści maila. Powinny trafić do zmiennych środowiskowych lub menedżera sekretów.

To samo sprawdzenie warto przejść przy powtórzeniach projektu w innych miastach — patrz organizacja zamówienia modułów i wtyczek (Zamość).

Utrzymanie i aktualizacje: co dzieje się z modułem po wdrożeniu

Moduł zamówiony raz nie zostaje taki sam. Zmienia się środowisko wokół niego, a Ty najczęściej dowiadujesz się o tym z maila „sklep nie nalicza kosztów dostawy”. Najczęstsze przypadki:

• Aktualizacja PHP na hostingu — dostawca włącza PHP 8.2, a moduł korzysta z funkcji usuniętych w tej wersji. Objaw: błąd 500 przy koszyku albo zapis Deprecated w logach.
• Aktualizacja PrestaShop lub WooCommerce — zmiany w hookach, w strukturze zamówień (np. przejście WooCommerce na HPOS) lub wycofanie starego API szablonu koszyka.
• Zmiana API kuriera albo operatora płatności — dostawca przełącza autoryzację na OAuth, zmienia endpoint lub format etykiety, a moduł dalej wysyła stary komunikat.
• Aktualizacja szablonu — nowy motyw nadpisuje pliki .tpl lub template WooCommerce; moduł wypada z układu albo przestaje się wyświetlać.

Roczny rytm utrzymania to trzy powtarzalne czynności: przegląd logów błędów, test po każdej aktualizacji platformy i kontrola zgodności z wersją PHP. Minimum monitoringu: logi błędów, powiadomienie o nieudanym zadaniu cron (heartbeat co 5–15 minut) i alert przy błędach API, np. przy odpowiedzi 429.

SLA zapisz konkretnie: czas reakcji (np. 4 godziny w dni robocze), czas naprawy, godziny objęte pakietem i to, co jest poza nim — nowe funkcje, konsekwencje zmian po stronie zewnętrznego dostawcy, prace powyżej ustalonej liczby godzin. Osobny punkt: kopie zapasowe i plan wycofania. Przed każdą aktualizacją robisz dump bazy i kopię plików. Wyłączenie modułu nie może blokować składania zamówień — dane zamówień zostają w bazie, a sklep działa dalej. To warunek, który warto wpisać do umowy razem z zasadami pracy nad modułami PrestaShop. Zmiany po stronie platformy śledzisz w dokumentacji dla deweloperów PrestaShop, gdzie publikowane są informacje o kompatybilności i kolejnych wersjach.

Praca z wykonawcą z Bydgoszczy i okolic — co ustalić na starcie

Nie ma jednej dobrej odpowiedzi na pytanie „lokalnie czy zdalnie”. Wszystko zależy od tego, czego dotyka wdrożenie.

Obecność na miejscu ma sens, gdy:

• integracja dotyka sprzętu w firmie — wagi, drukarki etykiet Zebra, czytnika kodów, terminala magazynowego,
• planujesz warsztat projektowy (1–2 dni) i wolisz narysować proces na tablicy niż opisywać go w mailach,
• robisz większą migrację danych z ERP (Subiekt, Comarch Optima) do sklepu i trzeba na bieżąco weryfikować mapowanie pól.

Praca zdalna wystarcza przy modułach, wtyczkach, integracjach API i optymalizacji — pod trzema warunkami: wykonawca dostaje środowisko testowe (staging, nie produkcję), masz wyznaczony kanał kontaktu (Slack, Teams) i na koniec każdego etapu jest demo. Bez dostępu do stagingu i kontaktu z osobą decyzyjną zdalny projekt rozciąga się przez same doprecyzowania.

Przed pierwszym spotkaniem przygotuj cztery rzeczy: opis procesu krok po kroku (kto klika co i gdzie), dostępy do stagingu, przykład dokumentacji systemu ERP (fragment XML lub JSON faktury z nazwami pól) i listę 5 najczęstszych problemów w panelu. Do tego jedna decyzja: kto po Twojej stronie odbiera pracę i podpisuje protokół.

Formalności ustal na starcie: umowa z zakresem i kryteriami odbioru, NDA jeśli dane są wrażliwe, liczba godzin w pakiecie, kto odpowiada za kopie zapasowe (zwykle właściciel serwera, ale musi to być zapisane) oraz dostęp do repozytorium — prywatne repo Git, do którego masz wgląd i które zostaje u Ciebie po zakończeniu. Płatność w transzach powiązanych z etapami. Jeśli szukasz szerszego kontekstu, zobacz aplikacje dedykowane i materiał o organizacji pracy przy niestandardowych modułach i wtyczkach. Kompatybilność wtyczki z kolejnymi wersjami platformy sprawdzaj w dokumentacji WooCommerce.

Rozmawiaj bezpośrednio z osobą, która pisze kod. Każdy pośrednik to dodatkowe przekazywanie zakresu „z głowy do głowy” i kilka dni straconych na ustalenia, które przy bezpośrednim kontakcie zajmują jedno spotkanie.

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

Lista kontrolna do odklikania

• Proces spisany na papierze — Rozpisz krok po kroku, co dzieje się od złożenia zamówienia do wystawienia faktury. Dopiero ten opis da się zamienić na zakres zlecenia i wycenę.
• Policzony czas pracy ręcznej — Zmierz, ile minut dziennie lub tygodniowo zajmuje przepisywanie danych między systemami. 20 minut dziennie to ponad 80 godzin w roku.
• Sprawdzone opcje natywne — Przejdź po ustawieniach koszyka, promocji, grup klientów i wysyłki, zanim uznasz, że funkcji brakuje.
• Sprawdzone istniejące wtyczki — Zajrzyj w ustawienia wtyczek, które już masz. Wiele z nich ma reguły i warunki, których nigdy nie włączyłeś.
• Wersje systemu i PHP — Zapisz dokładną wersję PrestaShop lub WooCommerce oraz PHP, a także wersję bazy danych. To pierwsza rzecz, o którą zapyta wykonawca.
• Lista aktywnych wtyczek i modułów — Konflikty najczęściej wynikają z nakładania się dwóch rozszerzeń na ten sam fragment sklepu. Zestawienie warto mieć przygotowane przed rozmową.
• Dostęp do kodu wtyczki z marketplace — Sprawdź, czy kupujesz kod, czy tylko prawo do korzystania. Bez dostępu do kodu nie naprawisz niczego, gdy autor porzuci projekt.
• Kryteria odbioru — Ustal, po czym poznasz, że działa. Konkretne scenariusze: zamówienie zagraniczne, zwrot, brak stanu magazynowego, anulowanie po opłaceniu.
• Środowisko testowe — Kopia sklepu plus dane sandboxowe od systemu zewnętrznego. Bez tego pierwszym testerem jest Twój klient.
• Repozytorium i właściciel kodu — Ustal, gdzie trafia kod i kto ma do niego dostęp. Zapisz to w umowie, nie w mailu.
• Zakres wsparcia po wdrożeniu — Ustal, ile godzin miesięcznie obejmuje opieka i co dzieje się, gdy sklep zmieni wersję PHP. To pozycja, o której zapomina się najczęściej.
• Kopie zapasowe i procedura wycofania — Przed aktualizacją produkcyjną: pełna kopia plików i bazy oraz sprawdzony sposób powrotu do poprzedniej wersji.
• Koszty na trzy lata — Zsumuj licencję, odnowienia, wdrożenie i utrzymanie. Porównuj warianty w tym samym horyzoncie czasowym, nie po cenie pierwszego roku.
• Jedna osoba decyzyjna — Wykonawca potrzebuje jednego kanału decyzyjnego. Ustal, kto zatwierdza zakres i kto odbiera prace, żeby nie wracać do ustaleń po fakcie.

Najczęściej zadawane pytania

Źródła i materiały

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