Niestandardowe moduły i wtyczki w Zamościu wyceniamy zadaniowo, nie z cennika. Punkt odniesienia: stawka 90–160 zł/h netto i typowe zakresy – prosty moduł integracyjny 16–32 h, logika koszyka 40–80 h, integracja z ERP z mapowaniem danych 80–160 h i więcej. W praktyce daje to 2 000–5 000 zł za mały moduł, 8 000–25 000 zł za średnią integrację i 25 000 zł+ za ERP lub niestandardową logikę procesu. Poniżej rozkładamy, co podnosi tę kwotę, jak krok po kroku liczymy godziny i na co patrzeć w ofercie, żeby porównywać ze sobą porównywalne zakresy.
Zacznijmy od liczby, którą wpiszesz do budżetu. Stawka godzinowa za pracę nad niestandardowym modułem lub wtyczką dla firm z Zamościa i okolic to 90–160 zł/h netto. Dolna granica dotyczy mid-level developera, z którym pracujesz bezpośrednio na B2B – bez pośrednika, bez projektu technicznego, bez gwarancji na poprawki po odbiorze. Górna – seniora w agencji, gdzie w stawkę wchodzi też analiza wymagań, testy, wdrożenie na produkcję, okres wsparcia po odbiorze i ktoś, kto odbierze od Ciebie telefon pół roku po zakończeniu prac.
Godziny mnożysz przez stawkę i dostajesz widełki. Przykład: moduł, który zajmie 60 h, wyceniony po 100 zł/h to 6 000 zł. Ten sam moduł w agencji po 150 zł/h to 9 000 zł – i zwykle będzie droższy jeszcze o 10–20 h na testy i dokumentację, których freelancer często nie ujmuje w ofercie.
Punkt odniesienia w liczbach:
Zastrzeżenie, które powtarzamy każdemu klientowi: to nie cennik, to widełki wyceny zadaniowej. Podajemy je po to, żebyś miał benchmark i wiedział, kiedy oferta za 3 000 zł na integrację z ERP jest nierealna, a kiedy 18 000 zł za prosty eksport zamówień to nadpłata. Kwotę da się ustalić dopiero po spisaniu zakresu – inaczej porównujesz dwie oferty opisujące dwa różne moduły. Jak wygląda taki proces od strony organizacyjnej i co dokładnie zamawiasz, rozpisaliśmy przy temacie wyceny niestandardowych modułów i wtyczek w Zamościu.
| Typ modułu | Zakres godzin | Kwota końcowa (netto) |
|---|---|---|
| Prosty moduł integracyjny (jedno API, dodatkowe pole, eksport zamówień) | 16–32 h | 2 000–5 000 zł |
| Moduł logiki koszyka (progi, rabaty warunkowe, łączenie promocji) | 40–80 h | 4 000–12 000 zł |
| Integracja ERP z mapowaniem danych | 80–160 h i więcej | 8 000–25 000 zł |
| Niestandardowa logika procesu (konfigurator, wycena, workflow) | 120–250 h i więcej | 25 000 zł+ |
Dwie oferty na „to samo” mogą różnić się trzykrotnie i obie być uczciwe. Różnica siedzi w szczegółach, które klient może ocenić sam, bez czytania kodu.
1. Liczba integracji zewnętrznych. Każde API to osobny zakres: autoryzacja (token, OAuth), środowisko testowe, obsługa błędów, limity zapytań, mapowanie statusów. InPost ShipX, DPD i DHL mają inne modele danych – pierwsze API zajmuje 24–40 h, bo powstaje szkielet i warstwa komunikacji, każde kolejne 12–24 h. Do tego dochodzi pytanie o zachowanie przy odpowiedziach 4xx i 5xx: czy zamówienie ma się cofnąć, czy trafić do kolejki ponowień. Standard HTTP opisuje RFC 9110 i to jest dokument, który warto znać, jeśli chcesz zrozumieć, po co płacisz za obsługę błędów.
2. Hooki kontra nadpisywanie core. W PrestaShop sprawdź, czy istnieje hook obsługujący Twoją akcję (np. przy zapisie koszyka, w widoku zamówienia). Jeśli nie – trzeba nadpisać klasę, a wtedy każda aktualizacja platformy wymaga weryfikacji. Na WordPress/WooCommerce odpowiednikiem są akcje i filtry, ale część wtyczek i tak nadpisuje szablony, co psuje aktualizacje.
3. Wielojęzyczność, wielowalutowość, multistore. Każdy z tych wymiarów mnoży konfigurację i testy. Multistore w PrestaShop oznacza osobne ustawienia na sklep i identyfikatory sklepów w każdym zapytaniu do bazy.
4. Dane historyczne do migracji. Stary moduł, którego dane nie eksportują się czysto, to 8–40 h pracy zależnie od jakości źródła.
5. Panel administracyjny. Prosty formularz to kilka godzin. Widok z filtrowaniem, sortowaniem, eksportem i akcjami masowymi to 16–40 h.
6. Testy regresji po aktualizacji platformy i PHP. 4–8 h na cykl. Jeśli dostawca tego nie wycenił, zrobi to „za darmo” albo wcale – w drugim przypadku dowiesz się o błędzie od klienta.
7. Dokumentacja i przekazanie kodu. 4–8 h jednorazowo, obniża koszt każdej przyszłej zmiany. Wpisz to w umowę. Sposób uporządkowania tych ustaleń opisujemy przy organizacji pracy nad modułami w Zamościu.
| Czynnik | Typowy wpływ na godziny |
|---|---|
| Każde kolejne API zewnętrzne (InPost ShipX, DPD, DHL, ERP) | 12–24 h na API; pierwsze 24–40 h |
| Brak hooka – override klasy core / nadpisany szablon | +20–50% zakresu i weryfikacja przy każdej aktualizacji |
| Wielojęzyczność, wielowalutowość, multistore | +30–60% na konfigurację i testy |
| Migracja danych historycznych | 8–40 h zależnie od jakości źródła |
| Rozbudowany panel administracyjny (filtry, eksport, akcje masowe) | 16–40 h |
| Testy regresji po aktualizacji platformy i PHP | 4–8 h na cykl |
| Dokumentacja i przekazanie kodu | 4–8 h jednorazowo |
Najczęstszy dylemat: kupić wtyczkę za 199 USD rocznie czy zamówić moduł. Policzmy na trzy lata, przy kursie ok. 4 zł za dolara (sprawdź aktualny przed decyzją).
Wtyczka premium: 199 USD rocznie × 3 = 597 USD, czyli około 2 400 zł. Moduł na zamówienie: 16–32 h, czyli 2 000–5 000 zł jednorazowo, plus 4–8 h rocznie na utrzymanie – aktualizacja pod nową wersję PHP, testy po aktualizacji platformy, drobne poprawki. Przez trzy lata to 12–24 h, czyli 1 400–3 800 zł. Razem moduł kosztuje 3 400–8 800 zł.
Wniosek pierwszy: przy standardowej funkcji wtyczka jest tańsza. Wniosek drugi: rachunek zmienia się, gdy wtyczka przestaje być rozwijana.
Ryzyko porzucenia wtyczki (abandoned plugin). Autor przestaje wydawać aktualizacje, a Twoja platforma idzie do przodu. Wtyczka zaczyna sypać błędami przy nowym PHP, a Ty nie masz jak jej naprawić, bo nie masz kodu albo nie wolno Ci go ruszać. Przepisanie funkcji od zera to zwykle 60–100% pierwotnego kosztu modułu – jeśli moduł kosztował 5 000 zł, licz się z 3 000–5 000 zł na odtworzenie tego samego.
Kiedy wtyczka wygrywa: funkcja jest standardowa (faktura PDF, podstawowe metody dostawy), wtyczka ma szeroką społeczność i tysiące instalacji, nie masz wymagań specyficznych dla swojego procesu.
Kiedy wygrywa moduł: logika procesu, której nie ma w żadnym marketplace (np. wycena zależna od strefy i gabarytu); integracja z Twoim wewnętrznym ERP, do którego nikt nie napisał konektora; wymóg wydajności przy katalogu kilkudziesięciu tysięcy SKU, gdzie wtyczka odpala zapytanie w pętli.
Pułapka licencyjna: zanim kupisz wtyczkę „premium”, przeczytaj, czy wolno modyfikować kod i czy wsparcie obejmuje pliki zmienione przez Ciebie. Część licencji tego zabrania – wtedy każda poprawka łamie warunki, a producent może odmówić pomocy. Jeśli planujesz pracę z zespołem zewnętrznym, zobacz, jak rozkładamy to na etapy przy organizacji pracy przy modułach w Chełmie.
| Pozycja | Wtyczka premium | Moduł na zamówienie |
|---|---|---|
| Koszt początkowy | 199 USD/rok | 16–32 h → 2 000–5 000 zł |
| Koszt licencji w 3 lata | ≈ 597 USD ≈ 2 400 zł | — |
| Utrzymanie (4–8 h/rok) | — | 12–24 h → 1 400–3 800 zł |
| Razem 3 lata | ≈ 2 400 zł | 3 400–8 800 zł |
| Ryzyko porzucenia | przepisanie funkcji: 60–100% kosztu modułu | kod zostaje u Ciebie |
Wycena zaczyna się od audytu, nie od cennika. Proces wygląda zawsze tak samo — różni się tylko liczbą godzin. Poniżej pięć kroków, które możesz porównać z dowolną ofertą.
Etap 1: audyt wymagań (1–3 h). Robimy go na dostępie do sklepu, panelu i hostingu, w rozmowie z osobą, która faktycznie obsługuje proces. Cel jest jeden: oddzielić „musi być” od „miło by było”. Przykład z praktyki: klient zamawia „integrację z ERP”. W audycie wychodzi, że krytyczne jest tylko pobieranie stanów magazynowych co 15 minut, a faktury mają zostać wystawiane ręcznie. To różnica kilkudziesięciu godzin w wycenie.
Etap 2: rozbicie na zadania (WBS). Każda pozycja to osobne zadanie z liczbą godzin, widoczne dla klienta. Typowy moduł integracyjny rozbija się na: kontroler i hooki, tabelę w bazie z migracją, zadanie cron, logowanie i obsługę błędów, panel konfiguracji w back office, testy na kopii sklepu. Struktura modułu PrestaShop to właśnie hooki, kontrolery i pliki w katalogu /modules — opisuje to dokumentacja dla deweloperów PrestaShop.
Etap 3: bufor 15–20%. To nie ukryta marża. Wykorzystujemy go, gdy API po stronie ERP zwraca inny format niż w dokumentacji, hosting blokuje cron albo trzeba dopisać drugą walutę. Jeśli bufor nie zostanie użyty, nie pojawia się na fakturze — rozliczamy faktyczne godziny.
Etap 4: wycena w formie zakres + godziny + stawka. Nie jedna kwota z sufitu. Etap 5: raport po wdrożeniu z faktycznie zużytych godzin, żeby różnica między wyceną a realizacją była jawna.
Zasada, którą stosujemy zawsze: jeśli po audycie okaże się, że moduł nie jest potrzebny, mówimy to wprost i proponujemy konfigurację natywną. Jak przekłada się to na kwoty, rozpisaliśmy w materiale o cenach niestandardowych modułów i wtyczek w Zamościu.
| Etap | Co dostaje klient | Typowy czas |
|---|---|---|
| 1. Audyt wymagań | Lista funkcji „musi być” / „miło by było”, źródła danych, wolumeny zamówień | 1–3 h |
| 2. WBS | Rozbicie na zadania z liczbą godzin przy każdym zadaniu | 2–4 h pracy analitycznej |
| 3. Bufor | 15–20% na nieprzewidziane, doliczany tylko jeśli faktycznie wykorzystany | — |
| 4. Wycena | Zakres + godziny + stawka, zamiast jednej kwoty | — |
| 5. Raport | Zestawienie faktycznie zużytych godzin po wdrożeniu | po odbiorze |
Oferta na moduł niestandardowy ma dwie części: zakres i sposób rozliczenia. Jeśli brakuje którejkolwiek, nie masz czego porównywać. Sześć sygnałów, które powinny zapalić lampkę.
Jak poukładać te ustalenia w harmonogramie projektu, opisujemy w tekście o organizacji pracy przy niestandardowych modułach i wtyczkach.
Budżet kończy się w momencie odbioru modułu tylko na papierze. W praktyce każdy niestandardowy moduł generuje koszt utrzymania: przy typowym sklepie 4–8 h rocznie na moduł. W tej liczbie siedzi przegląd po aktualizacji sklepu, testy po zmianie wersji PHP i drobne poprawki zgodności. Jeśli moduł dotyka płatności albo koszyka, schodzimy z tego widełka w górę — każda zmiana po stronie bramki płatniczej wymaga przejścia testów transakcji w Sandboxie i na produkcji.
Ryzyko jest konkretne, nie teoretyczne. Aktualizacja PrestaShop 1.7 → 8.x zmienia środowisko (Symfony, nowsze PHP) i moduł nietknięty od trzech lat często nie wstaje. W WooCommerce włączenie HPOS (High-Performance Order Storage) potrafi rozłożyć wtyczkę, która czyta zamówienia bezpośrednio z metadanych wpisów. Dlatego każdą taką zmianę testujemy na kopii sklepu, zanim dotkniemy produkcji.
Drugi element to SLA, czyli ustalenie, co dzieje się, gdy coś padnie. W pakietach godzinowych 5 / 10 / 20 h miesięcznie zapisujemy cztery rzeczy: czas reakcji, czas naprawy, kanał zgłoszeń (mail, zgłoszenie w repozytorium czy telefon) i dostępność poza godzinami pracy. Bez tych czterech punktów „opieką” można nazwać wszystko.
Koszt braku opieki liczy się w utraconych zamówieniach, nie w godzinach. Sklep robiący 60 zamówień dziennie przy średniej wartości 250 zł traci około 15 000 zł za każdy dzień przestoju w szczycie sezonu. Czterogodzinna naprawa po stawce 140 zł/h to 560 zł — zupełnie inna skala. Sposób ułożenia takiej współpracy opisujemy przy okazji organizacji pracy nad modułami niestandardowymi.
| Pakiet godzinowy | Do czego zwykle wystarcza | Co zapisujemy w SLA |
|---|---|---|
| 5 h / mies. | jeden moduł, sporadyczne zgłoszenia, przegląd po aktualizacji | czas reakcji, kanał zgłoszeń |
| 10 h / mies. | 2–3 moduły albo moduł dotykający koszyka lub płatności | czas reakcji, czas naprawy, kolejność zgłoszeń |
| 20 h / mies. | integracja z ERP, kilka wtyczek, prace rozwojowe | czas reakcji, czas naprawy, dostępność poza godzinami |
Widełki 90–160 zł/h netto przestają być abstrakcją dopiero na konkretnym zamówieniu. Trzy scenariusze, które najczęściej trafiają do nas z Zamościa, Krasnegostawu i Biłgoraja.
| Scenariusz | Co dopisaliśmy | Godziny | Kwota netto |
|---|---|---|---|
| A. Płatność odroczona B2B | moduł płatności, walidacja, pro forma, cron | 20 h | 2 400 zł |
| B. Synchronizacja z Subiektem GT | mapowanie, zapis zamówień, odczyt stanów, kolejka, logi | 96 h | 12 480 zł |
| C. Koszyk WooCommerce | ceny per rola, rabaty, progi dostawy | 56 h | 5 600 zł |
Wycena w DropDigital zajmuje 30 minut pod jednym warunkiem: dostajemy komplet informacji. Bez nich pierwsze spotkanie zamienia się w zbieranie faktów, a wstępna kwota bywa zaniżona o 30–40%, co wychodzi dopiero w trakcie prac.
Co przygotować przed kontaktem:
Najczęstsza pułapka to brak listy wtyczek. Dwie wtyczki modyfikujące ceny w tym samym miejscu koszyka to konflikt wart 6–10 h. Brak dostępu do ERP to kolejne 4–8 h na uzgodnienia, a brak słownika pól — 8–16 h. Dlatego organizacja pracy przy niestandardowych modułach w Zamościu zaczyna się jeszcze przed pierwszym spotkaniem.
| Co przygotować | Efekt dla wyceny |
|---|---|
| Konto techniczne do panelu i hostingu | brak blokady przy weryfikacji po 2–3 dniach |
| Opis procesu w punktach + częstotliwość użycia | trafniejszy szacunek godzin, mniej zmian w trakcie |
| Lista wtyczek i wersje (PHP, MySQL, motyw) | wykrycie konfliktów przed startem, nie w połowie prac |
| Dokumentacja API i kontakt techniczny | krótsze mapowanie pól przy integracji z ERP |
| Decyzja o prawach do kodu i aktualizacjach | jasny zakres utrzymania po wdrożeniu |
Traktowanie wstępnej wyceny „na oko” jako ceny stałej i podpisywanie umowy bez rozbicia na zadania.
Jak wykryć: Oferta ma jedną kwotę końcową i zero informacji, ile godzin pochłania które zadanie. Nie ma listy funkcji ani zakresu wyłączonego.
Jak naprawić: Poproś o rozbicie na zadania z liczbą godzin per zadanie (WBS) i o listę rzeczy, które w zakres nie wchodzą. Dopiero na tym poziomie da się porównać dwie oferty.
Brak bufora na nieprzewidziane i brak zapisu, kiedy ten bufor jest zwracany.
Jak wykryć: W kosztorysie nie ma pozycji „rezerwa”, a deweloper mówi, że „wszystko jest już jasne”. Przy integracjach zewnętrznych to rzadko prawda.
Jak naprawić: Wpisz do umowy bufor 15–20% z zasadą rozliczenia: wykorzystany tylko po opisaniu przyczyny, niewykorzystany wraca do Ciebie jako obniżenie faktury końcowej lub godziny na rozwój.
Zlecanie modułu bez sprawdzenia, czy platforma ma gotowe hooki i czy nie trzeba nadpisywać rdzenia.
Jak wykryć: Pytanie „robimy to hookiem czy overridem?” kończy się ciszą albo odpowiedzią „będziemy modyfikować core”. Wtedy każda aktualizacja platformy to ryzyko.
Jak naprawić: Zweryfikuj dostępne mechanizmy w dokumentacji deweloperskiej platformy, np. PrestaShop Developer Documentation. Wymagaj, żeby rozwiązanie opierało się na hookach, a nadpisania (override) były wypisane osobno w ofercie wraz z konsekwencjami przy aktualizacjach.
Pomijanie kosztu utrzymania po aktualizacji platformy i PHP.
Jak wykryć: W ofercie nie ma ani jednej godziny na testy regresji. Nazwa wersji PHP, na której moduł ma działać, nie pojawia się w rozmowie.
Jak naprawić: Wpisz do budżetu 4–8 h rocznie na przegląd i testy po aktualizacjach. Zapytaj wprost, kto reaguje, gdy po podbiciu PHP moduł przestanie działać i ile to kosztuje.
Zakup wtyczki premium bez sprawdzenia licencji na modyfikacje.
Jak wykryć: Nie wiesz, czy wolno Ci zmieniać kod, czy dostajesz tylko subskrypcję, czy przy braku opłaty moduł przestaje się aktualizować, ale dalej działa na produkcji.
Jak naprawić: Przeczytaj warunki licencji przed zakupem. Jeśli planujesz forka albo zmiany w kodzie, sprawdź, czy jest to dozwolone i czy nie tracisz wsparcia. Przy licencji niejasnej załóż scenariusz przepisania funkcji od zera.
Mieszanie wymagań „musi być” z „miło by było” i wycenianie ich razem.
Jak wykryć: Lista wymagań ma 30 punktów bez priorytetów, a rozmowa o zakresie kończy się stwierdzeniem „dogadamy się w trakcie”.
Jak naprawić: Podziel wymagania na trzy koszyki: obowiązkowe na start, dołożenie w drugim etapie, pożądane na przyszłość. Wyceń etap pierwszy, resztę zostaw jako szacunek z jawnym zastrzeżeniem, że to nie jest zobowiązanie.
Cena modułu to nie liczba z cennika, ale wynik trzech zmiennych: liczby integracji, liczby wariantów (języki, waluty, sklepy) i tego, czy da się pracować na hookach, czy trzeba nadpisywać rdzeń. Widełki 90–160 zł/h netto i zakresy 16–160 h dają benchmark, który pozwala ocenić ofertę w kilka minut. Zanim podpiszesz cokolwiek, zażądaj rozbicia na zadania, jawnego bufora z zasadą zwrotu i zapisu o przekazaniu kodu. Bez tych trzech elementów porównujesz wrażenia, nie koszty.
Punkt odniesienia to stawka 90–160 zł/h netto, zależnie od seniority i od tego, czy pracujesz z deweloperem bezpośrednio, czy przez agencję. Prosty moduł integracyjny to zwykle 16–32 h, czyli 2 000–5 000 zł. Moduł z logiką koszyka to 40–80 h. Integracja z ERP z mapowaniem danych to 80–160 h i więcej, co daje 25 000 zł+.
Bo prawie nigdy nie dotyczą tego samego. Jedna oferta obejmuje jedną integrację i prosty formularz w panelu, druga – trzy integracje, wielojęzyczność, migrację starych danych i testy regresji. Zanim porównasz kwoty, porównaj listy zadań i zakres wyłączony. Jeśli którejś oferty nie da się rozbić na zadania, nie porównujesz ceny, tylko poziom ogólności opisu.
Czasem wyjdzie i wtedy warto ją kupić. Policz jednak trzy lata: wtyczka za 199 USD rocznie to około 600 USD plus czas na wdrożenie i obejścia. Własny moduł kosztuje raz, ale dochodzi 4–8 h rocznie na utrzymanie. Jeśli Twoja logika procesu jest standardowa i wtyczka ma szeroką społeczność, kupno się broni. Jeśli funkcja wynika z Twojego procesu albo z wewnętrznego ERP – nie ma czego kupić.
Zostajesz z działającym kodem bez aktualizacji. Po podbiciu PHP lub platformy funkcja może przestać działać w najmniej wygodnym momencie. Awaryjne przepisanie tej samej funkcji to zwykle 60–100% pierwotnego kosztu modułu, liczone od zera, bez skrótów. Dlatego przy wtyczkach, na których opiera się sprzedaż, warto wcześniej mieć plan B i dostęp do kodu.
Nie, jeśli jest zapisany w umowie razem z zasadą rozliczenia. Bufor to rezerwa na sytuacje, których nie da się przewidzieć na etapie wyceny – zmiana w API przewoźnika, dokumentacja ERP niezgodna ze stanem faktycznym, dane, których nie da się wyeksportować czysto. Ukryty koszt to brak bufora: wtedy albo dostajesz wezwanie do dopłaty w trakcie prac, albo zakres jest po cichu okrajany.
Tak i zwykle tak robimy. Etap pierwszy obejmuje funkcję niezbędną do uruchomienia, kolejne to rozwinięcia: eksporty, dodatkowe integracje, rozbudowany panel. Zaleta jest podwójna – płacisz za to, co realnie działa, a po pierwszym etapie widzisz jakość kodu i komunikacji, zanim zlecisz resztę. Wymaga to jednak podziału wymagań na koszyki już na etapie audytu.
Nie ma jednego źródła, które da gwarancję. Sensowna praktyka to oparcie modułu na mechanizmach rozszerzeń przewidzianych przez platformę, zamiast modyfikowania rdzenia, oraz wpisanie testów regresji w utrzymanie. Ogólne zasady działania wyszukiwarki po zmianach technicznych znajdziesz w dokumentacji Core Web Vitals, ale kwestie zgodności kodu z nową wersją PHP czy PrestaShop rozwiązuje się w repozytorium, nie w poradnikach.
Jeśli chcesz porównać swoją ofertę z naszym sposobem liczenia godzin, wyślij nam zakres – powiemy wprost, które pozycje są niedoszacowane. Zobacz też, jak podchodzimy do ceny i organizacji modułów w Zamościu.