Niestandardowe moduły i wtyczki dla firmy w Toruniu wycenia się dokładnie tak samo jak w każdym innym mieście: stawką godzinową i zakresem prac, a nie cennikiem z sufitu. Zanim padnie jakakolwiek liczba, trzeba ustalić, co moduł ma robić, z czym się łączyć i po czym poznamy, że działa. Ten tekst zbiera stronę organizacyjną projektu: kiedy wtyczka gotowa przestaje wystarczać, ile realnie kosztuje moduł na zamówienie, jak wygląda proces wdrożenia krok po kroku i jak napisać brief, który nie wygeneruje trzech skrajnie różnych ofert.
Zanim padnie pytanie o cenę, warto ustalić nazwy. W PrestaShop „moduł” to katalog w /modules — na przykład /modules/dd_erp_export — a w nim plik główny o tej samej nazwie: dd_erp_export.php. W środku znajduje się klasa dziedzicząca po Module. Sam plik nic nie robi, dopóki moduł nie zarejestruje się na hookach: registerHook('displayHeader'), actionCartSave, displayAdminOrder. Dopiero rejestracja na hooku podłącza kod do konkretnego momentu życia sklepu — tak opisuje to dokumentacja deweloperska PrestaShop.
W WordPressie i WooCommerce odpowiednikiem jest wtyczka: katalog /wp-content/plugins/dd-erp-export i plik dd-erp-export.php z komentarzem nagłówkowym (Plugin Name, Version, Requires PHP), po którym WordPress rozpoznaje ją na liście. Logikę podłącza się przez akcje i filtry: add_action('woocommerce_order_status_completed', ...) oraz add_filter('woocommerce_order_number', ...). Osobny przypadek to /wp-content/mu-plugins — wtyczki „must-use”: ładują się zawsze, nie da się ich wyłączyć z panelu i nie mają przycisku aktualizacji.
Wspólny mianownik jest jeden: i moduł, i wtyczka to kod, który dopisuje funkcję, jakiej platforma nie ma w standardzie. Różnice wynikają z tego, jak ten kod jest podpinany i co się z nim dzieje przy aktualizacji platformy. Jeśli pracujesz na PrestaShop, zobacz, jak podchodzimy do wdrożeń i modułów PrestaShop w praktyce.
| Aspekt | Moduł PrestaShop | Wtyczka WordPress/WooCommerce |
|---|---|---|
| Katalog na kod | /modules/nazwa-modulu | /wp-content/plugins/nazwa-wtyczki |
| Plik startowy | nazwa-modulu.php, klasa extends Module | nazwa-wtyczki.php z komentarzem nagłówkowym |
| Sposób rozszerzania | hooki + registerHook() | akcje add_action() i filtry add_filter() |
| Kod aktywny bez włączania | brak standardowego odpowiednika | /wp-content/mu-plugins (must-use) |
| Ryzyko przy aktualizacji | zmiany w hookach i API modułów | konflikty z innymi wtyczkami, duplikacja funkcji |
Nie każde odstępstwo od ideału oznacza, że trzeba pisać kod. Ale jeśli rozpoznajesz u siebie trzy z poniższych sygnałów, gotowe rozwiązanie zaczyna generować koszt większy niż jego licencja.
woocommerce_order_status_completed. Objaw: część zamówień nie generuje dokumentu, a kolejność włączania wtyczek zmienia wynik.Konkretny przykład: wtyczka obsługuje InPost, ale etykiety wystawia pojedynczo. O 15:00 pracownik ma do zaklejenia 40 przesyłek, a panel kuriera przyjmuje plik zbiorczy. 40 kliknięć dziennie to około 25 minut, czyli blisko 9 godzin miesięcznie. To argument, którego nie widać w cenniku wtyczki.
Kiedy NIE zamawiać modułu: gdy wtyczka za 300 zł rocznie robi 95% tego, czego potrzebujesz, a brakujące 5% to jedna ręczna operacja raz na kwartał. Pytanie kontrolne brzmi: czy brak tej funkcji kosztuje Cię czas pracownika co tydzień, czy raz na kwartał? Sposób organizacji takiego projektu opisujemy w materiale o niestandardowych modułach i wtyczkach Toruń – organizacja pracy.
Wycena wynika z liczby godzin, nie z widzimisię wykonawcy. Praktyczne widełki dla typowych zadań: prosty moduł (jedna funkcja, jeden hook, brak zewnętrznego API) to 8–16 godzin; moduł średni (kilka hooków, panel w back office, eksport danych) to 40–80 godzin; moduł złożony z integracją zewnętrzną i obsługą błędów to 120–250 godzin. Do tego dolicza się analizę, testy i dokumentację — jeśli ktoś ich nie uwzględnia, wpisze je w stawkę albo pominie.
Przykładowa wycena — moduł eksportu zamówień do ERP, 60 godzin: analiza pól i mapowanie statusów (8 h), autoryzacja i testy połączenia z API ERP (10 h), cykliczny eksport z crona z ponowieniami przy błędzie (16 h), panel z podglądem ostatnich wysyłek i logiem błędów (14 h), testy na kopii bazy i wdrożenie na produkcji (8 h), instrukcja dla pracownika i przekazanie (4 h). W cenę wchodzi kod, konfiguracja, testy, dokumentacja oraz wsparcie po wdrożeniu — zwykle 30 dni na zgłoszenia powdrożeniowe. Poza zakresem zostaje np. migracja trzech lat historii zamówień.
TCO: wtyczka subskrypcyjna za 490 zł rocznie to 980 zł po dwóch latach. Własny moduł przy 12 godzinach i stawce 150 zł/h kosztuje około 1800 zł jednorazowo, więc próg przecięcia wypada w okolicy 2–3 lat — wcześniej, jeśli doliczysz czas pracownika na ręczne obejścia. Nie podawaj jednej liczby bez stawki i zakresu, bo to zawsze wróżenie z fusów.
Co podnosi cenę: każde zewnętrzne API (autoryzacja, limity zapytań, obsługa błędów, ponowienia), niestandardowy panel w back office z uprawnieniami, migracja danych historycznych, obsługa wielu walut i języków. Wycena godzinowa z rozbiciem na etapy jest dla klienta bezpieczniejsza niż sztywna cena bez zakresu: wiesz, za co płacisz, i widzisz, co dokładnie zostaje poza projektem. Zobacz też, jak wyglądają aplikacje dedykowane budowane w tym trybie.
Dobrze poprowadzony projekt ma etapy, które kończą się czymś, co da się obejrzeć albo kliknąć. Typowy przebieg dla modułu do PrestaShop lub wtyczki WooCommerce wygląda tak:
Staging to nie fanaberia. Bez niego pierwszy test generuje prawdziwą etykietę kurierską, prawdziwy list przewozowy i maila do klienta. Różnica jednej wersji PHP między stagingiem a produkcją potrafi wyłożyć moduł w godzinach szczytu – a wtedy płacisz za gaszenie pożaru, nie za rozwój. Szczegóły techniczne po stronie sklepu opisujemy w sekcji poświęconej PrestaShop.
Kamienie milowe wiąż z płatnościami: zaliczka 30–50% na start, płatność po odbiorze etapu (np. po akceptacji makiety), reszta po odbiorze końcowym i 14-dniowym okresie obserwacji. Na koniec klient dostaje repozytorium z dostępem, dokumentację wdrożenia (gdzie są klucze API, jakie zadania cron, jakie uprawnienia) oraz instrukcję aktualizacji w kolejności: backup → staging → moduł → testy → produkcja. Cały cykl opisujemy szerzej na stronie organizacji pracy przy niestandardowych modułach i wtyczkach w Toruniu.
| Etap | Typowy czas | Co dostajesz | Powiązanie z płatnością |
|---|---|---|---|
| Analiza potrzeb | 1–3 dni | notatka z zakresem i pytaniami otwartymi | część zaliczki |
| Specyfikacja i makieta | 2–5 dni | dokument funkcji + makiety ekranów | odbiór etapu |
| Staging | 1 dzień | adres testowy, dane zanonimizowane | w ramach zaliczki |
| Kod i testy | zależnie od zakresu | działający moduł na stagingu | płatność za etapy |
| Wdrożenie produkcyjne | 0,5–1 dnia | moduł na produkcji, backup | przed odbiorem końcowym |
| Dokumentacja | 1–2 dni | repozytorium, instrukcja aktualizacji | odbiór końcowy |
Brief to nie zamówienie na moduł, tylko opis problemu. Im mniej w nim przymiotników, tym łatwiej porównać oferty. Sprawdzony szablon ma pięć pól: cel biznesowy (co ma się poprawić: czas obsługi, liczba pomyłek, koszt), użytkownik (kto realnie klika – magazynier, księgowa, właściciel na telefonie), dane wejściowe (skąd i w jakim formacie), integracje zewnętrzne (z jakim systemem i czy masz konto z odpowiednimi uprawnieniami) oraz kryteria akceptacji zapisane jako zdania mierzalne.
Różnica między zgłoszeniami to nie kwestia stylu, tylko pieniędzy. „Chcę moduł do wysyłki” może znaczyć integrację z dwoma kurierami, wybór paczkomatu i PDF z listem przewozowym – albo jedno pole z nazwą przewoźnika. „Potrzebuję generowania etykiet InPost z zamówień opłaconych, zbiorczo, max 50 paczek na jedno kliknięcie, po pobraniu etykiety status zmienia się na »Wysłane«” da się wycenić w jednym akapicie. Gdy moduł zaczyna obsługiwać magazyn, stany i rozliczenia, mówimy już o aplikacji dedykowanej – warto to nazwać już na etapie briefu, bo zmienia sposób pracy nad projektem.
Sześć pytań, które zada dobry deweloper przed wyceną:
Na końcu dopisz zakres negatywny. Zdanie „moduł nie wystawia faktur, nie zmienia sposobu płatności, nie obsługuje zwrotów i nie tłumaczy etykiet” kosztuje minutę, a ucina połowę sporów przy odbiorze.
| Pole briefu | Pytanie do odpowiedzi | Zły zapis | Dobry zapis |
|---|---|---|---|
| Cel biznesowy | co ma się poprawić? | „ma być szybciej” | „skrócenie wysyłki 50 paczek z 40 do 5 minut” |
| Użytkownik | kto klika? | „pracownicy” | „magazynier, 2 osoby, panel na tablecie” |
| Dane wejściowe | skąd i w jakim formacie? | „z zamówień” | „zamówienia opłacone, status »Opłacone«, adresy z pola delivery” |
| Integracje | z czym i czy mamy dostęp? | „z kurierem” | „InPost ShipX, konto firmowe, klucze produkcyjne i sandbox” |
| Kryteria akceptacji | po czym poznamy, że działa? | „ma działać poprawnie” | „50 etykiet na jedno kliknięcie, błąd API nie przerywa partii” |
Kryteria odbioru da się sprawdzić bez czytania kodu. Pierwsze i najważniejsze: czy moduł korzysta z hooków i mechanizmów rozszerzeń, czy nadpisuje pliki rdzenia. W PrestaShop każdy plik w katalogu /override/ to praca do powtórzenia przy każdej aktualizacji sklepu – po dwóch latach nie pamiętasz, po co był, a nowa wersja platformy go nadpisuje. Poprawnie napisany moduł używa hooków typu actionValidateOrder, actionOrderStatusPostUpdate, displayHeader i własnych kontrolerów. Zasady pisania modułów opisuje dokumentacja dla deweloperów PrestaShop.
Drugie: brak hardkodowanych ścieżek i danych dostępowych. Przeszukaj repozytorium po frazach „/var/www”, „api_key”, „http://”, adresach IP. Klucz API wpisany w kod to wyciek przy udostępnieniu repozytorium i brak możliwości przeniesienia modułu z jednego serwera na drugi. Klucze należą do konfiguracji modułu albo zmiennych środowiskowych, a ścieżki do stałych platformy.
Trzecie: standardy kodu. Zapytaj o plik phpcs.xml, zgodność z PSR-12 (PHP-FIG) i WordPress Coding Standards oraz o analizę uruchamianą w CI. To nie estetyka – spójny kod łatwiej przekazać innemu wykonawcy, gdy obecny zniknie.
Czwarte: obsługa błędów. Pytanie kontrolne brzmi: co się dzieje, gdy API kuriera nie odpowiada? Dobra odpowiedź: żądanie trafia do kolejki przetwarzanej przez cron, odstęp między próbami rośnie, status zamówienia się nie zmienia, a zdarzenie ląduje w logu (np. PrestaShopLogger::addLog()) i generuje alert mailowy. Zła: skrypt pada w połowie paczek, część zamówień zostaje przetworzona, klient widzi błąd 500. Piąte: testy regresji przed każdą aktualizacją platformy. Sprawdź, czy po aktualizacji na stagingu wykonawca przysyła raport z listy scenariuszy, czy tylko ciszę i zdanie „powinno działać”.
| Kryterium | Jak sprawdzić bez czytania kodu | Czerwona flaga |
|---|---|---|
| Overrides rdzenia | policz pliki w /override/ przed i po instalacji modułu | moduł dorzuca kilkanaście plików do nadpisania |
| Dane dostępowe | przeszukaj repo po „api_key”, „/var/www”, adresach IP | klucze i ścieżki wpisane w kod |
| Standardy kodu | poproś o phpcs.xml i wynik analizy w CI | brak jakiejkolwiek konfiguracji |
| Obsługa błędów | odłącz API w sandboxie i obserwuj zachowanie modułu | biały ekran albo połowa zamówień przetworzona |
| Testy przed aktualizacją | zapytaj o checklistę scenariuszy i raport ze stagingu | odpowiedź „powinno działać” |
Moduł na zamówienie dostaje dokładnie takie uprawnienia, jakie daje mu platforma — dlatego bezpieczeństwo projektuje się na etapie kodu, a nie dopisuje po pierwszym incydencie. W WordPressie każde dane z formularza przepuszczaj przez sanitize_text_field(), absint() lub wp_kses_post(), a wyjście przez esc_html() i esc_attr(). W PrestaShop odpowiednikiem jest Tools::getValue() w parze z Validate::isInt() i Validate::isEmail(), a zapytania idą przez PDO z parametrami — nigdy przez sklejanie SQL-a.
Własny endpoint zabezpieczasz podwójnie: nonce (wp_nonce_field() i check_admin_referer()) oraz weryfikacja uprawnień (current_user_can(); w PrestaShop token pracownika i sprawdzenie profilu). Sam nonce bez sprawdzenia roli to dziura — nonce da się pobrać z publicznie dostępnej strony.
Klucze API do płatności, kurierów czy ERP trzymaj w zmiennych środowiskowych albo w stałych w wp-config.php, poza repozytorium. Klucz wpisany na sztywno w plik modułu trafia do Gita i zostaje u każdego, kto kiedykolwiek sklonował repo.
Wydajność mierz przed i po. Przed wdrożeniem zrób test Lighthouse i PageSpeed Insights na stagingu, po wdrożeniu powtórz go na produkcji, na tym samym urządzeniu i tym samym połączeniu. Patrz na LCP i TTFB — najczęstszy grzech to zapytanie SQL w pętli (N+1) albo brak indeksu na kolumnie filtrowanej. Progi i definicje znajdziesz w materiałach o Core Web Vitals.
RODO: jeśli moduł zapisuje imię, e-mail, telefon, adres dostawy albo wysyła te dane do zewnętrznego API, przetwarza dane osobowe. Wtedy potrzebna jest umowa powierzenia przetwarzania (art. 28 RODO) i wpis w rejestrze czynności. Moduł liczący anonimowe statystyki takich danych nie dotyka.
Warunek startu na produkcji jest jeden: świeży zrzut bazy (mysqldump lub panel hostingu) i plików, sprawdzony testem odtworzenia na stagingu. Dostęp do serwera dajesz na koncie z minimalnymi uprawnieniami i kluczem SSH, nie na głównym koncie root — w razie problemu zakres szkód jest wtedy policzalny.
| Obszar | Co konkretnie | Jak sprawdzić |
|---|---|---|
| Dane wejściowe | sanitize_text_field(), absint(), Validate::isInt() | Test formularza z payloadem ze znacznikiem script i znakami spoza UTF-8 |
| Endpointy | nonce plus weryfikacja roli lub tokenu pracownika | Wywołanie endpointu bez logowania i z konta o niższych uprawnieniach |
| Sekrety | klucze w .env lub wp-config.php, poza repo | przegląd historii commitów i skan repozytorium |
| Wydajność | brak zapytań w pętli, indeksy na kolumnach filtrowanych | Lighthouse i PageSpeed Insights przed i po wdrożeniu |
| Kopie zapasowe | dump bazy i plików przed każdym wdrożeniem | Odtworzenie kopii na stagingu i test kluczowych ścieżek |
Wdrożenie kończy się w dniu startu na produkcji. Od tego momentu potrzebny jest rytm: kto, kiedy i co sprawdza. W WordPressie rdzeń i wtyczki aktualizuj raz w miesiącu, a poprawki bezpieczeństwa w ciągu 48 godzin od publikacji. W PrestaShop zostawaj na gałęzi patch i nie wskakuj od razu na nowe wydanie major — najpierw staging, potem produkcja. Własny moduł przeglądaj raz na kwartał pod kątem zgodności z nową wersją PHP i API platformy; harmonogram wydań i zmiany w API opisuje dokumentacja dla deweloperów PrestaShop.
Monitoring to trzy niezależne warstwy. Pierwsza: dostępność sklepu sprawdzana co minutę (UptimeRobot, Better Stack) z alertem na maila i Slacka. Druga: błędy PHP — logi serwera albo Sentry, z progiem alertu ustawionym na powtarzający się błąd, nie na pojedynczy wpis. Trzecia, najczęściej pomijana: nieudane transakcje. Zestaw zamówienia zakończone statusem błędu płatności z liczbą wejść na stronę koszyka i porównaj tydzień do tygodnia. Spadek konwersji o 2 punkty procentowe przy stabilnym ruchu prawie zawsze oznacza problem techniczny, a nie sezonowość.
Co realnie oznacza SLA: konkretne liczby i kanał zgłoszeń. Ustalone z góry, nie improwizowane przy awarii. Bez tego każde zgłoszenie trafia do kolejki „kiedyś”.
Na koniec współpracy zadaj jedno pytanie: czy dostaję kod, repozytorium i dokumentację? Jeśli moduł istnieje tylko na serwerze wykonawcy, a Ty nie masz dostępu do źródeł, następny deweloper zaczyna od zera — albo wcale. Warto to ustalić przed podpisaniem umowy.
| Priorytet | Przykład | Czas reakcji | Czas naprawy |
|---|---|---|---|
| Krytyczny | Sklep nie przyjmuje zamówień, błąd 500 na karcie produktu | 1 h w godzinach 8:00-16:00 | do 8 h roboczych |
| Wysoki | Nie działa jedna metoda płatności lub wysyłki | 4 h | do 24 h roboczych |
| Normalny | Błąd w eksporcie CSV, literówka w e-mailu transakcyjnym | 1 dzień roboczy | do 5 dni roboczych |
| Niski | Kosmetyka, drobne usprawnienia interfejsu | 3 dni robocze | wg kolejki zadań |
Praca zdalna nie oznacza pracy bez kontroli. Standard wygląda tak: repozytorium Git (GitHub, GitLab albo Bitbucket — u Ciebie lub u wykonawcy), osobna gałąź na każde zadanie, pull request z opisem zmian i przeglądem kodu przed wdrożeniem. Staging to osobna subdomena z kopią bazy. Bez stagingu każda poprawka ląduje prosto na produkcji i pierwszym testerem jest Twój klient.
Komunikacja idzie jednym uzgodnionym kanałem — mail, Slack albo system zgłoszeń, a nie jednocześnie Messenger, SMS i telefon. Do tego krótki status raz w tygodniu: co zrobione, co w toku, co blokuje. Przed odbiorem demo na stagingu, żebyś klikał działającą rzecz, a nie czytał opis.
Zgłoszenia trafiają bezpośrednio do osoby, która pisze kod, a nie przez handlowca. Różnica widać przy błędach: pytanie techniczne wraca z odpowiedzią, a nie z prośbą o doprecyzowanie. O organizacji takiego projektu od strony briefu pisaliśmy szerzej przy okazji niestandardowych modułów i wtyczek dla firm z Torunia.
Spotkania online wystarczają na brief, demo i odbiór. Google Meet albo Zoom z udostępnianiem ekranu, 30-45 minut na etap. Nie musisz jechać do biura ani rezerwować całego dnia — brief można zamknąć w jednej rozmowie z podzielonym ekranem, na którym omawiamy makietę i listę integracji.
Dlaczego firmy z Torunia, Bydgoszczy i reszty województwa kujawsko-pomorskiego pracują z zespołami z Zamościa i Lublina? Trzy powody: ta sama strefa czasowa i język roboczy, dostępność specjalistów od PrestaShop i WordPressa, których w mniejszych ośrodkach trudniej zebrać w jednym zespole, oraz brak pośredników w łańcuchu decyzji. Odległość nie ma znaczenia, gdy repozytorium, staging i kanał komunikacji są ustalone od pierwszego dnia. Podobny model pracy opisujemy przy wdrożeniach dla firm z Zamościa.
Brief w jednym zdaniu, np. „chcę moduł do wysyłki”. Wykonawca musi zgadywać zakres, więc każdy wycenia coś innego.
Jak wykryć: Wyślij to samo zapytanie do trzech firm. Jeśli wyceny różnią się o więcej niż 50%, problem leży w opisie, nie w wykonawcach.
Jak naprawić: Rozpisz cel biznesowy, użytkownika, dane wejściowe, integracje i kryteria akceptacji. Nawet pół strony A4 wystarczy, żeby wyceny były porównywalne.
Zamawianie modułu, zanim sprawdzi się wtyczki gotowe. Czasem rozwiązanie za kilkaset złotych rocznie robi 95% potrzebnej pracy.
Jak wykryć: Policz, ile godzin miesięcznie zajmuje ręczne obejście problemu. Jeśli to 15 minut raz na kwartał, moduł na zamówienie się nie zwróci.
Jak naprawić: Przejrzyj katalog wtyczek pod kątem konkretnej funkcji, nie kategorii. Dopiero gdy żadna nie obsługuje polskiego kuriera albo zbiorczego eksportu, wracaj do rozmowy o kodzie na zamówienie.
Testowanie nowego modułu bezpośrednio na produkcji, na żywym sklepie z zamówieniami klientów.
Jak wykryć: Pytanie kontrolne do wykonawcy brzmi: na jakim środowisku będziemy testować i czy jest to kopia bazy produkcyjnej.
Jak naprawić: Postaw staging – kopię sklepu na osobnym adresie i osobnej bazie. Testy tam kosztują mniej niż jedna nieudana promocja.
Sztywna cena bez specyfikacji. Przy zmianach zakresu wykonawca albo dopisuje aneks, albo ucina funkcje, żeby zmieścić się w budżecie.
Jak wykryć: Oferta mówi „moduł do integracji z ERP – 4000 zł” i nic więcej. Nie ma listy funkcji ani godzin.
Jak naprawić: Proś o wycenę godzinową z zakresem prac. Wtedy wiadomo, ile kosztuje dodatkowa funkcja, a ile można z niej zrezygnować.
Brak repozytorium i dokumentacji po odbiorze. Kod zostaje na komputerze wykonawcy, a firma nie ma jak go rozwijać ani przekazać innemu zespołowi.
Jak wykryć: Zapytaj przed startem, gdzie trafi kod i czy dostaniesz dostęp do repozytorium oraz instrukcję aktualizacji.
Jak naprawić: Wpisz do umowy przekazanie repozytorium, dokumentacji wdrożenia i instrukcji aktualizacji jako warunek odbioru końcowego.
Płacenie całości z góry i brak kamieni milowych. Klient traci dźwignię, jeśli projekt się opóźnia.
Jak wykryć: Faktura na 100% przed pierwszą linią kodu to sygnał ostrzegawczy.
Jak naprawić: Ustal trzy punkty: zaliczka na start, płatność po odbiorze etapu na stagingu, płatność po wdrożeniu produkcyjnym i przekazaniu dokumentacji.
Moduł na zamówienie ma sens wtedy, gdy brak funkcji regularnie zabiera czas pracownikom albo blokuje proces, którego nie da się obejść gotową wtyczką. Wycena liczona godzinowo – od 8–16 godzin na prosty moduł do 120–250 godzin na złożoną integrację – jest bezpieczniejsza niż sztywna cena bez zakresu, bo wiadomo, za co się płaci. Brief z celem biznesowym, danymi wejściowymi i kryteriami akceptacji skraca wycenę i pozwala porównać oferty bez zgadywania. Reszta to proces: staging, kamienie milowe, odbiór i dokumentacja przekazana klientowi.
Nie ma jednej ceny, bo rozliczenie idzie za godzinami. Prosty moduł to zwykle 8–16 godzin, średni 40–80 godzin, a złożony z integracją zewnętrzną 120–250 godzin. Moduł eksportujący zamówienia do ERP to typowo około 60 godzin pracy, licząc analizę, kod, testy i dokumentację.
Może przestać, jeśli korzysta z funkcji, które zmieniły się w nowej wersji. Ryzyko ogranicza się na dwa sposoby: kod trzyma się udokumentowanych mechanizmów platformy, a nie hacków, oraz przed każdą aktualizacją robi się test na stagingu. Warto od razu ustalić, kto odpowiada za taki przegląd i ile kosztuje.
Prosty moduł to zwykle kilka dni roboczych, średni projekt dwa do czterech tygodni, integracja z zewnętrznym API potrafi zająć dwa miesiące. Największym ryzykiem terminu nie jest samo pisanie kodu, tylko czas oczekiwania na dostęp do dokumentacji API po stronie zewnętrznego dostawcy.
To kwestia ustaleń w umowie i warto ją rozstrzygnąć przed startem, nie po odbiorze. W praktyce klient powinien dostać repozytorium z kodem, dokumentację wdrożenia i instrukcję aktualizacji. Bez tego zostaje z modułem, którego nie da się rozwijać poza jednym wykonawcą.
Gdy gotowe rozwiązanie pokrywa większość potrzeb, a brakujący element da się obejść ręcznie raz na kwartał. Wtyczka za około 300 zł rocznie robiąca 95% pracy zwykle wygrywa z modułem za kilkanaście tysięcy złotych. Własny kod ma sens, gdy brak funkcji regularnie blokuje proces albo gdy licencja wtyczki ogranicza liczbę domen lub wymusza subskrypcję.
Zestaw oferty w tabeli: liczba godzin, zakres prac, co nie wchodzi w cenę, termin, warunki płatności i to, co dostajesz na koniec. Jeśli jedna oferta jest dwa razy tańsza, sprawdź, czy nie pomija testów, dokumentacji albo środowiska stagingu. Wycena godzinowa z jasnym zakresem jest łatwiejsza do porównania niż sztywna kwota bez specyfikacji.
Oficjalna dokumentacja dla deweloperów opisuje strukturę modułu, rejestrację hooków i plik główny: PrestaShop Developer Documentation. Warto zajrzeć tam przed rozmową z wykonawcą, żeby rozumieć, o czym mówi w wycenie.
Jeśli nie wiesz, czy w Twoim sklepie wystarczy wtyczka, czy potrzebny jest moduł pisany na zamówienie, opisz krótko proces, który chcesz usprawnić – odpowiemy, co da się zrobić gotowym rozwiązaniem, a co wymaga kodu. Zobacz też, jak podchodzimy do aplikacji dedykowanych.