Wdrożenie modułu do sklepu w Chełmie najczęściej rozsypuje się nie w kodzie, a w organizacji: brak zakresu, brak osoby decyzyjnej, brak kryteriów odbioru. Efekt to projekt, który miał zająć 40 godzin, a ciągnie się pół roku i kosztuje dwa razy tyle. W tym tekście zbieramy to, co w praktyce decyduje o powodzeniu: typowe błędy, checklistę do odhaczenia przed startem i odpowiedzi na pytania, które słyszymy na pierwszym spotkaniu. Jeśli szukasz raczej porównania technicznego niż organizacyjnego, zajrzyj do materiału o tym, jak zorganizować pracę nad modułami w Lublinie.
Zacznijmy od rozróżnienia, bo w rozmowach z klientami te trzy pojęcia mieszają się najczęściej.
Moduł PrestaShop to katalog w /modules/ z plikiem głównym, którego klasa dziedziczy po Module. Moduł podpina się do hooków (np. displayHeader, actionValidateOrder), może mieć kontroler frontowy i adminowy oraz własne szablony .tpl. Struktura katalogów i hooki są dokładnie opisane w dokumentacji dla deweloperów PrestaShop. Wtyczka WordPress to katalog w /wp-content/plugins/ z nagłówkiem opisującym wtyczkę i kodem podpiętym do akcji oraz filtrów — bez tego nagłówka WordPress jej nie zobaczy. Wtyczka WooCommerce to wtyczka WordPress rozszerzająca WooCommerce: korzysta z hooków woocommerce_*, dodaje metody płatności, dostawy albo pola zamówienia.
Integracja to warstwa łącząca sklep z systemem zewnętrznym — ERP, magazynem, księgowością, kurierem. Można ją napisać jako moduł lub wtyczkę, ale można też postawić osobny serwis, który rozmawia ze sklepem przez REST, a z ERP przez SOAP albo pliki wymieniane cyklicznie.
Przykłady z wdrożeń: moduł do wyceny B2B (ukryte ceny dla gości, rabat progowy, generowanie oferty PDF), wtyczka do fakturowania (dokument wystawiany po zmianie statusu na „Zrealizowane", własna numeracja, przekazanie do KSeF), integracja z magazynem (stany odświeżane co kilka minut, rezerwacja towaru przy dodaniu do koszyka).
Kiedy zostać przy gotowym rozwiązaniu? Gdy proces jest standardowy: koszyk, zwykła wysyłka, podstawowe faktury. Kiedy pisać własny kod? Gdy reguły są unikalne i dają przewagę (np. ceny zależne od historii zakupów klienta), gdy gotowa wtyczka wymaga trzech innych, żeby zadziałać, albo gdy dane muszą trafić do systemu, którego żadna wtyczka nie obsługuje. Różnicę między porównaniem technicznym a organizacyjnym rozkładamy w materiale o niestandardowych modułach i wtyczkach w Lublinie.
Zanim poprosisz o wycenę, przejdź przez siedem pytań. Dwa lub więcej „tak" oznacza zwykle, że własny kod ma sens. Jedno „tak" to jeszcze nie powód.
TCO liczymy na 24 miesiące, nie na pierwszy rok. Przykład: wtyczka z licencją 1200 zł/rok plus 12 h konfiguracji po 180 zł to ok. 4560 zł przez dwa lata. Własny moduł 80 h po 180 zł plus 400 zł miesięcznie utrzymania — ok. 24 000 zł. Różnica zwraca się dopiero wtedy, gdy wtyczka wymusza pracę ręczną wartą np. 4 h miesięcznie (przy 60 zł/h to 5760 zł przez dwa lata).
| Kryterium | Gotowa wtyczka (24 mies.) | Własny moduł (24 mies.) |
|---|---|---|
| Licencja / wykonanie | 600–3000 zł | 7000–18000 zł |
| Konfiguracja i wdrożenie | 6–16 h | w cenie wykonania |
| Dopasowanie do procesu | często obejścia ręczne | dokładnie pod proces |
| Aktualizacje i poprawki | w ramach licencji | 300–1500 zł/mies. |
| Koszt odejścia | niski — dane w standardzie | średni — potrzebny deweloper |
| Szacunek łączny | 3000–8000 zł | 14000–40000 zł |
Stawki w Polsce w 2025 roku mieszczą się w przedziale 120–250 zł netto za godzinę. Dolna granica to prace standardowe i mniej skomplikowany kod, górna — integracje ERP, płatności, PIM, czyli wszystko, gdzie trzeba znać protokół systemu zewnętrznego. Do tego dochodzi koszt analizy i testów, który nie znika, nawet jeśli kod pisze jedna osoba.
Typowe zakresy: prosty moduł (dodatkowe pole w formularzu, zmiana logiki koszyka, blok na stronie) to 20–40 h. Integracja z ERP albo magazynem: 60–160 h, bo dochodzi mapowanie pól, obsługa błędów i uzgodnienie stanów. Skomplikowany moduł B2B (ceny indywidualne, limity, wyceny, wielopoziomowe rabaty): 100–200 h.
| Zakres | Pracochłonność | Widełki netto |
|---|---|---|
| Prosty moduł (pole, logika koszyka, blok) | 20–40 h | 2400–8000 zł |
| Własna bramka płatności | 16–30 h | 2000–5000 zł |
| Integracja z kurierem (np. InPost, DPD) | 25–50 h | 4000–9000 zł |
| Integracja z ERP lub magazynem | 60–160 h | 10000–25000 zł |
| Moduł B2B z wycenami i limitami | 100–200 h | 12000–45000 zł |
| Utrzymanie i opieka techniczna | miesięcznie | 300–1500 zł |
PrestaShop i WooCommerce rozwiązują ten sam problem dwoma różnymi mechanizmami. W PrestaShop moduł to katalog /modules/nazwa_modulu z plikiem głównym nazwa_modulu.php, klasą dziedziczącą po Module, plikiem config.xml i katalogiem views/ na szablony .tpl. Logikę podłącza się przez hooki — displayHeader, actionOrderStatusPostUpdate, displayAdminOrderMain — rejestrowane w metodzie install(). Jeśli hooka nie ma, dopisujesz własny przez registerHook i rozszerzasz szablon nadpisaniem w themes/twoj_theme/modules/nazwa_modulu/. Override (katalog override/controllers/) działa, ale jest najbardziej ryzykowny: aktualizacja PrestaShop potrafi nadpisać te pliki, a konflikt z innym modem wychodzi dopiero na produkcji. Zasada: override tylko wtedy, gdy hooka naprawdę brakuje, i zawsze z wpisem do dokumentacji projektu.
Zgodność z 1.7 i 8 wymaga testów na obu gałęziach — inne są klasy formularzy, inne sygnatury części hooków, inny renderowanie w back office. Nie zakładaj kompatybilności, sprawdź ją. Szczegóły interfejsów są w dokumentacji deweloperskiej PrestaShop.
W WooCommerce kod trzymasz w child theme (samo functions.php to za mało — potrzebny katalog inc/ z klasami), a logikę niezależną od wyglądu w /wp-content/mu-plugins/, który ładuje się zawsze i nie da się go wyłączyć z panelu. Podłączasz się przez add_action i add_filter, dane wystawiasz przez REST API (register_rest_route). Standardy kodowania WordPressa i escapowanie danych to warunek, żeby wtyczka bezpieczeństwa nie zgłosiła twojego kodu jako podatności.
Różnica w aktualizacjach jest zasadnicza: WooCommerce rzadko łamie wtyczki przy minorach, PrestaShop potrafi zmienić strukturę hooków między 1.7.x a 8.x. W obu wypadkach kod trzymaj w repozytorium git, nigdy w edytorze w panelu. Praktyczne rozpisanie tego procesu znajdziesz w materiale o tym, jak wygląda praca nad niestandardowymi modułami i wtyczkami w Biłgoraju.
| Element | PrestaShop | WooCommerce / WordPress |
|---|---|---|
| Miejsce na kod | katalog /modules/nazwa_modulu | child theme + /wp-content/mu-plugins/ |
| Punkt podłączenia | hooki (registerHook), override | add_action / add_filter, REST API |
| Szablony | pliki .tpl w views/, nadpisanie w motywie | child theme, nadpisanie szablonu w motywie |
| Aktualizacje | zmiany hooków i klas między 1.7 a 8.x | duże wersje WP bywają bolesne |
| Największe ryzyko | override nadpisany przy aktualizacji | kod wklejony w edytorze, poza gitem |
Typowy zestaw to: sklep → ERP (Subiekt, Comarch Optima, ERPNext, WMS), etykiety u kuriera (InPost ShipX, DPD WebAPI, DHL24), płatności (Przelewy24, PayU, tpay, Stripe) i zwroty. Każde z tych połączeń ma własne limity, własny styl błędów i własne opóźnienia.
Mapowanie statusów. Sklep ma zwykle 6–8 statusów, ERP własne stany dokumentów. Nie mapuj 1:1 „bo tak wygląda lista”. Ustal jednoznacznie: który status tworzy zamówienie w ERP, który wystawia fakturę, który oznacza wysyłkę, a który anulowanie. Anulowanie po wystawieniu faktury wymaga korekty — to osobna operacja, nie ten sam webhook.
Kurierzy. InPost wymaga kodu punktu (paczkomatu). Jeśli klient wybierze paczkomat w checkoucie, a integracja nie zapisze tego kodu, etykieta się nie wygeneruje. DPD i DHL zwracają etykiety w PDF lub ZPL i odrzucają błędne kody pocztowe oraz brak numeru domu — adres warto walidować już w formularzu, a nie dopiero przy generowaniu etykiety. Webhooki kurierów przychodzą z opóźnieniem i potrafią się powtórzyć, więc endpoint musi być idempotentny (ten sam event przetworzony dwa razy nie może wysłać dwóch maili).
Płatności. Autoryzacja i pobranie środków to dwie różne operacje. Zwrot częściowy (zwracasz jeden produkt z trzech) wymaga odwołania do konkretnej transakcji i kwoty. Płatność częściowa — zaliczka plus dopłata — komplikuje rozliczenie w ERP, bo faktura nie równa się jednej transakcji. Klucze API trzymaj w zmiennych środowiskowych, nigdy w repozytorium; dane karty nie mogą przechodzić przez twój serwer.
Kolejkowanie. Nie wysyłaj requestów synchronicznie przy składaniu zamówienia. Kolejka (Redis, RabbitMQ albo tabela zadań) plus retry z opóźnieniem i log błędów z pełnym payloadem. Inaczej awaria API kuriera blokuje checkout. Szersze omówienie tematu znajdziesz przy okazji niestandardowych modułów i wtyczek w Bełżcu.
| Integracja | Co najczęściej się psuje | Zabezpieczenie po stronie sklepu |
|---|---|---|
| ERP | niejednoznaczne mapowanie statusów, korekty po fakturze | tabela mapowania status → dokument, osobny webhook na korektę |
| InPost | brak kodu paczkomatu przy etykiecie | walidacja wyboru punktu przed zapisem zamówienia |
| DPD / DHL | błędny adres, brak numeru domu | walidacja adresu w formularzu, nie przy generowaniu etykiety |
| Płatności | zwroty częściowe i zaliczki | log transakcji z ID i kwotą, osobna obsługa capture |
| Webhooki | powtórzone i spóźnione zdarzenia | endpoint idempotentny, kolejka + retry z backoffem |
Sześć etapów, z których każdy kończy się dokumentem albo działającą rzeczą. Jeśli wykonawca któregoś nie potrafi nazwać, to sygnał ostrzegawczy.
1. Brief. Jedna strona: co moduł ma robić, kto go użyje, jakie dane wchodzą i wychodzą, czego moduł robić nie ma. Bez tej listy zakres rośnie w trakcie.
2. Analiza. Sprawdzenie, czy funkcja nie jest już dostępna w istniejących wtyczkach lub w API systemu. Efekt: lista hooków, endpointów, tabel i integracji plus szacunek godzin.
3. Prototyp. Ekrany w back office i ścieżka klienta jako klikalny szkic albo działający szkielet bez pełnej logiki. Tu najtaniej wychodzą nieporozumienia — poprawka prototypu kosztuje minuty, poprawka gotowego kodu dni.
4. Development. Praca na branchu, commit za zadanie, środowisko testowe z kopią bazy produkcyjnej. Dane produkcyjne testuj wyłącznie na kopii — nie podłączaj się do żywej bazy, żeby „sprawdzić jeden insert”.
5. Testy. Code review przez drugą osobę, testy regresji krytycznych ścieżek (dodanie do koszyka, zamówienie, płatność, mail), kryteria odbioru spisane przed startem: konkretna akcja, konkretny oczekiwany wynik, konkretny ekran.
6. Wdrożenie i przekazanie. Wdrożenie poza godzinami szczytu, kopia zapasowa przed, procedura wycofania opisana. Przekazujesz kod źródłowy, repozytorium, dokumentację ustawień i SLA: kanał zgłaszania błędów, czas reakcji, co jest gwarancją, a co nowym zleceniem.
Kolejność i dyscyplina w tych etapach to zwykle większa oszczędność niż wybór technologii. Więcej o tym, jak ułożyć taką pracę, pisaliśmy przy okazji niestandardowych modułów i wtyczek w Narolu.
| Etap | Co powstaje | Warunek przejścia dalej |
|---|---|---|
| Brief | jednostronicowy opis zakresu i granic | klient akceptuje zakres i listę wykluczeń |
| Analiza | lista hooków, endpointów, tabel, szacunek godzin | potwierdzone, że nie ma gotowej wtyczki |
| Prototyp | szkic ekranów i ścieżki klienta | akceptacja układu przed pisaniem logiki |
| Development | kod na branchu, środowisko testowe | commit za zadanie, brak pracy na produkcji |
| Testy | code review, testy regresji | spisane kryteria odbioru spełnione w całości |
| Wdrożenie i przekazanie | kod źródłowy, dokumentacja, SLA | podpisany odbiór i ustalony kanał zgłoszeń |
Własny moduł daje przede wszystkim kontrolę nad tym, co trafia do <head> i ile skryptów ładuje się na stronie. Sklep po trzech latach na gotowych wtyczkach to często 12–18 plików JS: slider, newsletter, popup, galeria — każde z własną kopią jQuery. Moduł pisany pod konkretny sklep robi jedną rzecz i waży 15–40 kB, a jego ładowanie można warunkować: tylko na karcie produktu, tylko dla zalogowanych, tylko po scrollu.
Google rozlicza to na realnych danych użytkowników, nie z laboratorium. Progi są znane: LCP maksymalnie 2,5 s, INP 200 ms, CLS 0,1 — pełne definicje i progi opisuje web.dev. W sklepie psują się one w przewidywalny sposób. LCP to zwykle baner główny albo zdjęcie produktu doczytywane przez JavaScript — przeniesienie go do HTML z fetchpriority="high" i preloadem potrafi urwać 1–2 s. INP rośnie, gdy przeliczanie koszyka idzie osobnym żądaniem przez trzy wtyczki, a każda trzyma główny wątek. CLS wyskakuje, gdy pasek promocyjny wstrzykuje się 300 ms po wejściu; własny moduł rezerwuje na niego wysokość już w pierwszym renderze.
Drugi obszar to baza. Kontrola nad zapytaniami SQL oznacza jedno złączenie zamiast pętli foreach z zapytaniem w środku — przy 5 000 produktów różnica liczy się w sekundach, nie milisekundach. Cache warto ustawić świadomie: tagowany po ID produktu i kategorii, unieważniany tylko przy edycji danego wpisu, plus Redis na sesje i koszyk. Domowy obejście to czyszczenie całego cache po każdym zapisie — wtedy sklep „przebudowuje się” kilka razy dziennie bez powodu.
Trzecia rzecz: dane strukturalne i adresy URL. JSON-LD dla Product z Offer, BreadcrumbList i Organization generowany w module jest spójny z tym, co faktycznie widać na stronie — wtyczki SEO lubią dopisywać pola puste albo sprzeczne. Adresy trzymaj w formie /kategoria/podkategoria/nazwa-produktu zamiast ?controller=product&id_product=123. Jak poukładać to w mniejszym projekcie, pokazujemy na przykładzie wdrożeń w rodzaju niestandardowych modułów i wtyczek Frampol.
Najczęstsza obawa brzmi: „a co, jeśli po aktualizacji PrestaShop moduł przestanie działać?”. Przy własnym kodzie ryzyko sprowadza się do kilku powtarzalnych procedur, a nie do szczęścia.
Backup: pełna kopia plików i bazy przed każdą aktualizacją plus kopia automatyczna codziennie z retencją 30 dni. Kopia musi leżeć poza serwerem produkcyjnym — zrzut obok źródła chroni przed literówką, nie przed awarią dysku. Osobno zrzut bazy przed każdą migracją, bo rollback plików bez bazy nic nie daje.
Monitoring: logowanie wyjątków do pliku z rotacją, alert przy błędzie 500 i przy skoku liczby błędów o 3× względem średniej z tygodnia. Wystarczy Sentry albo podobne narzędzie podpięte do modułu — bez tego o awarii dowiesz się od klienta, nie z alertu.
Aktualizacje: PHP 8.1, 8.2, 8.3 to nie opcja, bo hostingi wycofują starsze wersje. Każda zmiana wersji PHP, PrestaShop, WordPressa czy WooCommerce przechodzi najpierw na kopii sklepu (staging), z prawdziwą bazą i prawdziwym motywem. Dopiero po testach idzie na produkcję. Wycofanie zmian: tag w Git przed wdrożeniem i gotowy skrypt przywracający pliki modułu, żeby rollback zajmował minuty, a nie godziny.
SLA to część umowy, nie dobra wola. Ustal trzy liczby: czas reakcji, czas naprawy i limit godzin w miesiącu. Przykładowe poziomy w tabeli poniżej. Zakres opieki musi też mówić, co jest poza nią — nowa funkcja to zwykle osobna wycena, a nie „drobna poprawka”. Jak wygląda to w praktyce mniejszych wdrożeń, opisujemy przy okazji niestandardowych modułów i wtyczek Józefów: organizacja pracy.
| Poziom | Przykład zdarzenia | Czas reakcji | Czas naprawy |
|---|---|---|---|
| Krytyczny | Sklep nie przyjmuje zamówień, błąd 500 na koszyku | 2–4 h w godzinach roboczych | do 24 h |
| Wysoki | Moduł płatności zwraca błędy przy części transakcji | 4–8 h | do 48 h |
| Normalny | Błąd w panelu administracyjnym, kosmetyka w widoku | 1 dzień roboczy | do 5 dni roboczych |
| Zmiana | Nowa funkcja lub modyfikacja istniejącej | wycena w 2 dni robocze | wg harmonogramu |
Na pierwszym spotkaniu łatwo ocenić prezentację, trudniej — sposób pracy. Te osiem pytań zadaj przed podpisaniem umowy i zapisz odpowiedzi. Jeśli któryś temat jest kręcony, to sygnał.
Najdroższy scenariusz to pośrednik bez własnego zespołu: bierze 30–40% marży, a Ty rozmawiasz z nim w sprawie decyzji, które i tak podejmuje ktoś inny. Ukryte koszty siedzą wtedy w licencjach, hostingu i płatnym wsparciu po okresie gwarancji. Więcej o tym, jak to wygląda przy dłuższej współpracy, piszemy w materiale o niestandardowych modułach i wtyczkach Lublin: organizacja pracy.
| Pytanie | Dobra odpowiedź | Czerwona flaga |
|---|---|---|
| Kto jest właścicielem kodu? | Repozytorium przekazane klientowi, kod bez szyfrowania | Kod tylko na serwerze wykonawcy, brak dostępu do repo |
| Kto pisze kod? | Imiona i nazwiska deweloperów, kontakt bezpośredni | „Zespół” bez nazwisk, zlecenie do podwykonawcy |
| Jak wygląda wycena? | Stawka godzinowa, zakres i kryteria odbioru na piśmie | Ryczałt bez zakresu i bez kryteriów odbioru |
| Co po zakończeniu? | Dokumentacja, szkolenie, umowa wsparcia z SLA | Brak dokumentacji, wsparcie „na telefon |
Brief istnieje tylko w mailach i ustaleniach na telefonie. Zakres rośnie w trakcie, bo każdy rozumie go inaczej.
Jak wykryć: Zapytaj wykonawcę, ile funkcji ma w wycenie, i porównaj z tym, co sam masz w głowie. Jeśli liczby się nie zgadzają — nie ma zakresu.
Jak naprawić: Jeden dokument: cel biznesowy, lista funkcji, lista wyjątków ("a co, jeśli klient nie ma NIP?"), kto decyduje, termin. Podpisany przez obie strony przed pierwszym commitem.
Brak jednej osoby decyzyjnej po stronie firmy. Na maile odpowiada handel, księgowość i właściciel, każdy trochę inaczej.
Jak wykryć: Policz, ile osób musi zaakceptować prototyp. Jeśli więcej niż dwie i nikt nie ma ostatniego słowa — projekt utknie w uzgodnieniach.
Jak naprawić: Wyznacz jedną osobę, która zbiera uwagi od reszty i przekazuje je wykonawcy. Wykonawca rozmawia z jedną osobą, nie z pięcioma.
Praca bezpośrednio na produkcji. Testy robi się na żywym sklepie, na prawdziwych zamówieniach.
Jak wykryć: Sprawdź, czy istnieje adres z dopiskiem test lub staging i czy jest na nim kopia bazy. Jeśli nie ma — testy idą na produkcji.
Jak naprawić: Osobne środowisko testowe z kopią bazy (dane klientów zanonimizowane) i osobnym kluczem API płatności w trybie sandbox.
Odbiór na zasadzie "wygląda dobrze". Nikt nie sprawdza przypadków brzegowych.
Jak wykryć: Zapytaj, kto i na jakiej podstawie powie "koniec". Jeśli odpowiedź brzmi "zobaczymy, jak zadziała" — nie ma kryteriów odbioru.
Jak naprawić: Lista przypadków testowych ustalona przed developmentem: poprawne dane, błędne dane, brak danych, duży wolumen, ponowne kliknięcie, brak odpowiedzi API.
Brak przekazania kodu źródłowego i dokumentacji. Po rozstaniu z wykonawcą nikt nie potrafi ruszyć modułu.
Jak wykryć: Zapytaj przed startem: na czyim koncie jest repozytorium i kto ma do niego dostęp. Odpowiedź "u nas, ale panu damy, jak będzie trzeba" to czerwona flaga.
Jak naprawić: Repozytorium Git po stronie klienta, dostęp dla co najmniej dwóch osób w firmie, README z opisem instalacji, hooków i zależności. Przekazanie kodu to punkt odbioru, nie uprzejmość.
Brak planu na aktualizacje PrestaShop lub WordPressa. Moduł działa, aż któregoś dnia po aktualizacji pojawia się biały ekran.
Jak wykryć: Zapytaj wykonawcę, co się stanie, gdy sklep przejdzie z PrestaShop 1.7 na 8.x. Jeśli nie ma odpowiedzi — nie ma planu.
Jak naprawić: Zapisz w umowie wsparcie przy aktualizacji i trzymaj kopię działającej wersji. Każdą aktualizację testuj najpierw na staging, dopiero potem na produkcji.
Większość problemów z niestandardowymi modułami i wtyczkami w Chełmie nie wynika z kodu, a z braku zakresu, osoby decyzyjnej i kryteriów odbioru. Brief, środowisko testowe i lista przypadków testowych kosztują kilka godzin, a oszczędzają tygodnie poprawek. Kod źródłowy i dokumentacja to punkt odbioru, nie przysługa — bez nich jesteś uzależniony od jednego wykonawcy. Zacznij od checklisty powyżej, zanim podpiszesz jakąkolwiek umowę.
Prosty moduł to 20–40 godzin pracy, czyli przy pracy dorywczej 2–4 tygodnie kalendarzowo. Integracja z ERP zajmuje 60–160 godzin, a rozbudowany moduł B2B 100–200 godzin. Największym zmartwieniem nie jest samo kodowanie, a czas na testy i uzgodnienia — one potrafią zająć tyle samo, co development.
Cel biznesowy, lista funkcji, lista wyjątków, informacja o systemach już działających w firmie, przykładowe dane i termin. Bez tego wykonawca wycenia własne domysły, a różnica między domysłem a rzeczywistością wychodzi dopiero w trakcie prac, przy zmianie zakresu.
Powinieneś — i to warto zapisać w umowie jako punkt odbioru, nie jako uprzejmość wykonawcy. Repozytorium Git powinno być po Twojej stronie, z dostępem dla co najmniej dwóch osób. Dokumentacja PrestaShop dla deweloperów (devdocs.prestashop-project.org) opisuje, jak zbudowany jest moduł, więc możesz sprawdzić, czy przekazana struktura ma sens.
Typowo 300–1500 zł netto miesięcznie. Górna granica dotyczy modułów z kilkoma integracjami, na przykład ERP plus dwóch kurierów plus płatności. W tej kwocie mieszczą się aktualizacje pod nowe wersje sklepu, monitoring błędów API i drobne poprawki.
Gotowa wtyczka wystarczy, gdy proces jest standardowy, a autor regularnie ją aktualizuje. Własny kod ma sens, gdy proces jest unikalny, integracji jest kilka naraz albo gdy zależy Ci na kontroli nad szybkością działania sklepu. Porównanie obu podejść w kontekście lokalnym znajdziesz w materiale o organizacji pracy nad modułami w Narolu.
Ustal kamienie milowe i demo co 1–2 tygodnie na środowisku testowym. Powinieneś widzieć działającą funkcję i móc ją samodzielnie kliknąć, a nie czytać opis postępu. Jeśli po miesiącu nie ma nic do przetestowania, problem jest w organizacji, nie w technologii.
Ustal to przed startem, nie po wdrożeniu. Moduł pisany pod PrestaShop 1.7 i 8 zwykle wymaga sprawdzenia po zmianie wersji, a wtyczka WooCommerce — po aktualizacji WordPressa i PHP. Każdą aktualizację testuj najpierw na kopii, nigdy od razu na produkcji. Osobny materiał o porządkowaniu pracy nad modułami w Bełżcu rozwija ten wątek.
Jeśli chcesz przejść przez to bez zgadywania, napisz do nas — powiemy wprost, czy w Twoim przypadku wystarczy gotowe rozwiązanie, czy potrzebny jest własny moduł.