Niestandardowe moduły i wtyczki Biłgoraj to najczęściej projekt prowadzony zdalnie, z jednym lub dwoma spotkaniami na kluczowych etapach. Sukces nie zależy tu od odległości, a od organizacji: kto podejmuje decyzje, jak wygląda specyfikacja i co dokładnie uznajemy za skończone. W tym tekście skupiamy się na części organizacyjnej: wyborze wykonawcy, procesie, kosztach, odbiorze i utrzymaniu. Ceny i terminy podajemy jako widełki, bo bez zakresu żadna liczba nie jest wiążąca.
W PrestaShop moduł to katalog w /modules/ z głównym plikiem PHP, klasą dziedziczącą po Module, metodami install() i uninstall() oraz podpiętymi hookami, np. hookDisplayHeader albo hookActionCartSave. W WordPress wtyczka to plik z nagłówkiem Plugin Name w katalogu wp-content/plugins/, który reaguje na zdarzenia przez add_action() i add_filter(). WooCommerce dokłada własne hooki, np. woocommerce_checkout_create_order czy woocommerce_cart_calculate_fees. Przed rozmową z wykonawcą warto przejrzeć dokumentację obu systemów: PrestaShop – dokumentacja dla deweloperów i WooCommerce – dokumentacja, bo tam widać, co realnie da się zrobić bez ruszania rdzenia.
Typowe zlecenia, które trafiają jako moduł lub wtyczka:
Kluczowe rozróżnienie: modyfikacja szablonu (child theme, override w /themes/ lub /override/) zmienia wygląd i układ. Moduł albo wtyczka zmienia logikę sklepu – przelicza koszyk, wysyła dane na zewnątrz, nadaje uprawnienia. Po aktualizacji sklepu sypią się prawie zawsze overrides i dopiski w plikach szablonu; moduł aktualizujesz osobno i wiesz, co zmieniłeś.
Bywa jednak, że problem nie jest techniczny. Sklep „potrzebuje wtyczki do faktur”, a naprawdę faktury wystawia się ręcznie z pliku CSV, bo nikt nie ustalił, kto zatwierdza korekty. Wtedy wtyczka tylko przenosi bałagan w inne miejsce.
Decyzję build vs buy najłatwiej podjąć na pięciu liczbach, nie na wrażeniach. Poniższa tabela to zakres, w jakim te liczby zwykle się mieszczą dla sklepu na PrestaShop lub WooCommerce z obrotem do kilku milionów złotych rocznie.
| Kryterium | Gotowa wtyczka/moduł | Rozwiązanie na zamówienie |
|---|---|---|
| Koszt wejścia | 0–1500 zł rocznie (licencja) | stawka godzinowa × zakres, zwykle 80–200 h |
| Czas do uruchomienia | 1–3 dni | 3–10 tygodni |
| Ryzyko | brak wpływu na kod, zależność od dostawcy | zależne od wykonawcy i dokumentacji |
| Unikalność procesu | proces musi pasować do wtyczki | wtyczka pasuje do procesu |
| TCO w 3 lata | licencje + dopiski + obejścia ręczne | rozwój i utrzymanie, ale kod zostaje w firmie |
Praktyczne progi: 20–40 h to konfiguracja gotowego rozwiązania plus dopisanie brakującego elementu przez hooki. 80–200 h to pełny moduł z integracją, testami i dokumentacją – tyle zajmuje np. synchronizacja z ERP obejmująca stany, ceny i faktury. Między 40 a 80 h leży strefa szara: najczęściej własna wtyczka „klej”, która nie powiela funkcji kupionej wtyczki, tylko dokłada brakujące 20%.
Gotowiec zaczyna blokować rozwój, gdy: licencja rośnie od liczby zamówień, dostawca nie daje API ani hooków do podłączenia ERP, schemat danych jest narzucony na sztywno, brak wsparcia dla nowego PHP albo HPOS w WooCommerce, kod jest zaszyfrowany (ionCube) i nie da się zrobić eksportu przy odejściu.
Przykład: sklep B2B z 15 klientami hurtowymi i rabatem łańcuchowym (grupa + wolumen + termin płatności). Trzy kupione wtyczki obsługują po jednej osi, resztę księgowość łata ręcznymi kodami rabatowymi – 4 h pracy miesięcznie. Własna wtyczka to ok. 60 h i koniec łatanin. Podobne dylematy opisujemy przy okazji wdrożeń w okolicy, np. w tekście Niestandardowe moduły i wtyczki Józefów: organizacja pracy.
Pytanie kontrolne, które rozstrzyga większość sporów: czy ten proces daje przewagę konkurencyjną? Jeśli tak – buduj i nie licz, że znajdziesz gotowca. Jeśli to standard (płatności, kurierzy, faktury, newsletter) – kupuj.
W Biłgoraju i okolicznych gminach mówimy głównie o firmach zatrudniających 5–50 osób: sklepach internetowych, hurtowniach, zakładach produkcyjnych z własną sprzedażą wysyłkową. Nie ma tu działu IT, decyzje podejmuje właściciel albo osoba łącząca marketing z obsługą zamówień. To zmienia sposób pracy bardziej niż sama lokalizacja.
Sprawdzony model: jedno spotkanie na start (1–2 h), potem praca zdalna z krótkim, stałym rytmem – 30 min raz w tygodniu, zawsze o tej samej godzinie. Odbiór końcowy online z nagraniem albo na miejscu, jeśli trzeba pokazać pracownikom obsługę panelu. Dojazd wykonawcy spoza regionu na jedno spotkanie to zwykle pół dnia po obu stronach, więc opłaca się gruplować: ustalenia, dostępy do serwera i testy załatwić na jednym wyjeździe, a nie w trzech turach.
Bezpośredni kontakt z deweloperem skraca ustalenia realnie o dni. Pytanie „czy rabat może zależeć od terminu płatności” trafia wprost do osoby, która pisze kod. Gdy w łańcuchu jest handlowiec i project manager, jeden cykl pytanie–odpowiedź zajmuje 2–3 dni; bezpośrednio – kilka godzin. Zapisz to w umowie: kanał komunikacji, czas reakcji i kto zatwierdza zmiany zakresu.
Na co uważać przy wykonawcy spoza regionu:
Nie wybieraj po najniższej stawce. 30 zł/h przy 200 h daje 6000 zł, ale poprawki po kimś często kosztują drugie tyle. Poproś o dwie referencje z PrestaShop lub WooCommerce z ostatnich 12 miesięcy i sprawdź, czy te sklepy nadal działają. Szerszy opis tego samego procesu znajdziesz w artykule Niestandardowe moduły i wtyczki Zamość: jak to zorganizować.
Proces ma osiem etapów i każdy kończy się dokumentem. Bez tego dokumentu nie ma sensu iść dalej.
Kryteria akceptacji to lista 10–20 przypadków testowych z oczekiwanym wynikiem, spisana przed kodowaniem. Odbiór robimy na stagingu, przed produkcją: klient klika scenariusze i akceptuje mailowo. Na produkcję wchodzi dokładnie ten build, który przeszedł testy — bez drobnych poprawek na serwerze.
I zasada bez wyjątków: żadnego wdrożenia bez planu rollbacku. Kopia bazy i katalogu przed startem, nazwany plik kopii, osoba odpowiedzialna, kryterium wycofania (np. błąd 500 na koszyku) i czas reakcji 15 minut. Rollback trzeba przećwiczyć na stagingu, inaczej to teoria. Jak poukładać te etapy w praktyce, opisujemy przy okazji organizacji pracy nad modułami w Zamościu. System hooków w PrestaShop znajdziesz w dokumentacji dla deweloperów PrestaShop.
| Etap | Dokument | Typowy czas |
|---|---|---|
| Discovery | notatka z celem i użytkownikami | 2–4 h |
| Specyfikacja | lista funkcji i przypadków brzegowych | 4–10 h |
| Wycena | kosztorys godzinowy z rezerwą | 1–2 h |
| Prototyp | działający szkielet | 10–15 h |
| Testy na stagingu | lista 10–20 przypadków testowych | zależnie od zakresu |
| Wdrożenie | plan rollbacku i okno wdrożeniowe | 1–2 h |
| Dokumentacja | README i changelog | 2–4 h |
| Odbiór | protokół akceptacji | 1 h |
Ceny rozliczamy w godzinach, bo tylko godzina jest porównywalna między wykonawcami. Widełki zakresu:
Przykład rachunku: 30 h × 150–250 zł/h = 4500–7500 zł netto. Stawki, które widzimy na rynku, mieszczą się w 120–200 zł/h (młodszy zespół, mniejszy ośrodek) i 200–350 zł/h (senior lub agencja z umową i SLA).
Stała cena czy godziny? Stała cena zawiera ukryty bufor ryzyka, zwykle 20–40%, więc przy mglistym zakresie wypada drożej. Bywa też odwrotnie: wykonawca szacuje nisko, a potem ucina zakres, bo tego nie było w wycenie. Wycena godzinowa z tygodniowym raportem (Toggl, Redmine) i limitem, po którym potrzebna jest osobna zgoda, jest bezpieczniejsza dla obu stron — klient widzi, gdzie idą pieniądze, i może w każdej chwili zatrzymać prace.
Co podnosi koszt: API bez sandboxa, limity zapytań i brak dokumentacji (do 30% więcej godzin), rozbudowany panel admina (każdy filtr, eksport i uprawnienie to osobna praca), migracja danych (mapowanie pól, duplikaty, relacje po ID, historia zamówień), wielojęzyczność, wymagania B2B (ceny grupowe, limity kredytu), zakres testów oraz SLA z czasem reakcji.
Najczęstszy błąd przy porównywaniu ofert: patrzenie na cenę całkowitą bez pytania o liczbę godzin i zakres. Różnica 2000 zł przy 40 h różnicy w szacunku to nie oszczędność. Podobne zasady porządkujemy w tekście o porządku pracy przy wtyczkach we Frampolu.
| Zakres | Godziny | Koszt przy 150 zł/h | Koszt przy 250 zł/h |
|---|---|---|---|
| Prosty moduł (pole, eksport CSV, widget) | 15–40 h | 2250–6000 zł | 3750–10 000 zł |
| Średni (panel admin, filtry, synchronizacja) | 40–120 h | 6000–18 000 zł | 10 000–30 000 zł |
| Złożona integracja (ERP/API, B2B, migracja) | 120–300 h | 18 000–45 000 zł | 30 000–75 000 zł |
Code review — cztery pytania. Czy moduł nadpisuje pliki core (katalog /override w PrestaShop, edycja plików motywu nadrzędnego lub obcej wtyczki w WordPress)? Nadpisanie oznacza, że najbliższa aktualizacja coś skasuje. Poprawnie używa się akcji i filtrów (add_action, add_filter) oraz własnych klas. Czy używa publicznych hooków zamiast modyfikowania plików? Czy po odinstalowaniu sprząta po sobie tabele, opcje i zadania cron? Czy kod jest w repozytorium z historią zmian, a nie wrzucany FTP-em?
Bezpieczeństwo. Nonce lub token przy każdym formularzu i akcji (wp_nonce_field, check_admin_referer, token w PrestaShop), sprawdzenie uprawnień (current_user_can) nie tylko przy wejściu w menu, escaping na wyjściu (esc_html, esc_attr, esc_url), walidacja i rzutowanie danych wejściowych, zapytania przez $wpdb->prepare albo Db::getInstance() z rzutowaniem na (int). To minimum, nie „dobre praktyki na potem”.
Wydajność. Policz zapytania na stronę: Query Monitor w WordPress, profilowanie w panelu PrestaShop. Moduł dobijający listę produktów 200 zapytaniami to najczęstsza przyczyna zejścia z 1 s na 4 s. Sprawdź indeksy, jeśli filtrujecie po kolumnie bez indeksu, cache (transients, Object Cache, cache fragmentów) oraz to, czy ciężka praca idzie w cronie i kolejce (Action Scheduler), a nie w żądaniu użytkownika.
Kompatybilność. PHP 7.4/8.1/8.2, wersje PrestaShop i WooCommerce oraz HPOS. Wtyczka, która nie deklaruje zgodności z HPOS, potrafi czytać zamówienia z wp_posts i po przełączeniu magazynu zamówień pokazać pustą listę. REST API warto sprawdzić testami kontraktowymi. Przydatne materiały: WordPress Developer Resources. Sposób oceny kodu opisujemy też przy porządku w kodzie modułów w Szczebrzeszynie.
| Obszar | Co sprawdzić | Czym |
|---|---|---|
| Struktura | brak nadpisywania core i obcych wtyczek, hooki zamiast edycji plików | code review, diff plików |
| Bezpieczeństwo | nonce/token, uprawnienia, escaping, walidacja, prepared statements | przegląd kodu, skaner |
| Wydajność | liczba zapytań, indeksy, cache, cron i kolejki | Query Monitor, profilowanie |
| Kompatybilność | wersje PHP, PrestaShop/WooCommerce, HPOS, REST API | staging z docelową wersją |
Pułapki w projektach niestandardowych nie są egzotyczne — powtarzają się w niemal każdej rozmowie. Poniżej pięć, które kosztują najwięcej, wraz z prostym testem do wykonania jeszcze przed podpisaniem umowy.
1. Brak przekazania kodu, dokumentacji i praw. Do umowy wpisz trzy rzeczy: repozytorium Git przekazane na Twoje konto (GitHub, GitLab, Bitbucket) najpóźniej w dniu odbioru, przeniesienie majątkowych praw autorskich oraz dokumentację w repozytorium — plik README z instalacją, listę zależności, opis hooków i tabel w bazie. Zdanie „kod zostaje u nas, ale możesz z niego bezterminowo korzystać” nie jest przekazaniem praw. Test: poproś o zrzut repozytorium przed podpisaniem. Jeśli wykonawca nie potrafi go pokazać teraz, nie będzie chciał oddać go po wdrożeniu.
2. Vendor lock-in i uzależnienie od jednej osoby. Zapytaj wprost, ile osób w zespole potrafi przejąć ten kod oraz czy moduł korzysta ze standardowych mechanizmów platformy (hooki, override, REST API), czy z autorskich rozwiązań znanych tylko autorowi. Drugie pytanie: co się dzieje, jeśli ta osoba zniknie na trzy tygodnie.
3. Brak stagingu, backupu i planu rollbacku. Wymagaj środowiska testowego na subdomenie, kopii bazy i plików przed każdym wdrożeniem oraz procedury cofnięcia: przywrócenie snapshotu plus skrypt wycofujący zmiany w bazie. Bez tego pierwszy błąd zobaczysz na produkcji, w godzinach szczytu sprzedaży.
4. Zbyt szeroki zakres i brak kryteriów akceptacji. „Moduł do obsługi zamówień” to nie zakres. Rozpisz 10–20 punktów, każdy z mierzalnym testem, np. „import 500 pozycji z CSV w mniej niż 30 sekund”. Sposób ułożenia tych ustaleń opisujemy szerzej przy okazji organizacji pracy przy niestandardowych modułach i wtyczkach Zamość.
5. RODO i dane osobowe w integracjach. Jeśli moduł wysyła dane klientów do zewnętrznego API, ustal: jakie pola, w jakim celu, jak długo są przechowywane, czy jest umowa powierzenia przetwarzania i wpis w rejestrze czynności. Sprawdź też, czy komunikacja idzie po HTTPS, a webhooki są podpisywane — podstawy protokołu znajdziesz w dokumentacji MDN dotyczącej HTTP. Brak tej rozmowy to nie tylko ryzyko kary, ale i problem przy pierwszej reklamacji klienta.
| Pułapka | Sygnał ostrzegawczy | Zapis w umowie |
|---|---|---|
| Brak kodu i praw | „Kod zostaje u nas, dostajesz licencję” | Repozytorium na konto klienta + przeniesienie praw autorskich |
| Vendor lock-in | Jedna osoba zna moduł, autorskie rozwiązania zamiast hooków | Lista osób zdolnych przejąć projekt, wymóg standardowych API |
| Brak stagingu i rollbacku | „Testujemy od razu na produkcji” | Staging, backup przed wdrożeniem, procedura cofnięcia |
| Zbyt szeroki zakres | Opis funkcji w jednym zdaniu | 10–20 punktów z mierzalnymi kryteriami akceptacji |
| RODO w integracji | Brak informacji, jakie pola idą do API | Umowa powierzenia, zakres danych, okres retencji |
Wdrożenie to połowa drogi. Druga połowa to umowa serwisowa, która przesądza, jak szybko wrócisz do sprzedaży po awarii. Poniżej punkty, które warto wpisać do SLA.
Czas reakcji i czas naprawy. To dwie różne liczby i często są mylone. Czas reakcji to potwierdzenie zgłoszenia: np. 4 godziny w dni robocze, 24 godziny poza nimi. Czas naprawy liczony od potwierdzenia: dla błędu blokującego sprzedaż 8 godzin, dla błędu istotnego 3 dni robocze, dla kosmetycznego — do najbliższego okna serwisowego. Zapisz, co uruchamia priorytet krytyczny: brak dodania do koszyka, brak płatności, niedziałający webhook zamówienia.
Godziny serwisowe i koszt godzin dodatkowych. Standard to 9:00–17:00 od poniedziałku do piątku, z klauzulą, ile kosztuje wyjście poza te godziny. Stawka godzinowa w Polsce to najczęściej 120–300 zł netto, zależnie od technologii i doświadczenia. Pula godzin w pakiecie miesięcznym (5 albo 10) bywa o 20–30 proc. tańsza niż rozliczenie po zdarzeniu, ale przepisuj ją na kolejny miesiąc tylko wtedy, gdy wykonawca faktycznie ją wykorzystuje.
Aktualizacje pod nowe wersje platformy i PHP. Ustal, kto testuje zgodność z nowymi wydaniami PrestaShop, WooCommerce i PHP, na ile dni przed planowaną aktualizacją serwera oraz co się dzieje, gdy aktualizacja łamie moduł. Jeśli chcesz samodzielnie ocenić, czy wykonawca pracuje zgodnie z zaleceniami platformy, pomocna jest dokumentacja deweloperska PrestaShop.
Monitoring, logi, kopie zapasowe, testy regresji. Kopia bazy codziennie, pliki tygodniowo, retencja minimum 30 dni. Logi błędów modułu w jednym miejscu i alert, gdy liczba błędów przekroczy ustalony próg. Do tego lista scenariuszy testowych: dodanie do koszyka, płatność, e-mail potwierdzający, zwrot. Uruchamiana przed każdym wdrożeniem, nie po.
Plan rozwoju. Zdefiniuj kwartalną pulę na drobne zmiany i kolejność priorytetów: awaria, obowiązek prawny, poprawa konwersji, kosmetyka. Podobny zestaw ustaleń opisujemy w tekście o organizacji pracy przy niestandardowych modułach i wtyczkach Frampol.
| Parametr SLA | Typowa wartość | Po co to ustalać |
|---|---|---|
| Czas reakcji | 4 h w dni robocze, 24 h poza | Wiesz, kiedy dostaniesz potwierdzenie i plan naprawy |
| Czas naprawy (krytyczny) | 8 h od potwierdzenia | Sklep wraca do sprzedaży w tym samym dniu |
| Godziny serwisowe | 9:00–17:00, pon.–pt. | Brak niedomówień przy zgłoszeniu o 20:00 w piątek |
| Stawka godzin dodatkowych | 120–300 zł netto | Znasz koszt przed zleceniem, nie po fakturze |
| Retencja kopii zapasowych | min. 30 dni | Masz z czego odtworzyć dane po błędnym wdrożeniu |
Ta lista mieści się na jednej stronie. Jeśli dostawca nie potrafi potwierdzić któregoś punktu na piśmie, traktuj to jako sygnał ostrzegawczy.
Krok 1: sprawdź, czy funkcja naprawdę wymaga customu. Zanim zamówisz kod, przejrzyj katalogi gotowych rozwiązań: PrestaShop Addons, WooCommerce Marketplace (opisany w dokumentacji WooCommerce) oraz repozytorium wtyczek na WordPress.org. Gotowiec kosztuje zwykle 300–800 zł jednorazowo. Custom startuje realnie od kilku tysięcy złotych i rośnie z każdym nietypowym warunkiem. Niestandardowy moduł ma sens, gdy logika jest specyficzna dla Twojego procesu (np. wycena zależna od wagi i strefy dostawy), potrzebna jest integracja z systemem, którego żaden gotowiec nie obsługuje, albo wymagania wydajnościowe przekraczają to, co oferuje wtyczka z marketplace.
Krok 2: zadaj dostawcy pytania i zbierz odpowiedzi na piśmie.
Krok 3: porównaj z podobnym projektem. Zobacz, jak te ustalenia wyglądają w praktyce na przykładzie organizacji pracy przy niestandardowych modułach i wtyczkach Zwierzyniec. Jeśli zależy Ci głównie na czytelności kodu i przekazaniu go innemu zespołowi, pomocny będzie też materiał o porządku w kodzie modułów niestandardowych w Szczebrzeszynie.
Krok 4: audyt techniczny przed startem. Jeśli masz już sklep i chcesz dołożyć moduł, zamów audyt: wersje PHP, platformy i wtyczek, stan kopii zapasowych, rozmiar bazy, wydajność. To zwykle kilka godzin pracy i najtańszy sposób uniknięcia przepisywania modułu po fakcie. Napisz do nas — sprawdzimy, czy Twoja funkcja wymaga customu i co trzeba przygotować przed startem.
Brak przekazania kodu, dokumentacji i praw autorskich.
Jak wykryć: Przed podpisaniem umowy sprawdź, czy jest zapis o przekazaniu repozytorium i licencji po opłaceniu faktury.
Jak naprawić: Dopisz do umowy klauzulę: przeniesienie praw majątkowych albo licencja wieczysta, dostęp do repozytorium Git, dokumentacja i instrukcja wdrożenia.
Uzależnienie od jednej osoby, która jako jedyna zna kod.
Jak wykryć: Zapytaj wprost, ile osób w zespole może przejąć projekt i czy istnieje repozytorium oraz dokumentacja.
Jak naprawić: Wymagaj repozytorium, pliku README, komentarzy w kodzie i trzymania się standardów kodowania PrestaShop oraz WordPress.
Wdrożenie bez stagingu, backupu i planu rollbacku.
Jak wykryć: Zapytaj, gdzie odbędą się testy i jak wygląda powrót do poprzedniej wersji, jeśli coś pójdzie nie tak.
Jak naprawić: Staging z kopią bazy, backup plików i bazy przed wdrożeniem oraz plan rollbacku opisany punkt po punkcie.
Zbyt szeroki zakres i brak kryteriów akceptacji.
Jak wykryć: Sprawdź, czy w umowie jest lista funkcji i jednoznaczne warunki odbioru dla każdej z nich.
Jak naprawić: Podziel projekt na etapy po 2-4 tygodnie, każdy z osobnym odbiorem i zgodą na przejście do kolejnego.
Ignorowanie RODO w integracjach z zewnętrznymi systemami.
Jak wykryć: Sprawdź, jakie dane osobowe wychodzą poza sklep i gdzie są przechowywane logi.
Jak naprawić: Umowa powierzenia przetwarzania, minimalizacja zakresu danych, określony czas retencji logów i szyfrowanie połączeń.
Brak budżetu na testy i utrzymanie po wdrożeniu.
Jak wykryć: Zapytaj, ile godzin w wycenie przeznaczono na testy i co się dzieje po aktualizacji wersji PrestaShop lub WooCommerce.
Jak naprawić: Dolicz 15-25 procent budżetu na testy oraz osobny pakiet utrzymaniowy z określonym czasem reakcji i liczbą godzin miesięcznie.
Niestandardowy moduł to projekt, a nie zakup z katalogu, dlatego wygrywa ten, kto ma uporządkowany proces: specyfikację, wycenę godzinową z limitem, staging, kryteria akceptacji i plan rollbacku. Praca zdalna z Biłgorajem i okolicami nie jest przeszkodą, o ile znacie stawkę, terminy i wiecie, do kogo dzwonić, gdy coś nie działa. Przed podpisaniem umowy sprawdźcie dwie rzeczy: czy dostajecie kod na własność i ile będzie kosztowało utrzymanie w skali roku.
Tak. Większość projektów z Biłgoraja i okolic prowadzimy zdalnie, z wideorozmowami na starcie, przy prototypie i przy odbiorze. Dojazd na miejsce ma sens w dwóch, trzech momentach: warsztat zbierający wymagania, pokaz działającego prototypu i szkolenie z obsługi. Reszta to repozytorium, staging i ustalone terminy. Podobny schemat organizacji opisaliśmy dla Zamościa: Niestandardowe moduły i wtyczki Zamość: jak to zorganizować.
Prosty moduł to zwykle 15-40 godzin pracy, czyli przy równoległym działaniu 1-2 tygodnie. Średni projekt to 40-120 godzin i zwykle 3-8 tygodni, a złożona integracja 120-300 godzin, czyli 2-4 miesiące. Terminy zależą przede wszystkim od tego, jak szybko po Waszej stronie zapadają decyzje i czy dane z systemów zewnętrznych są dostępne.
Nie na pierwsze spotkanie, ale bez specyfikacji nie ma wiążącej wyceny. Wystarczy opis procesu krok po kroku i przykłady z życia, na przykład jak dziś wygląda zamówienie B2B od zapytania do faktury. Na tej podstawie przygotowujemy zakres, a dopiero potem podajemy liczbę godzin. Wycena bez zakresu to zawsze strzał w ciemno.
Jest odwrotnie: przy stałej cenie wykonawca ma motywację, żeby przy nieprzewidzianym problemie ograniczyć zakres albo ciąć testy. Przy rozliczeniu godzinowym pracujecie na jawnym rejestrze czasu i znanej stawce. Zabezpieczeniem jest limit, na przykład po przekroczeniu 10 procent budżetu dalsze prace wymagają Waszej pisemnej akceptacji.
Cztery rzeczy: czy rozmawiacie bezpośrednio z deweloperem, a nie tylko z handlowcem; czy kod trafia do Waszego repozytorium; czy wykonawca pokaże referencje z podobnych wdrożeń w PrestaShop lub WooCommerce; i czy umowa zawiera kryteria akceptacji oraz plan rollbacku. Lokalizacja ma znaczenie przy warsztatach i szkoleniach, nie przy codziennej pracy nad kodem.
Wy. W umowie powinien być zapis o przekazaniu repozytorium i praw majątkowych albo o licencji wieczystej, obejmującej również biblioteki zewnętrzne. Jeśli wykonawca nie chce tego zapisać, traktujcie to jako sygnał ostrzegawczy. Zmiana dostawcy w połowie projektu jest zwykle droższa niż rozpoczęcie go od nowa u kogoś innego.
Trzy elementy: czas reakcji na zgłoszenie, na przykład 1 dzień roboczy, miesięczny budżet godzin, na przykład 2-8 godzin, oraz zakres prac. Warto rozdzielić błędy, naprawiane w ramach gwarancji, od nowych funkcji, rozliczanych godzinowo. Dopiszcie też zobowiązanie do utrzymania kompatybilności z nowymi wersjami platformy i PHP.
Jeśli chcesz sprawdzić, czy Twój pomysł to 20 godzin pracy czy 200, opisz proces w kilku zdaniach — wrócimy z zakresem i widełkami. Powiemy też wprost, kiedy taniej wyjdzie gotowa wtyczka, a kiedy nie rozwiąże problemu.