Niestandardowe moduły i wtyczki Szczecin dla firmy to temat, w którym najwięcej pieniędzy traci się nie na kodzie, a na organizacji: źle nazwanym zleceniu, briefie bez kryteriów akceptacji i braku audytu wersji przed wyceną. Efekt jest przewidywalny – wykonawca wycenia coś innego, niż potrzebujesz, a różnica wraca jako „zmiana zakresu” i dodatkowa faktura. Poniżej znajdziesz zestaw zasad, które da się zastosować przed wysłaniem pierwszego zapytania: jak nazywać artefakt, jak wykryć problem wcześnie i jak sprawdzić wykonawcę. To część organizacyjna cyklu o niestandardowych modułach i wtyczkach.
Zacznijmy od słownika, bo tu robi się najdroższy bałagan. „Moduł” w PrestaShop to katalog w /modules/nazwa-modulu/ z plikiem głównym rozszerzającym klasę Module. Działa przez hooki: hookDisplayHeader, hookDisplayProductAdditionalInfo, actionDispatcher, actionCartSave. „Wtyczka” to WordPress: katalog w /wp-content/plugins/, nagłówek z Plugin Name i Requires PHP, kod podpinany przez add_action() i add_filter() w Plugin API. Inne cykle życia, inne debugowanie, inna osoba to ogarnie. Zlecenie „wtyczka do PrestaShop” to sygnał, że wykonawca doliczy godziny na tłumaczenie.
Kiedy gotowiec z PrestaShop Addons albo WordPress.org w pełni wystarcza? Cztery warunki naraz:
Brak któregokolwiek punktu oznacza, że zaczynasz płacić za cudzy dług techniczny.
Koszt utrzymania zależy od wersji. Moduł pod PrestaShop 1.7 wymaga innej obsługi niż 8.x – inne hooki, inny panel, w 8.x PHP 8.1+ i wycofane funkcje legacy. Wtyczka WP musi działać na PHP 8.2 i WP 6.x, bo po aktualizacji hostingu dostaniesz błąd 500 na stronie głównej.
Pięć pytań, które zadaj sobie przed wysłaniem zapytania:
Bez odpowiedzi na pytania 2 i 4 wykonawca wyceni coś innego niż potrzebujesz. Zanim to zrobisz, zobacz, jak u nas wygląda wdrożenie i utrzymanie modułów PrestaShop.
| Aspekt | Moduł PrestaShop | Wtyczka WordPress/WooCommerce |
|---|---|---|
| Lokalizacja kodu | /modules/nazwa-modulu/ | /wp-content/plugins/nazwa/ |
| Mechanizm rozszerzeń | hooki: hookDisplay*, action*, actionDispatcher | Plugin API: add_action(), add_filter() |
| Wersje do wsparcia | 1.7 i 8.x – różne hooki i wymagania PHP | WP 6.x + PHP 8.2 |
| Typowy koszt utrzymania | 15–25% wartości wdrożenia rocznie | 15–25%, wyżej przy integracjach |
Nie ma progu „powyżej X zł robimy custom”. Jest siedem sygnałów, które sprawdzasz przed podpisaniem umowy.
WP_DEBUG – biały ekran.Dwa z siedmiu sygnałów to jeszcze nie wyrok. To argument, żeby wycenić custom i porównać go z kosztem utrzymania gotowca przez 24 miesiące – wtedy decyzja jest liczbą, a nie wrażeniem.
Wycena customu jest do sprawdzenia, jeśli wykonawca podaje godziny i stawkę. Trzy progi pokrywają około 90% zleceń.
Stawki rynkowe w Polsce: 120–250 zł/h netto. Dolna granica to proste moduły WooCommerce, górna – PrestaShop 8.x z integracją ERP i migracją danych. Stawka 80 zł/h zwykle oznacza, że ktoś uczy się na Twoim projekcie, a Ty płacisz za to czasem i błędami na produkcji.
Budżet dzielisz tak: analiza 10–15%, development 60–70%, testy 15%, dokumentacja 5%. Jeśli w ofercie nie ma pozycji „testy”, nie będzie ich też w projekcie.
Utrzymanie: 15–25% wartości wdrożenia rocznie. Przy modułach integracyjnych bywa wyżej, bo API kurierów i bramek zmieniają się 2–4 razy w roku i ktoś musi to poprawić w ciągu dni, nie miesięcy.
Czego nie ma w wycenie modułu: hosting/VPS (50–300 zł/mies.), licencje zewnętrzne, opłaty za API kurierów i bramek płatniczych, SSL, CDN. To osobne koszty i powinny być w ofercie widoczne, a nie doliczone po odbiorze. Moduł jest często elementem większego systemu, więc porównaj go z tym, jak liczą się aplikacje dedykowane – tam dochodzi backend i panel administracyjny.
Przykład: moduł łączący InPost Paczkomaty, DPD i DHL z wyborem przewoźnika po wadze i strefie. Analiza kont i zakresów: 12 h. Development: 90 h (trzech integratorów, własny panel, logi). Testy: 20 h, w tym zamówienia testowe i generowanie etykiet. Dokumentacja: 6 h. Razem 128 h × 160 zł/h = około 20 500 zł netto. Utrzymanie w pierwszym roku ok. 20%, czyli 4 100 zł. Umowy i opłaty po stronie kurierów są poza tym budżetem.
| Próg złożoności | Zakres godzin | Co zwykle obejmuje |
|---|---|---|
| Prosty | 16–40 h | jeden hook lub punkt integracji, brak panelu w adminie, dane z jednego źródła |
| Średni | 40–120 h | własny panel, 1–2 integracje API, import/eksport, uprawnienia |
| Zaawansowany | 120–400 h | wielu przewoźników lub ERP, kolejkowanie, logika cenowa, migracja danych, testy |
Wdrożenie niestandardowego modułu da się rozpisać na sześć etapów, z których każdy kończy się akceptacją po stronie klienta. Brzmi banalnie, ale to brak akceptacji na etapach generuje potem „zmiany zakresu”.
displayShoppingCartFooter), nadpisane szablony w katalogu motywu, wtyczki porzucone (ostatnia aktualizacja 3 lata temu). Wynik to notatka na piśmie: co jest, co koliduje, czego nie ruszamy.Na koniec klient dostaje trzy rzeczy: repozytorium Git z historią commitów, dokumentację techniczną (hooki, tabele w bazie, zadania cron) oraz instrukcję dla administratora sklepu – jak wyłączyć moduł, gdzie szukać logów, co i gdzie zgłaszać. Jeśli wykonawca nie potrafi wskazać tych trzech elementów już na etapie wyceny, to sygnał ostrzegawczy. Więcej o samej organizacji pracy pisaliśmy w tekście Niestandardowe moduły i wtyczki: organizacja pracy, a przykłady wdrożeń zebraliśmy w sekcji Aplikacje dedykowane.
| Krok | Czas | Artefakt kończący etap |
|---|---|---|
| 1. Audyt instalacji | 1–3 h | Notatka: wersje, konflikty, ryzyka |
| 2. Brief techniczny | 2–4 h warsztatu | User stories + kryteria akceptacji |
| 3. Makieta i MVP | 1–2 dni | Rysunek przepływu, lista MVP |
| 4. Sprinty + demo | zależnie od zakresu | Działający moduł na stagingu co tydzień |
| 5. Testy | 4–8 h | Wypełniona checklista przedwdrożeniowa |
| 6. Wdrożenie + monitoring | 14 dni | Repozytorium, dokumentacja, instrukcja |
Katalog wtyczek pokrywa większość typowych potrzeb i prawie nigdy nie pokrywa tej jednej rzeczy, która decyduje o marży. Poniżej obszary, w których najczęściej trzeba pisać własny kod.
Jeśli sklep działa na PrestaShop, większość takich integracji i tak dotyka koszyka, zamówienia i statusów – warto zacząć od wdrożeń i modułów PrestaShop. Przykład rozłożenia takiego zakresu na etapy opisaliśmy też przy okazji projektu Niestandardowe moduły i wtyczki Zamość dla firmy – organizacja.
| Obszar | Co zawodzi w gotowej wtyczce | Co trzeba dopisać |
|---|---|---|
| ERP | Jeden kierunek, jedna wersja programu | Kolejka zadań, mapowanie dokumentów, obsługa błędów |
| Płatności B2B | Brak płatności odroczonej i limitów | Reguły limitów, częściowe płatności, zwroty |
| Kurierzy | Jeden przewoźnik, jeden format etykiety | Weryfikacja webhooków, wiele formatów etykiet |
| Hurtownie | Brak retry i kolejkowania | Rate limiting, ponawianie, log importu |
Cała Polska to jedna strefa czasowa, więc argument „muszę mieć wykonawcę za rogiem” dotyczy zwykle czegoś innego niż praca – poczucia kontroli. Da się je osiągnąć bez przeprowadzki dewelopera.
Warto porównać to z tym, jak wygląda organizacja po drugiej stronie Polski – np. w tekście Niestandardowe moduły i wtyczki Zwierzyniec dla firmy albo Niestandardowe moduły i wtyczki Krasnobród dla firmy. Zasady są te same, różni się tylko liczba kilometrów.
Wniosek: lokalizacja ma znaczenie przy warsztacie i szkoleniu, nie przy kodzie. Przy kodzie liczy się repozytorium, SLA i to, czy ktoś odbiera telefon, gdy sklep nie przyjmuje zamówień.
| Priorytet zgłoszenia | Czas reakcji | Czas rozwiązania |
|---|---|---|
| Krytyczny – sklep nie przyjmuje zamówień | 2 h w dni robocze | 8 h roboczych lub obejście problemu |
| Wysoki – błędna cena lub brak synchronizacji | 1 dzień roboczy | 3 dni robocze |
| Standard – zmiana treści, pytanie | 2 dni robocze | wg osobnego zlecenia |
Pierwsza zasada: kod modułu istnieje wyłącznie w repozytorium Git. Nie w edytorze plików na FTP, nie w katalogu modules na produkcji, nie w ZIP-ie wysłanym mailem. Jeśli wykonawca poprawia pliki bezpośrednio na serwerze, nie masz historii zmian, nie cofniesz wdrożenia i nie ustalisz, która wersja modules/mojmodul/mojmodul.php jest aktualna. Typowy scenariusz: poprawka „na szybko” o 14:00, a o 15:00 aktualizacja modułu z panelu kasuje zmiany.
Druga zasada: kod trzyma się standardów – WordPress Coding Standards dla WordPressa i WooCommerce, PrestaShop Coding Standards dla PrestaShop – i działa na PHP 8.x. Na PHP 8.2 niezdefiniowana zmienna to widoczny warning w logach, a nie cichy błąd, a kolejny programista czyta kod zgodny z dokumentacją, zamiast odtwarzać intencje autora.
Trzecia: każdą aktualizację PrestaShop (np. 1.7.8 → 8.1) lub WooCommerce testujesz najpierw na kopii – staging z kopią bazy i tym samym zestawem modułów. Na produkcję wchodzisz po testach, nie zamiast nich.
Przekazanie projektu to nie „hasło do FTP”. Musi zawierać: repozytorium z pełną historią commitów i dostępem dla Ciebie; instrukcję instalacji z wymaganymi wersjami PHP i PrestaShop/WooCommerce, kolejnością wdrożenia i migracjami bazy; dokumentację hooków (nazwa, co robi, jakie dane przyjmuje i zwraca) oraz endpointów (metoda, ścieżka, autoryzacja, przykładowe zapytanie).
Osobna pułapka to ionCube. Moduł zakodowany oznacza brak źródła: nie poprawisz go, nie przeniesiesz na inny serwer i nie sprawdzisz, co wysyła na zewnątrz. Masz licencję na używanie cudzego kodu, nie kod. Przy rozbudowie sklepu na PrestaShop to najczęstsza przyczyna zdania „nie da się tego ruszyć”.
Klucze API i dostępy: zasada minimalnych uprawnień (osobne konto dla modułu, tylko potrzebne zakresy, brak panelu hostingowego, jeśli wystarczy samo API) i rotacja wszystkich kluczy oraz haseł po zakończeniu współpracy. To 15 minut pracy, które odcina byłych wykonawców od systemu.
Audyt zacznij od faktów, nie od wrażeń. Otwórz listę modułów, zanotuj wersje i porównaj z datą ostatniej aktualizacji oraz z wersją sklepu. Moduł nietknięty od dwóch lat przy sklepie na PrestaShop 8 to nie „stabilny”, a porzucony.
Cache::store().sanitize_text_field(), Validate::isCleanHtml()) i escapowanie wyjścia (esc_html(), esc_attr(), Tools::safeOutput()). Przejrzyj endpointy: w WordPressie listę REST przez /wp-json/, w PrestaShop kontrolery frontowe. Publiczny endpoint bez autoryzacji to zaproszenie do nadużycia.TTFB jest częścią Web Vitals, więc wolny moduł kosztuje nie tylko komfort użytkownika. Zasady nazywania i opisywania tego, co zamawiasz, zebraliśmy w materiale o organizacji pracy przy niestandardowych modułach i wtyczkach.
| Obszar | Co sprawdzić | Sygnał ostrzegawczy |
|---|---|---|
| Technika | Data ostatniej aktualizacji, wspierana wersja PHP i PrestaShop/WooCommerce | Brak changelogu, deklaracja PHP 5.x, brak zgodności z wersją Twojego sklepu |
| Wydajność | Wpływ na TTFB, liczba zapytań do bazy, cache ciężkich operacji | Wzrost TTFB powyżej 150 ms, N+1 zapytań w pętli, brak cache dla eksportów i importów |
| Bezpieczeństwo | Walidacja wejścia, escapowanie wyjścia, endpointy publiczne | Dane z formularza trafiają do bazy bez walidacji, aktywny endpoint bez autoryzacji |
| Utrzymanie | Dostęp do repozytorium, dokumentacja, właściciel aktualizacji | Tylko pliki na FTP, brak dokumentacji, aktualizacje „zależą od wykonawcy” |
Zlecanie „wtyczki do PrestaShop” albo „modułu do WordPressa” – mylenie nazewnictwa już na etapie zapytania.
Jak wykryć: W swoim briefie nie podajesz nazwy platformy i wersji, a wykonawca dopytuje o hooki, Plugin API albo strukturę katalogu /modules. Albo odwrotnie – dostajesz ofertę, w której nie ma ani jednego słowa o platformie.
Jak naprawić: Ustal jedną rzecz przed rozmową: PrestaShop (moduł, katalog /modules, rejestracja hookami) czy WordPress/WooCommerce (wtyczka, Plugin API, add_action/add_filter). Wpisz platformę i wersję w tytule zapytania, żeby nie trafić do wykonawcy, który specjalizuje się w drugim stacku.
Brief, który mówi „ma działać jak u konkurencji” bez opisania procesu.
Jak wykryć: Nie umiesz w trzech krokach powiedzieć, co ma się stać po kliknięciu „Zapytaj o wycenę” – kto dostaje wiadomość, co się dzieje z koszykiem, gdzie ląduje plik. Każde pytanie wykonawcy kończy się odpowiedzią „to zależy”.
Jak naprawić: Rozpisz user stories w formacie „jako [rola] chcę [akcja], żeby [efekt]” i dopisz do każdej 2–3 kryteria akceptacji. To dokument, który da się wycenić punktowo, a nie zgadywać.
Wycena przyjmowana bez audytu instalacji.
Jak wykryć: Wykonawca podaje kwotę „na oko” po screenie z panelu, nie pytając o wersję PrestaShop/WooCommerce, wersję PHP ani listę aktywnych modułów. W ofercie nie ma pozycji „audyt”.
Jak naprawić: Zaakceptuj audyt jako płatny etap 1–3 h i wpisz go do umowy. Bez listy aktywnych modułów i wykrytych konfliktów każda wycena custom modułu jest szacunkiem, a nie ofertą.
Kupowanie i utrzymywanie gotowej wtyczki, która realizuje 20% funkcji.
Jak wykryć: Zrób dwie kolumny: „dopasowanie” i „braki”. Jeśli braków jest więcej niż dopasowań, a mimo to płacisz i utrzymujesz 100% cudzego kodu – właśnie tam jest problem. Dodatkowo autor nie odpowiada na zgłoszenia.
Jak naprawić: Policz realny koszt: licencja roczna + czas na obejścia + ryzyko konfliktu przy każdej aktualizacji. Często taniej wychodzi mały custom moduł pod jeden proces niż trzy wtyczki spinane „na styk”.
Brak właściciela kodu i brak repozytorium po wdrożeniu.
Jak wykryć: Po odbiorze kod istnieje tylko na serwerze produkcyjnym, nie ma repo, nie ma tagu wersji, a zmiany robi się przez FTP. Nikt nie wie, która wersja pliku jest aktualna.
Jak naprawić: W umowie zapisz: repozytorium Git z historią, środowisko testowe (staging), dokumentacja instalacji i szkolenie 1–2 h dla osoby, która przejmie utrzymanie.
Mieszanie budżetu wdrożenia z kosztami zewnętrznymi.
Jak wykryć: Porównujesz dwie oferty, z których jedna zawiera licencje i opłaty za API, a druga nie – i wybierasz tańszą pozycję wiersza, nie tańszy projekt. Potem okazuje się, że brakuje hosting/VPS, licencji zewnętrznych, opłat za API kurierów i bramek płatniczych.
Jak naprawić: Wymagaj rozbicia oferty na: analiza, development, testy, dokumentacja oraz osobna sekcja „poza wyceną”. To jedyny sposób, żeby porównywać oferty tej samej długości.
Wdrożenie prosto na produkcji, bez etapu testów.
Jak wykryć: W harmonogramie nie ma okna testowego, a zmiany pojawiają się na żywym sklepie w godzinach sprzedaży. Klient dowiaduje się o błędzie z maila od klienta, nie z raportu.
Jak naprawić: Wpisz do harmonogramu osobny etap testów (zwykle 15% budżetu) na kopii instalacji, z listą scenariuszy: koszyk, płatność, faktura, etykieta kurierska, mail do klienta.
Organizacja projektu custom modułu jest ważniejsza niż sam wybór technologii. Nazwij artefakt po platformie, wymagaj audytu instalacji przed wyceną i rozbij ofertę na analizę, development, testy oraz dokumentację. Wymagaj kryteriów akceptacji na piśmie i repozytorium po odbiorze – to dwie rzeczy, które najczęściej decydują o tym, czy moduł da się utrzymać po dwóch latach. Jeśli szukasz szerszego kontekstu, zobacz aplikacje dedykowane.
Nie. Lokalizacja ma znaczenie praktyczne głównie przy spotkaniach i reakcji na awarię w godzinach pracy, a nie przy samym kodzie. Liczy się stack wykonawcy: doświadczenie w PrestaShop albo w WooCommerce i integracjach. Jeśli szukasz wykonawcy w Szczecinie, pytaj o konkretne wdrożenia z tych samych wersji platformy, na których pracujesz.
To zależy od złożoności. Prosty moduł to zwykle 16–40 h pracy, średni 40–120 h, a zaawansowany z integracjami zewnętrznymi 120–400 h. Do tego dolicz analizę 10–15% budżetu i testy 15%. Realny harmonogram zawsze warto rozpisać z kamieniami milowymi i akceptacją po każdym etapie.
Architektonicznie to dwa różne światy. Moduł PrestaShop to katalog osadzony w /modules, rejestrowany hookami i wpinający się w cykl życia sklepu przez actionDispatcher oraz displayHook. Wtyczka WordPress działa przez Plugin API i funkcje add_action oraz add_filter. Konsekwencja praktyczna: inny jest koszt utrzymania, bo moduł pod PrestaShop 1.7 wymaga innej obsługi niż pod 8.x, a wtyczka WP musi działać na PHP 8.2 i aktualnym WP 6.x. Możesz o tym poczytać w sekcji o PrestaShop.
Gdy spełnia cztery warunki naraz: obsługuje standardowy koszyk, nie wymaga integracji z ERP, autor jest aktywny, a ostatnia aktualizacja jest młodsza niż 6 miesięcy. Jeśli któryś z tych punktów nie działa, zacznij liczyć koszt obejść i ryzyko konfliktu przy następnej aktualizacji. Wtedy wybór między gotowym a custom przestaje być kwestią upodobań.
Typowo 15–25% wartości wdrożenia rocznie. Przy modułach integracyjnych ten procent bywa wyższy, bo dochodzą zmiany po stronie zewnętrznych API. W budżecie utrzymania uwzględnij też aktualizacje platformy i wersji PHP – to one najczęściej wymuszają poprawki w kodzie modułu.
Powinieneś dostać kod w repozytorium wraz z historią zmian, dokumentacją instalacji i informacją, gdzie znajdują się konfiguracje. To standard, który warto zapisać w umowie przed startem, a nie ustalać po odbiorze. Jeśli dostajesz tylko pliki na FTP bez repo, utrzymanie modułu przez kogoś innego będzie trudniejsze i droższe.
Gdy wtyczka realizuje 20% potrzebnej funkcji, a płacisz i utrzymujesz 100% kodu. Podobnie gdy wchodzi w konflikt z innym modułem, gdy proces jest specyficzny (cenniki kontrahentów B2B, konfigurowalna wycena, zamówienia na zapytanie) albo gdy limit API zewnętrznego wymaga własnej kolejki i obsługi błędów. W takich przypadkach dopłata za custom zwraca się szybciej, niż się wydaje.
Jeśli chcesz, żeby ktoś przeszedł z tobą przez audyt instalacji i pomógł rozłożyć brief na etapy, napisz do nas – powiemy wprost, co da się zrobić gotowym rozwiązaniem, a co wymaga custom modułu.