Niestandardowe moduły i wtyczki zamawia się w Lublinie zwykle z jednego powodu: gotowe rozwiązanie nie obsługuje procesu, który w firmie realnie działa. Różnica między udanym a kosztownym wdrożeniem rzadko leży w samym kodzie – leży w organizacji pracy: kto pisze brief, kto testuje, kto odbiera kod i co dzieje się po wdrożeniu. Poniżej zbieramy praktyczne zasady, które stosujemy w projektach PrestaShop i WooCommerce. Jak wygląda to od strony procesu, opisaliśmy na przykładzie organizacji pracy przy modułach w Biłgoraju.
Moduł PrestaShop to katalog w /modules/ z plikiem głównym, w którym klasa dziedziczy po Module. Podpina się do sklepu przez hooki — displayHeader, actionValidateOrder, displayAdminOrder — ma metody install() i uninstall(), własne tabele w bazie i szablony .tpl. Odpowiedzialność jest duża: taki moduł wchodzi w koszyk, zamówienia i faktury, więc jego błąd potrafi zatrzymać sprzedaż na kilka godzin.
Wtyczka WooCommerce to plik PHP z nagłówkiem Plugin Name w katalogu /wp-content/plugins/, korzystający z add_action() i add_filter(). Działa w ekosystemie WordPressa, gdzie o konflikt najłatwiej: motyw, wtyczka do faktur i wtyczka do wysyłki nadpisują te same hooki. Dlatego testy robi się na kopii sklepu z pełnym zestawem dodatków, a nie na świeżej instalacji. Strukturę modułu i wymagania wersji opisuje dokumentacja dla deweloperów PrestaShop.
Typowe zamówienia, które trafiają do nas jako custom:
Custom wygrywa w trzech sytuacjach. Pierwsza: proces jest unikalny i żaden plugin go nie odwzoruje bez wykrzywiania pracy działu. Druga: nie ma odpowiednika na rynku — sprawdź to realnie, wpisując frazę w wyszukiwarkę repozytorium wtyczek i czytając opinie z datą. Trzecia: skala — 150 tys. SKU albo tysiące zamówień dziennie wymagają kodu pisanego pod Twój ruch, a nie uniwersalnego. Jak rozłożyć taki projekt na etapy, opisaliśmy w materiale o organizacji pracy przy niestandardowych modułach i wtyczkach w Józefowie.
Największa różnica nie leży w stawce godzinowej, tylko w tym, z kim rozmawiasz. W modelu z pośrednikiem brief przechodzi przez handlowca i wraca z pytaniami po 2–3 dniach, a każde doprecyzowanie to kolejny cykl. Przy bezpośredniej pracy z deweloperem jedno 40-minutowe spotkanie rozstrzyga więcej niż 15 maili. Jeśli w trakcie rozmowy wychodzi, że problem jest w konfiguracji, a nie w kodzie, słyszysz to od razu — nie po wystawieniu oferty na 80 godzin.
Dostępność w czasie rzeczywistym działa w dwie strony. Ty widzisz postęp w repozytorium i na stagingu, my widzimy błąd na produkcji w kilka minut, a nie po tygodniu opisywania go w zgłoszeniu. Spotkanie w Lublinie albo Zamościu bywa najtańszą częścią projektu: 2 godziny przy komputerze pracownika działu handlu pokazują proces od zapytania ofertowego do faktury lepiej niż kilkustronicowy brief. Zdarza się, że po takim spotkaniu zakres spada o połowę, bo część funkcji jest już w PrestaShop, tylko nikt jej nie włączył.
Lokalny rynek ma swoją specyfikę: zamówienia telefoniczne i mailowe, klienci B2B z odroczonym terminem płatności, dostawy paletowe, sezonowość. To wpływa na projekt panelu — choćby na to, czy status zamówienia zmienia się jednym kliknięciem, czy czterema.
Opieka po wdrożeniu to konkret, nie hasło. Ustal przed podpisaniem umowy: gdzie leży kod (repozytorium Git, nie tylko FTP), kto ma dostęp do serwera, jaki jest czas reakcji na błąd krytyczny (płatności, koszyk) i jaki na drobne poprawki, ile godzin miesięcznie wchodzi w abonament i czy aktualizacja PrestaShop 8.x jest w cenie. Bez tego po roku zostajesz z kodem, którego nikt nie chce dotknąć. Jak wygląda pełny proces od briefu do odbioru, rozpisaliśmy na przykładzie organizacji pracy przy modułach i wtyczkach w Biłgoraju.
Zanim zapłacisz za development, odpowiedz na siedem pytań. Kolejność ma znaczenie — pierwsze trzy potrafią przekreślić projekt taniej wtyczki.
Próg 80/20: jeśli gotowa wtyczka pokrywa 80% potrzeb, taniej jest dopisać brakujące 20% w osobnym module lub wtyczce niż budować całość od zera. Ale uwaga — gdy musisz forkać cudzy kod, przestajesz dostawać aktualizacje i po dwóch latach utrzymanie kosztuje więcej niż własne rozwiązanie. Dlatego przy każdej decyzji pytaj o jedno: kto poprawi ten kod po aktualizacji PHP. Przykład uporządkowanego podejścia do zakresu i odbioru opisaliśmy w artykule o porządku pracy przy modułach i wtyczkach we Frampolu.
| Kryterium | Gotowy moduł / wtyczka | Rozwiązanie custom |
|---|---|---|
| Koszt początkowy | 0–1500 zł licencji, często 0 zł za wersję darmową | zwykle 40–200 godzin pracy, największy wydatek na start |
| Koszt po 12 miesiącach | odnowienie licencji plus czas na konfigurację | 2–6 godzin miesięcznie na poprawki i aktualizacje |
| Ryzyko porzucenia | autor znika, wtyczka przestaje działać po zmianie PHP | kod zostaje u Ciebie, o ile masz dostęp do repozytorium |
| Czas wdrożenia | od 1 dnia do 2 tygodni konfiguracji | od 3 tygodni do 3 miesięcy |
| Wpływ na wydajność | trudny do przewidzenia, zależy od autora | mierzalny — wiesz, ile zapytań dodaje funkcja |
| Kontrola nad zmianami | brak, czekasz na decyzje autora | pełna, zmiany zlecasz w dowolnym momencie |
Pytanie „ile kosztuje niestandardowy moduł albo wtyczka?” nie ma jednej odpowiedzi, bo moduł liczący marżę z dwóch tabel i moduł wystawiający faktury z Subiekta to dwa różne projekty. Dlatego nie podajemy cennika z sufitu — pracujemy na godzinach i rozbiciu na etapy.
Punktem startowym jest analiza: 4–8 h. W tym czasie czytamy kod sklepu, dokumentację API po stronie systemu zewnętrznego i opisujemy realny proces w firmie. Dopiero potem wiadomo, czy mówimy o prostym module, czy o integracji. Typowe zakresy wyglądają tak:
Stawki rynkowe w Polsce w 2025 r. to 120–300 zł/h netto. Freelancer zwykle 120–180 zł/h, doświadczona agencja 180–300 zł/h. Przy 150 zł/h daje to od ok. 2 500 zł za mały moduł z testami i dokumentacją do 60 000 zł i więcej przy integracji ERP. Kwota na fakturze zależy nie od „trudności kodu”, a od czterech rzeczy:
Dlaczego wycena godzinowa jest bezpieczniejsza niż sztywny cennik? Cena stała bez analizy wymaga zamrożenia zakresu „na wyczucie”. Każda zmiana procesu kończy się aneksem, a wykonawca ucina testy, żeby zmieścić się w budżecie. Rozliczenie godzinowe z limitem (np. 60 h z raportem co tydzień) pokazuje, gdzie idą pieniądze. Jak wygląda to w mniejszych miastach regionu, opisujemy przy okazji organizacji pracy przy modułach w Józefowie.
| Zakres prac | Godziny | Koszt przy 150 zł/h netto |
|---|---|---|
| Analiza i brief | 4–8 h | 600–1 200 zł |
| Prosty moduł + testy | 8–20 h | 1 200–3 000 zł |
| Średni moduł | 40–120 h | 6 000–18 000 zł |
| Integracja ERP/CRM | 80–200 h | 12 000–30 000 zł |
| Moduł złożony | 150–400 h+ | 22 500–60 000 zł+ |
Proces wygląda tak samo, niezależnie od tego, czy piszemy wtyczkę do WooCommerce, czy moduł do PrestaShop. Różni się tylko liczbą godzin. Osiem etapów, które u nas zawsze występują:
Kryteria akceptacji spisujemy przed pierwszym commitem — np. „moduł blokuje zapis zamówienia, jeśli suma wag przekracza 30 kg, i pokazuje komunikat z numerem reguły”. Bez tego odbiór zamienia się w dyskusję o gustach. Na koniec klient dostaje repozytorium z dostępem, przeniesienie majątkowych praw autorskich w umowie i instrukcję obsługi. Kolejność etapów w projektach lokalnych opisujemy też w материалах o porządku pracy przy modułach w Krasnobrodzie.
Poniższe błędy widzimy najczęściej w projektach przejmowanych po innych wykonawcach. Dobra wiadomość: większość da się wykryć przed zapłatą faktury.
Jak to sprawdzić w praktyce? Cztery kroki, które zajmą jeden dzień roboczy:
Te same pytania warto zadać na etapie wyboru wykonawcy, nie po wdrożeniu. Więcej o kolejności prac przy modułach piszemy w tekstach o porządku w kodzie modułów w Szczebrzeszynie i w organizacji projektu we Frampolu.
Moduł, który działa poprawnie na jednym zamówieniu, potrafi położyć sklep przy tysiącu. Najczęstsza przyczyna to zapytania SQL w pętli, czyli problem N+1. Moduł pobiera 500 zamówień, a potem dla każdego osobno dociąga dane klienta – 501 zapytań do bazy. Rozwiązanie jest proste: jedno zapytanie z JOIN albo WHERE IN. Zanim odbierzesz kod, poproś wykonawcę o zrzut z EXPLAIN dla najcięższych zapytań i sprawdź, czy kolumny filtrowane (np. date_add w tabeli zamówień) mają indeks.
Cache to drugi nawyk. Dane, które zmieniają się raz na godzinę – listy kategorii, kursy walut, stany magazynowe z zewnętrznego API – nie muszą być pobierane przy każdym wejściu. W PrestaShop służy do tego Cache::getInstance() z TTL, np. 3600 s. Przy integracjach ustal limit zapytań na godzinę i mechanizm backoff, żeby moduł nie zasypał API dostawcy i nie dostał blokady.
Wpływ na Core Web Vitals mierz przed i po wdrożeniu – Lighthouse, PageSpeed Insights, a dla realnych danych użytkowników raport CrUX. Skrypty ładuj z defer lub async, obrazy z lazy-loading. Jeśli moduł dodaje nietypową funkcję (rezerwacje, wydarzenia, katalog), wdroż dane strukturalne JSON-LD zgodne z galerią Google – to realna szansa na wynik wzbogacony.
Bezpieczeństwo: waliduj każdy parametr (Validate::isInt, Tools::getValue), sprawdzaj uprawnienia pracownika, dodawaj token CSRF i chroń własne endpointy frontowe – publiczny kontroler bez tokena to otwarte drzwi. Punktem odniesienia jest OWASP Top 10. Monitoruj wydajność przed i po wdrożeniu – wystarczy log wolnych zapytań albo Blackfire. Jak wygląda porządek w kodzie modułu, opisaliśmy osobno.
| Co sprawdzić | Narzędzie / metoda | Próg akceptacji |
|---|---|---|
| Liczba zapytań SQL | EXPLAIN, log slow queries | brak zapytań w pętli |
| Cache danych z API | Cache::getInstance() + TTL | min. 15 min dla danych rzadkich |
| Core Web Vitals | Lighthouse, CrUX | LCP poniżej 2,5 s |
| Dane strukturalne | Test wyników wzbogaconych | JSON-LD bez błędów |
| Bezpieczeństwo | OWASP Top 10, walidacja | brak otwartych endpointów |
W DropDigital regularnie odradzamy pisanie modułu od zera. Jeśli zmiana dotyczy mniej niż 20% funkcji istniejącej wtyczki, taniej i szybciej jest ją zmodyfikować – przez hook, child theme albo własny plugin nadpisujący. Koszt spada z kilkudziesięciu godzin do kilku. Warunek: wtyczka ma aktywne wsparcie i aktualizacje, a Ty akceptujesz, że po dużej aktualizacji modyfikację trzeba odtworzyć.
Kolejną opcją jest integracja przez API. Jeśli łączysz sklep z ERP, kurierem czy systemem księgowym, często wystarczy REST plus cron co 15 minut. Proces półautomatyczny – import CSV, eksport zamówień, ręczne potwierdzenie w panelu – bywa wystarczający, gdy wolumen to 20–50 zamówień miesięcznie. Nie każdy problem wymaga aplikacji.
SaaS lub zewnętrzne narzędzie wygrywa, gdy problem nie jest unikalny: rezerwacje, faktury, program lojalnościowy, mailing. Płacisz 50–300 zł miesięcznie i nie utrzymujesz kodu. Ryzyko to uzależnienie od dostawcy i wyższe koszty przy wzroście wolumenu.
Overengineering to najdroższy błąd. Własny system zamówień, gdy WooCommerce ma go w core, albo własny panel statystyk, gdy wystarczy analityka – to dług techniczny, który ktoś będzie spłacał latami. Rekomendacja jest zawsze ta sama: zacznij od audytu potrzeb, wypisz proces krok po kroku i policz osoby oraz zamówienia, a potem pytaj o wycenę. Jak wygląda porządek pracy przy modułach we Frampolu, pokazaliśmy na konkretnym przykładzie.
| Opcja | Kiedy sensowna | Orientacyjny koszt | Główne ryzyko |
|---|---|---|---|
| Gotowa wtyczka | Problem standardowy, wsparcie aktywne | 50–300 EUR/rok | Wzrost ceny, koniec rozwoju |
| Modyfikacja istniejącej | Zmiana poniżej 20% funkcji | kilka–kilkanaście godzin | Aktualizacja cofa zmiany |
| Integracja przez API | Dane z ERP, kuriera, księgowości | zależny od zakresu | Limity i zmiany w API |
| SaaS / narzędzie zewnętrzne | Rezerwacje, faktury, mailing | 50–300 zł/mies. | Uzależnienie od dostawcy |
| Custom moduł | Proces unikalny i krytyczny | od kilkudziesięciu godzin | Dług techniczny, brak wsparcia |
Zanim podpiszesz umowę, przejdź przez dwanaście punktów. Każdy z nich to miejsce, w którym projekty custom modułów najczęściej się wykolejają.
Zapisz obok każdego punktu pytania do wykonawcy: kto robi backupy, jak przekazujesz dostęp, co się dzieje, gdy moduł przestanie działać w piątek o 20:00. Jak wygląda organizacja pracy przy modułach w Józefowie, opisaliśmy w osobnym materiale. W DropDigital prowadzimy bezpłatny audyt potrzeb – przechodzimy przez tę listę razem z Tobą i mówimy wprost, czy custom moduł ma sens.
Start developmentu bez analizy technicznej i bez kryteriów akceptacji. Klient opisuje potrzebę ustnie, wykonawca od razu siada do kodu, a po wdrożeniu nie ma na czym oprzeć odbioru.
Jak wykryć: Zapytaj wykonawcę, jak wygląda jego etap analizy i poproś o przykładowy dokument analizy z innego projektu. Jeśli nie potrafi go pokazać, prawdopodobnie pracuje metodą prób i błędów.
Jak naprawić: Przed startem zamroź dokument z opisem procesu, listą integracji i scenariuszami testowymi. Development ruszaj dopiero po akceptacji tego dokumentu przez obie strony.
Brak repozytorium po stronie klienta albo dostęp do niego tylko przez wykonawcę. Kod istnieje wyłącznie na serwerze produkcyjnym.
Jak wykryć: Poproś o adres repozytorium i sprawdź historię commitów. Jeden wpis „init” sprzed dwóch lat to sygnał ostrzegawczy.
Jak naprawić: Ustal w umowie, że repozytorium jest Twoje i masz do niego stały dostęp. Wymagaj commitów opisanych merytorycznie, nie zbiorczych wrzutek raz na kwartał.
Modyfikowanie plików core PrestaShop lub motywu WooCommerce zamiast użycia hooków i nadpisań. Pierwsza aktualizacja kasuje zmiany.
Jak wykryć: Poproś o code review albo listę plików, które moduł zmienia poza własnym katalogiem. Każdy plik spoza katalogu modułu wymaga uzasadnienia.
Jak naprawić: Zleć przepisanie na hooki i mechanizm override. Dokumentacja deweloperska PrestaShop opisuje, gdzie wolno ingerować: devdocs.prestashop-project.org.
Testy wyłącznie na produkcji, bez środowiska stagingowego i kopii bazy.
Jak wykryć: Zapytaj, na jakim adresie zobaczysz wersję testową i czy dane klientów są tam zamaskowane. Brak jednoznacznej odpowiedzi oznacza testy „na żywym organizmie”.
Jak naprawić: Wymagaj stagingu z kopią danych i procedury wdrożenia na produkcję poza godzinami sprzedaży. Ustal, kto odpowiada za backup przed wdrożeniem.
Cała wiedza o module siedzi w głowie jednej osoby. Brak dokumentacji, brak instrukcji konfiguracji, brak kontaktu do nikogo innego w zespole.
Jak wykryć: Poproś o dokumentację i o nazwisko drugiej osoby, która może przejąć projekt. Sprawdź, czy dokumentacja opisuje konfigurację, a nie tylko listę funkcji.
Jak naprawić: Wpisz do umowy obowiązek przekazania dokumentacji i minimum dwie osoby znające projekt. Dodaj zapis o okresie wsparcia po zakończeniu prac.
Umowa bez przeniesienia praw autorskich i bez prawa do modyfikacji kodu przez inny zespół.
Jak wykryć: Przeczytaj umowę pod kątem zapisów o prawach majątkowych i o polach eksploatacji. Milczący brak takiego zapisu działa zwykle na Twoją niekorzyść.
Jak naprawić: Dopisz klauzulę o przeniesieniu praw majątkowych na zamawiającego oraz o prawie do modyfikacji i dalszego rozwoju kodu bez zgody autora.
Nieudane wdrożenia niestandardowych modułów i wtyczek w Lublinie rzadko wynikają z braku umiejętności programisty. Najczęściej brakuje ustalonego procesu: briefu, kryteriów akceptacji, stagingu, repozytorium i dokumentacji. Te pięć elementów kosztuje niewiele na starcie, a oszczędza dziesiątki godzin przy poprawkach. Zanim podpiszesz umowę, sprawdź checklistę powyżej i dopytaj o rzeczy, których wykonawca sam nie poruszył.
Nie, jeśli jest napisany zgodnie z zasadami: przez hooki, bez edycji plików core i bez kopiowania szablonów na sztywno. Problem pojawia się wtedy, gdy moduł nadpisuje core albo korzysta z nieudokumentowanych mechanizmów. Przed wdrożeniem warto ustalić, kto testuje moduł po aktualizacji – to element umowy, nie dobra wola wykonawcy.
Prosty moduł to zwykle 8–20 godzin pracy, czyli od jednego do trzech dni roboczych dewelopera. Funkcja z jedną integracją i własnym panelem konfiguracji to często 40–120 godzin. Terminy zależą też od tego, jak szybko dostarczysz dokumentację API i dostęp do środowiska testowego partnera.
Tak, bez niej wycena jest zgadywaniem. Dokumentacja API systemu ERP lub dostawcy płatności to podstawa analizy technicznej i wyceny godzinowej. Jeśli dokumentacja jest niekompletna, trzeba doliczyć godziny na testy i ustalenia z dostawcą – to realny koszt, który warto znać przed startem.
To zależy wyłącznie od umowy. Standardem przy zamówieniu na wyłączność jest przeniesienie majątkowych praw autorskich na zamawiającego, wraz z prawem do modyfikacji przez inny zespół. Jeśli umowa tego nie reguluje, możesz mieć problem z dalszym rozwojem sklepu u innego wykonawcy.
Tak, część projektów prowadzimy w pełni zdalnie i to działa. Spotkanie na miejscu ma jednak sens wtedy, gdy proces jest zawiły, kilka osób musi się zgodzić co do zakresu, albo trzeba szybko przejrzeć dane i systemy w firmie. Wtedy krótkie warsztaty skracają analizę o kilka dni.
Opis procesu krok po kroku, lista systemów do integracji, kto będzie używał funkcji i jak często, oraz przykłady sytuacji wyjątkowych. Warto dopisać, co ma się stać, gdy integracja nie odpowiada – czy zamówienie ma się wstrzymać, czy trafić do ręcznej obsługi. Im więcej takich szczegółów, tym mniej niespodzianek w wycenie.
Jeśli gotowe rozwiązanie pokrywa około 80% potrzeb, modyfikacja bywa tańsza i szybsza niż pisanie od zera. Trzeba jednak sprawdzić, czy producent wtyczki nie zmieni jej tak, że Twoje zmiany przestaną działać. Przy mocno nietypowym procesie albo wielu integracjach custom zwykle wychodzi taniej w perspektywie dwóch–trzech lat.
Jeśli chcesz przejść przez taki proces krok po kroku, napisz do nas – powiemy wprost, czy w Twoim przypadku wystarczy gotowa wtyczka, czy potrzebny jest custom. Prowadzimy projekty PrestaShop i WooCommerce z Lublina i okolic.