Własny moduł czy gotowa wtyczka: decyzja w pięciu pytaniach

Decyzję „gotowiec czy własny kod” rozstrzygniesz w pięciu pytaniach. Zadaj je sobie przed wysłaniem zapytania do wykonawcy — odpowiedzi potrafią zmienić wycenę o kilka tysięcy złotych w obie strony.

1. Czy proces jest krytyczny dla sprzedaży? Jeśli jego awaria zatrzymuje zamówienia (konfigurator, progi rabatowe B2B, wysyłka do ERP), potrzebujesz kodu, którego autor odbierze telefon. Gotowiec od nieznanego wydawcy to ryzyko.
2. Czy wymaga logiki, której nie ma na rynku? Sprawdź Addons PrestaShop i repozytorium wtyczek WooCommerce, wpisując nazwę mechaniki, nie produktu: „tier pricing”, „B2B price rules”, „product configurator”, „packstation choose”.
3. Czy dane muszą iść do ERP? Ręczny eksport CSV i mapowanie kolumn to 20–40 minut dziennie. Przy 300 zamówieniach miesięcznie robi się z tego etat.
4. Czy koszt licencji rośnie z obrotem? Wtyczki rozliczane od liczby zamówień lub SKU zjadają marżę dokładnie wtedy, gdy firma rośnie.
5. Czy aktualizacje platformy będą łamać gotowca? Przejście PrestaShop 1.7 → 8.x i wdrożenie HPOS w WooCommerce to znane punkty łamania starszych wtyczek.

Prosty rachunek: licencja 600 zł rocznie × 3 lata = 1800 zł. Własny moduł w PrestaShop to zwykle 4000–7000 zł netto plus 15–20% rocznie na utrzymanie (600–1400 zł). Tani gotowiec wygrywa na papierze, dopóki nie doliczysz czasu na obejścia. Własny kod broni się wtedy, gdy daje przewagę procesową, a nie tylko brak opłaty.

Kiedy wszystkie odpowiedzi brzmią „nie”, własny kod to wyrzucone pieniądze: standardowe metody dostawy i płatności, zwykłe progi rabatowe (w PrestaShop reguły cenowe, w WooCommerce kupony z ograniczeniami), koszyk, faktury PDF, podstawowa integracja z kurierem przez gotowy moduł. Konfiguracja wystarcza. Kontekst organizacyjny takich projektów opisujemy w tekście o niestandardowych modułach i wtyczkach w Zamościu. Jeśli i tak piszesz kod, zacznij od dokumentacji deweloperskiej PrestaShop — struktura hooków i rejestracja modułu są tam opisane bezpośrednio.

Co realnie da się zamknąć w module: dziesięć przypadków z polskich sklepów

Poniższe przypadki wracają w firmach z Zamościa i okolic najczęściej. Każdy da się zamknąć w module PrestaShop albo wtyczce WooCommerce, ale nie każdy w ten sam sposób — różnice widać dopiero przy utrzymaniu.

• Indywidualne progi rabatowe dla klientów B2B: 8% od 2000 zł, 12% od 5000 zł, osobno dla grup klientów, osobno dla kategorii.
• Wycena produktu konfigurowalnego: cena zależna od wymiaru, materiału i dodatków (meble, okna, opakowania).
• Automatyczna wysyłka danych zamówienia do ERP: XML lub API po zmianie statusu na „zrealizowane”.
• Własna logika darmowej dostawy: próg 300 zł, ale tylko paczkomat i tylko produkty z jednej kategorii.
• Mapowanie metod płatności: przelew tylko powyżej 500 zł, za pobraniem do 2000 zł, faktura z odroczonym terminem wyłącznie dla grupy B2B.
• Wybór paczkomatu z limitem wagi: przy koszyku 30 kg punkty InPost (limit 25 kg) znikają z listy.
• Generowanie etykiet InPost, DPD i DHL z panelu, z zapisaniem numeru przesyłki do zamówienia.
• Własne statusy zamówień: „w kompletacji”, „częściowo wysłane”, z automatyczną informacją do klienta.
• Synchronizacja stanów magazynowych z hurtowni w cyklu co 15 minut.
• Program lojalnościowy z zasadami, których nie obsłuży żadna gotowa wtyczka (np. punkty tylko za produkty z marżą powyżej 20%).

Ile to kosztuje: widełki godzinowe i jak czytać ofertę

Wycena modułu do PrestaShop albo wtyczki do WordPressa to zawsze dwie liczby: stawka godzinowa i liczba godzin. W projektach dla MŚP w Polsce stawki układają się w trzech pasmach: 120–180 zł/h za prostą implementację (hooki, szablony, dodatkowe pola), 180–280 zł/h za pracę z API, płatnościami i bazą danych, 250–400 zł/h i więcej, gdy dochodzi ERP, nietypowa logika rabatowa albo prace poza godzinami pracy sklepu. To wartości orientacyjne – ostateczna cena zależy od zakresu i tego, czy dostawca startuje z własnego szablonu modułu, czy pisze wszystko od zera.

Budżet warto dostać rozbity na etapy. Zdrowa proporcja wygląda tak:

• analiza i brief – 10–15% budżetu,
• implementacja – 50–60%,
• testy – 15–20%,
• wdrożenie na produkcję – 5–10%,
• dokumentacja i przekazanie – 5%.

Pracochłonność: mały moduł (np. pole NIP z walidacją i zapisem do zamówienia) to 16–40 godzin. Średni (integracja z bramką płatniczą, własne statusy zamówień, eksport do pliku) – 60–120 godzin. Złożony (dwukierunkowa synchronizacja z ERP: stany, ceny, faktury) startuje od 150 godzin i potrafi przekroczyć 400. Pytaj o te liczby wprost, bo oferta bez godzin jest nieporównywalna z żadną inną.

Czerwone flagi: jedna kwota bez rozbicia na etapy, „wycena od sufitu” bez podania pracochłonności, brak informacji, ile kosztuje godzina pracy po wdrożeniu i kto płaci za poprawki po aktualizacji PrestaShop. Stawkę powdrożeniową i zakres wsparcia wpisz do umowy, zanim zaczniesz.

Koszt, o którym nikt nie mówi, to czas twojego zespołu: 10–20 godzin na brief, przygotowanie danych testowych (produkty z wagą i wymiarami, 200–500 zamówień w kopii bazy, konta sandbox kurierów) i testy akceptacyjne. Zaplanuj to jako realny koszt – bez tego moduł nie ma na czym pracować. Jak rozłożyć te zadania w kalendarzu, opisuję w materiale o organizacji pracy przy niestandardowych modułach w Lublinie.

Integracje z ERP, płatnościami i kurierami: gdzie pękają wdrożenia

Najwięcej wdrożeń wywraca się nie na kodzie, a na kolejności prac. Poprawna sekwencja: 1) kontrakt danych – dokument z listą pól, typami, kierunkiem przepływu i częstotliwością (np. stany magazynowe co 15 minut, faktury raz na godzinę); 2) kod modułu; 3) środowisko testowe po stronie ERP; 4) produkcja. Jeśli dostawca ERP mówi „napiszcie najpierw, potem zobaczymy”, to znak, że punkt 1 został pominięty.

Limity API to druga pułapka. Sprawdź w dokumentacji, ile zapytań na minutę dostajesz, co zwraca kod 429 i 5xx oraz jak długo wolno ponawiać. Standard: ponowienie z rosnącym opóźnieniem (1 s, 2 s, 4 s, 8 s, maksymalnie 5 prób) i zapis nieudanych operacji do kolejki. Bez idempotencji – klucza operacji albo sprawdzenia, czy zamówienie o tym numerze już istnieje – jedno ponowienie po timeoucie daje dwa zamówienia i dwie faktury. To najdroższy błąd w tej kategorii, bo sprząta się go ręcznie w księgowości.

Kurierzy: InPost, DPD i DHL generują etykiety przez API, ale różnią się zakresem wymaganych pól (gabaryt, punkt odbioru, pobranie), formatem pliku (PDF vs ZPL) i sposobem przekazywania statusów – część wysyła webhooki, część trzeba odpytywać co kilka minut. Zwroty i protokoły rozliczeniowe to osobna integracja, często pomijana w wycenie.

Na koniec log zdarzeń z identyfikatorem korelacji i alert, gdy na przykład 3 błędy wystąpią w ciągu 15 minut. Chcesz wiedzieć o awarii z maila, a nie z telefonu klienta. Cały proces opisuję w tekście o niestandardowych modułach i wtyczkach dla firm z Zamościa. Struktury hooków i modeli danych w PrestaShop masz w dokumentacji dla deweloperów PrestaShop.

Testy i odbiór: lista kontrolna przed wypuszczeniem na produkcję

Odbiór modułu nie wymaga czytania kodu. Wystarczy lista kontrolna i kopia danych produkcyjnych na środowisku stagingowym. Kopia ma odpowiadać produkcji co do struktury, ale być zanonimizowana – maile, telefony i adresy klientów podmienione. Bez tego testujesz na fikcji.

Testy funkcjonalne. Przejdź 10–15 scenariuszy: zamówienie z jednym produktem, z 20 produktami, z kodem rabatowym, z produktem poza stanem, z odrzuconą płatnością, zwrot, ponowne zamówienie tego samego klienta. Wynik zapisuj w arkuszu: scenariusz, oczekiwany efekt, wynik, kto sprawdził, data.

Wydajność. Zmierz czas odpowiedzi kategorii i koszyka przed włączeniem modułu i po. Praktyczny budżet: kategoria maksymalnie +200 ms, koszyk +300 ms. Jeśli moduł dokłada 1,5 s do koszyka, klient to poczuje na telefonie. Progi i sposób pomiaru metryk opisuje web.dev – Web Vitals.

Bezpieczeństwo. Sprawdź cztery rzeczy: nowe kontrolery w panelu widoczne tylko dla właściwych ról, walidacja formularzy po stronie serwera (nie wyłącznie w JavaScript), klucze API w konfiguracji modułu lub zmiennych środowiskowych, brak kluczy w widoku źródła strony i w publicznie dostępnych plikach JS.

Aktualizacja i wycofanie. Na klonie zaktualizuj PrestaShop o jedną wersję w górę i sprawdź moduł. Potem wyłącz moduł i odpowiedz: czy sklep działa, czy dane zamówień zostają w bazie, czy po ponownym włączeniu nic się nie dubluje. To test, który pokaże, czy nie zostaniesz zakładnikiem jednego wykonawcy. Szerszą listę kontrolną stosujemy przy wdrożeniach modułów dla firm z Hrubieszowa.

Utrzymanie po wdrożeniu: aktualizacje, PHP i jasne SLA

Własny moduł lub wtyczka to nie jednorazowy zakup, a zobowiązanie na 3–4 lata. W tym czasie zmieni się niemal wszystko wokół kodu: wersje PrestaShop (1.7 → 8.x), WordPress i WooCommerce (duże wydania raz w roku, mniejsze co kilka tygodni), wersje PHP (7.4 → 8.1 → 8.3) oraz API kurierów i operatorów płatności. Przykład z życia: funkcja napisana pod PHP 7.4, korzystająca z dynamicznych właściwości klas, na PHP 8.2 zaczyna sypać ostrzeżeniami, a integracja z operatorem płatności przestaje działać po zmianie wymagań 3DS2 i sposobu autoryzacji tokenów. Nikt nie zadzwoni z wyprzedzeniem — po prostu przestanie działać płatność albo etykieta kurierska. Zasady zgodności wstecznej i wymagania wersji opisuje dokumentacja PrestaShop dla deweloperów, i to jest pierwszy dokument, który powinien znać wykonawca.

Dlatego w umowie utrzymaniowej SLA zapisuje się liczbami, nie hasłem „wsparcie techniczne”. Rozsądny układ wygląda tak:

Poziom	Przykład	Czas reakcji	Czas naprawy
Krytyczny	nie działa płatność, sklep nie przyjmuje zamówień	do 2 godz.	do 8 godz.
Ważny	błąd eksportu zamówień do ERP, zła kalkulacja dostawy	do 8 godz.	do 3 dni roboczych
Zwykły	kosmetyka w panelu, literówka, drobna poprawka	do 2 dni roboczych	wg kolejki

Do tego cztery elementy, o które warto zapytać przed podpisaniem: kanał zgłoszeń (jeden — e-mail lub panel ticketowy, nie Messenger plus SMS plus telefon), zakres godzin wsparcia (np. 8:00–16:00 w dni robocze, poza tym tylko zgłoszenia krytyczne), kopie zapasowe (codzienne, retencja min. 30 dni, raz na kwartał test odtworzenia na stagingu) oraz podział na prace rutynowe i rozwojowe. Rutynowe — aktualizacje, monitoring, backupy, poprawki do ustalonej liczby godzin — idą w abonamencie. Rozwojowe, czyli nowe funkcje, wycenia się osobno. Bez tego rozdzielenia każda aktualizacja rozjeżdża budżet.

Ostatni warunek: dokumentacja i przekazanie kodu. Repozytorium Git z dostępem po stronie klienta, README z opisem hooków, konfiguracji i zależności, procedura wdrożenia i rollback. Jeśli zmieni się wykonawca, brak tych plików oznacza 2–3 dni płatnego rozgryzania cudzego kodu. Więcej o tym, jak ułożyć całość projektu, piszemy w tekście o organizacji pracy przy niestandardowych modułach i wtyczkach w Zamościu.

Pięć sygnałów, że nie potrzebujesz własnego modułu

Własny kod bywa najdroższym sposobem rozwiązania problemu, który da się zamknąć konfiguracją. Pięć sygnałów, że lepiej odpuścić:

• Proces da się zmienić, nie kod. Handlowiec prosi o „moduł do wycen B2B”. Zanim go zamówisz, sprawdź, czy nie wystarczy formularz z załącznikiem i PDF przygotowywany raz dziennie. Zmiana przyzwyczajenia kosztuje zero, moduł — kilka tysięcy.
• Gotowa wtyczka pokrywa 80–90% potrzeb. Brakującą resztę często obsłuży jeden hook w motywie dziecka albo ustawienie w panelu. Przed zakupem sprawdź datę ostatniej aktualizacji wtyczki i czy wsparcie odpowiada na pytania.
• Nie ma kto odebrać zgłoszenia. Kto w firmie przetestuje poprawkę, opisze błąd i sprawdzi po aktualizacji, czy koszyk nadal działa? Jeśli nikt, kod zostanie bez opieki przy pierwszej zmianie wersji PHP.
• Funkcja jest potrzebna na jeden sezon. Kalkulator świąteczny czy jednorazowa akcja lepiej oprzeć na zewnętrznym narzędziu niż modułem, który zostanie w sklepie na lata.
• Nikt nie policzył utrzymania. Jeśli budżet kończy się na wdrożeniu i nie ma kilkuset złotych miesięcznie na aktualizacje, to nie jest projekt na własny kod.

Porównanie pierwszego roku — poniżej wyłącznie rzędy wielkości, nie oferta. Każdą kwotę trzeba potwierdzić wyceną, bo zakres bywa bardzo różny.

Wariant	Koszt 1. roku (orientacyjnie)	Kiedy ma sens
Konfiguracja lub zmiana procesu	od 0 do ok. 1500 zł	gdy da się obejść bez kodu
Gotowa wtyczka plus konfiguracja	licencja roczna plus kilka godzin wdrożenia	gdy pokrywa 80–90% potrzeb
Własny moduł	wdrożenie liczone w tysiącach złotych plus miesięczne utrzymanie	gdy funkcja jest specyficzna, powtarzalna i krytyczna dla przychodu

Szczera rekomendacja jest w interesie obu stron: klient, który kupił moduł bez zaplecza technicznego, po roku wraca z pretensjami, a nie z kolejnym zleceniem. Jak wygląda organizacja takich wdrożeń poza Zamościem, opisujemy przy okazji pracy nad modułami i wtyczkami w Narolu i okolicach.

Praca z deweloperem z Zamościa i regionu: jak to wygląda w praktyce

Model, który działa, jest prosty: jedna osoba decyzyjna po stronie firmy i jedna osoba po stronie dewelopera. Nie dział handlowy, nie pośrednik, który przekazuje zlecenie dalej. Na starcie ustalacie trzy rzeczy na piśmie:

• Kto pisze kod. Pytanie wprost: czy projekt robi ta sama osoba, która prowadzi rozmowy, i czy będzie dostępna w sierpniu oraz w okresie świątecznym.
• Jeden kanał zgłoszeń. E-mail albo wspólny kanał roboczy. Nie SMS do właściciela firmy po godzinach, bo tam giną ustalenia.
• Liczba rund poprawek w cenie. Typowo dwie rundy uwag na etapie demo, kolejne płatne osobno. Dzięki temu projekt ma koniec, a nikt nie pracuje za darmo.

Komunikacja na odległość działa dobrze, gdy ma rytm: 30-minutowa rozmowa wideo na koniec etapu plus demo na stagingu. Dla firm z Chełma, Hrubieszowa czy Lublina wystarcza to w większości projektów — odległość nie ma znaczenia, dopóki demo jest dostępne online, a nie tylko na screenshocie. Więcej o tym, jak wygląda organizacja pracy przy niestandardowych modułach i wtyczkach w Lublinie, a także jak przebiega ona w Chełmie, opisujemy osobno.

Spotkanie na miejscu warto zaplanować w dwóch sytuacjach. Pierwsza: moduł musi rozmawiać z systemem, do którego nie ma wygodnego dostępu zdalnego — lokalny ERP, serwer plików, VPN, drukarka fiskalna, integracja z magazynem. Druga: odbiór końcowy przy większym wdrożeniu, gdzie trzeba przejść procedury na żywo. Zwykle wystarczą dwa spotkania: jedno na początku, jedno przy odbiorze.

Punkty kontrolne w projekcie:

• Demo po etapie analizy — makieta ekranów i panelu ustawień, zanim powstanie kod.
• Demo po implementacji — działający moduł na stagingu, dane testowe, przypadki brzegowe.
• Odbiór na stagingu — checklista akceptacyjna 10–20 przypadków, w tym błędne dane, brak kuriera, anulowanie zamówienia.
• Wdrożenie na produkcję — poza godzinami szczytu, z kopią bazy i plików, planem rollback i obserwacją przez 48 godzin.

Jeśli w projekcie pojawia się podwykonawca, ustal, kto odpowiada za błędy i komu zgłaszasz poprawki. W praktyce najlepiej działa brak przekazywania zlecenia dalej.

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

Lista kontrolna do odklikania

• Wersje oprogramowania w briefie — PrestaShop lub WooCommerce, wersja PHP, wersja bazy. Sprawdź w panelu hostingu i w stopce administracji, nie z pamięci.
• Lista aktywnych modułów i wtyczek — Zrób eksport listy z wersjami. Sprawdź, czy któraś dotyka tego samego procesu, np. rabatów albo wysyłki.
• Środowisko testowe — Kopia sklepu na subdomenie, dane klientów zanonimizowane. Ustal, kto ma dostęp.
• Właściciel procesu po stronie firmy — Jedna osoba, jedno nazwisko w briefie, prawo do zatwierdzania zakresu.
• Proces opisany krok po kroku — Kto zaczyna, co klika, co dzieje się dalej, kto kończy. Test: przeczytaj to na głos osobie, która tego nie robi.
• Przypadki brzegowe wypisane osobno — Brak stanu, błąd API, anulowanie, częściowa realizacja, zwrot. Jeśli czegoś nie ma na liście, nie jest zamówione.
• Kontrakt danych dla integracji — Pola, format, częstotliwość, kto jest właścicielem API po drugiej stronie. Ustal przed pierwszą linią kodu.
• Kryteria akceptacji po ludzku — Nie „moduł działa”, tylko „po opłaceniu zamówienia numer trafia do ERP w ciągu 5 minut”.
• Wycena rozbita na etapy — Analiza, implementacja, testy, wdrożenie, dokumentacja — z liczbą godzin przy każdym punkcie.
• Koszt utrzymania na piśmie — Ile kosztuje aktualizacja po zmianie wersji platformy i kto za nią odpowiada.
• Czas zespołu na testy — Zaplanuj konkretne godziny w kalendarzu, nie „przy okazji”. Przy małym module to zwykle 4-8 godzin.
• Dane testowe gotowe przed startem — Klient B2B z rabatem, produkt konfigurowalny, zamówienie zagraniczne. Bez tego testy staną.
• Plan wdrożenia i wycofania — Okno czasowe, kopia zapasowa, sposób cofnięcia zmian, jeśli coś pójdzie nie tak.
• Protokół odbioru — Kto podpisuje, na podstawie jakiej listy i co uruchamia płatność końcową.

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