Koszt niestandardowego modułu do PrestaShop lub wtyczki do WooCommerce zależy od dwóch rzeczy: liczby godzin i tego, jak dobrze zorganizujesz projekt po swojej stronie. Ta część artykułu jest o tej drugiej części, bo to ona najczęściej decyduje, czy zapłacisz tyle, ile było w ofercie. Podpowiadamy, jak przygotować brief, jakie pytania zadać wykonawcy i co ustalić w umowie, żeby nie dopłacać za coś, co dało się ustalić w pierwszym tygodniu. Konkretne widełki godzinowe i kwotowe znajdziesz w części o wycenie.
Zacznijmy od liczb, żebyś nie musiał ich szukać w dalszej części tekstu.
Przy stawce 140–250 zł/h netto daje to od około 2 800 zł za najprostsze rozszerzenie do 30 000 zł i więcej przy rozbudowanej integracji. Kwoty są netto, bez licencji i bez kosztów serwera.
Wzór, którym powinieneś liczyć każdą ofertę, wygląda tak:
koszt = (liczba godzin × stawka) + testy + wdrożenie
Testy i wdrożenie to zwykle dodatkowe 15–30% godzin deweloperskich. Jeśli wykonawca wrzuca je „w cenę”, to znaczy, że albo je policzył w środku, albo ich nie planuje — a drugi scenariusz kończy się poprawkami po odbiorze, za które zapłacisz osobno. Wdrożenie to nie „wgranie pliku na FTP”, tylko konfiguracja na produkcji, sprawdzenie zamówień testowych, maili i płatności.
I najważniejsze zastrzeżenie: wycena ryczałtowa podana bez estymacji godzin jest ryzykiem dla obu stron. Dla Ciebie — bo nie wiesz, za co płacisz i nie masz punktu odniesienia przy zmianach zakresu. Dla wykonawcy — bo każdą nieprzewidzianą rzecz musi ukryć w buforze, który i tak zapłacisz. Zawsze proś o rozbicie na pozycje i liczbę godzin, nawet jeśli rozliczasz się ryczałtem. Jak przygotować się do rozmowy o tym zakresie, opisujemy w materiale o [organizacji współpracy z wykonawcą modułów](https://dropdigital.pl/niestandardowe-moduly-i-wtyczki-zamosc-organizacja).
| Typ rozszerzenia | Godziny | Kwota przy 140 zł/h netto | Kwota przy 250 zł/h netto |
|---|---|---|---|
| Prosty moduł / wtyczka | 20–40 h | 2 800 – 5 600 zł | 5 000 – 10 000 zł |
| Średni zakres (panel, logika, eksport) | 40–120 h | 5 600 – 16 800 zł | 10 000 – 30 000 zł |
| Integracja ERP / płatności / magazyn | 80–250 h | 11 200 – 35 000 zł | 20 000 – 62 500 zł |
„Moduł” i „wtyczka” robią dla klienta to samo, ale nie są tym samym z punktu widzenia pracy. Problem pojawia się, gdy zestawiasz ofertę na wtyczkę do WooCommerce z ofertą na moduł do PrestaShop — zakresy są różne i ceny przestają być porównywalne.
hookDisplayHeader, hookActionCartSave, hookDisplayAdminProductsExtra, a logikę trzymasz w klasach dziedziczących po Module i ObjectModel. W nowszych wersjach część back office działa w Symfony, część w starym podejściu (legacy). To rozróżnienie bezpośrednio przekłada się na godziny.add_action(), add_filter(), własne endpointy REST. Jeśli sklep korzysta z HPOS (nowego sposobu przechowywania zamówień), wtyczka musi zadeklarować kompatybilność przez FeaturesUtil::declare_compatibility('custom_order_tables', __FILE__). Bez tego zamówienia w panelu potrafią się nie wyświetlać.Dlaczego wtyczka bywa tańsza w prostych przypadkach? Bo często wystarczy filtr zmieniający jedno pole — 10–15 godzin i gotowe. PrestaShop w analogicznym scenariuszu wymaga nadpisania szablonu, kontrolera albo metody z core (override), a to 25–40 godzin, bo trzeba pilnować, żeby aktualizacja sklepu tego nie zjadła.
I tu najważniejsza konsekwencja dla kosztu utrzymania: każdy override pliku core to potencjalny konflikt przy aktualizacji. Moduł oparty wyłącznie na hookach aktualizuje się zwykle bez ingerencji.
Zastanów się też, czy potrzebujesz modułu administracyjnego (nowa zakładka w back office, konfiguracja, raport), czy wystarczy widget front-endowy. Pierwszy to zwykle 2–3 razy więcej pracy. Punkt odniesienia dla obu platform znajdziesz w [dokumentacji dla deweloperów PrestaShop](https://devdocs.prestashop-project.org/).
Cena nie jest przypadkowa. Te osiem rzeczy realnie przesuwa wycenę w górę albo w dół — i na większość z nich masz wpływ jeszcze przed podpisaniem umowy.
Jeśli pracujesz z zespołem rozproszonym albo masz dostawców z kilku miast, sposób prowadzenia projektu opisujemy też przy okazji [niestandardowych wtyczek Hrubieszów – organizacja pracy](https://dropdigital.pl/niestandardowe-moduly-i-wtyczki-hrubieszow-organizacja).
| Czynnik | Przykład | Typowy wpływ na godziny |
|---|---|---|
| Integracje zewnętrzne | InPost + Przelewy24 + ERP | +40 do +100 h |
| Logika biznesowa | rabaty progowe, cenniki B2B | +10 do +50 h |
| Widoki w panelu admina | 3 ekrany konfiguracji + raport | +15 do +30 h |
| Brak dokumentacji API | reverse engineering | +20% do +50% zakresu |
| Gotowość klienta | brief i jedna osoba decyzyjna | −10% do −25% zakresu |
Zanim porównasz oferty, ustal jedną liczbę: ile godzin realnie pochłonie zadanie. Poniższe poziomy to typowy rozrzut, jaki zobaczysz u wykonawców w 2025 roku przy sklepach na PrestaShop i WooCommerce. Godziny mnożysz przez stawkę z oferty — przy 120 zł/h netto poziom 2 to 4 800–9 600 zł. Punkt odniesienia do rozmowy o stawkach znajdziesz też w materiale o tym, jak wygląda wycena niestandardowych modułów w Zamościu i co wpływa na jej wysokość.
Rozbicie przeciętnego, 60-godzinnego modułu na pozycje wygląda tak:
Suma: 60 h. Jeżeli oferta nie zawiera takiego rozbicia, nie masz czego porównywać — zostaje goła kwota, która przy pierwszej zmianie zakresu rośnie bez negocjacji.
Najtańsza oferta bez estymacji godzin prawie zawsze kończy się dopłatami. „3 000 zł za moduł” nie mówi, czy w środku jest analiza, czy samo kodowanie. Pierwsza drobna zmiana — dodatkowe pole w mailu potwierdzającym, inne zaokrąglenie kwoty dostawy — potrafi zjeść kolejne 8 h, bo nikt nie zapisał zakresu. Warto zajrzeć do dokumentacji dla deweloperów PrestaShop i wiedzieć, o jakie mechanizmy pytasz wykonawcę: hooki, kontrolery administracyjne, ObjectModel, tabele w bazie. Wtedy pytanie „dlaczego 70 h, a nie 40?” ma sens.
| Poziom | Przykład funkcji | Godziny | Co podnosi górną granicę |
|---|---|---|---|
| 1 | Prosty moduł funkcjonalny: kalkulator kosztu dostawy, dodatkowe pole w koszyku, walidacja NIP | 20–40 h | Wiele stref wysyłki, waluty, niestandardowe reguły zaokrągleń |
| 2 | Moduł z panelem administracyjnym: konfigurator, własne pola, eksport danych do CSV | 40–80 h | Liczba opcji w panelu, wielojęzyczność, uprawnienia pracowników |
| 3 | Integracja z kurierem lub płatnościami (API przewoźnika, bramka płatnicza) | 60–120 h | Jakość dokumentacji API, dostępność sandboxa, obsługa błędów i zwrotów |
| 4 | Integracja z ERP (Subiekt, Comarch, WAPRO) i synchronizacja stanów, cen, zamówień | 120–250 h | Liczba mapowanych pól, tryb pracy (na żywo vs. cron), historia do przepisania |
Cena zakupu to najgorszy możliwy punkt odniesienia. Licencja 300–1 500 zł/rok przez 3 lata daje 900–4 500 zł — i to dopiero początek rachunku. Do tego dochodzą płatne dodatki, odnowienie wsparcia i czas programisty na każdą aktualizację, która coś zepsuje.
Własny moduł zamknięty w 30 h to przy 120 zł/h około 3 600 zł jednorazowo, ale zostaje koszt utrzymania: poprawki po aktualizacji PrestaShop 8.x albo WooCommerce, dostosowanie do nowej wersji PHP, zmiany w logice po Twojej stronie. Różnica polega na tym, że w drugim przypadku ty decydujesz, kiedy ta praca jest potrzebna.
Główne ryzyko przy gotowej wtyczce to porzucenie projektu przez autora. Sprawdzasz to w pięć minut: data ostatniej aktualizacji, czy są wpisy o kompatybilności z bieżącą wersją silnika, czy autor odpowiada na zgłoszenia w dziale wsparcia, ile jest aktywnych instalacji. Jeśli ostatnia aktualizacja była dwa lata temu, a ty planujesz aktualizację WooCommerce z obsługą HPOS — licz się z tym, że nikt tego nie naprawi.
Gotowa wtyczka wystarcza, gdy problem jest standardowy (faktury, kurier, podstawowe pola w koszyku), ekosystem jest duży, a autor aktywnie rozwija produkt. Własny moduł opłaca się, gdy proces jest specyficzny dla Twojej firmy — własne progi marżowe, nietypowa kolejka zamówień — gdy dane są wrażliwe i nie chcesz ich przepuszczać przez zewnętrzny serwis, albo gdy integrujesz sklep z wewnętrznym systemem, którego nikt nie zna poza Twoim zespołem.
Dług techniczny objawia się później: dwie wtyczki przechwytują ten sam hook, jedna nadpisuje drugą przy aktualizacji, do koszyka dochodzą zapytania do bazy w pętli i strona produktu zaczyna ładować się 2 sekundy dłużej. To koszt, którego nie widać w cenie zakupu.
| Kryterium | Gotowa wtyczka | Własny moduł |
|---|---|---|
| Koszt w 3 lata | 900–4 500 zł licencji + płatne dodatki + czas na konflikty | Development 20–80 h + utrzymanie przy aktualizacjach |
| Kontrola nad kodem | Brak — poprawki tylko przez autora | Pełna — zleceniodawca ma źródła |
| Główne ryzyko | Porzucenie wtyczki, brak zgodności z nową wersją silnika | Konieczność zaplanowania budżetu na utrzymanie |
| Kiedy wybór ma sens | Standardowy problem, duży ekosystem, aktywny rozwój | Proces specyficzny, dane wrażliwe, integracja z systemem wewnętrznym |
Dobra wycena nie jest zgadywaniem. To pięć kroków, z których każdy ma konkretny efekt i termin. Warto wiedzieć, czego oczekiwać, bo dzięki temu łatwiej ocenić, czy wykonawca w ogóle zrozumiał zadanie — pokazuje to też artykuł o organizacji pracy przy niestandardowych modułach w Chełmie, gdzie opisujemy podobny przebieg z perspektywy firmy zamawiającej.
Krok 1: rozmowa wstępna (30–60 min). Cel: ustalenie, co ma się dziać w sklepie po wdrożeniu. Potrzebne są scenariusze typu „klient z województwa lubelskiego zamawia 3 sztuki, system nalicza dostawę 14,99 zł”. Bez przykładów rozmowa schodzi na funkcje, nie na proces.
Krok 2: analiza sklepu i dostępnych API (1–3 dni roboczych). Wykonawca sprawdza wersję silnika, listę wtyczek lub modułów, motyw, czy API przewoźnika albo ERP ma dokumentację i sandbox. Na tym etapie wypadają założenia, które brzmią prosto, a proste nie są.
Krok 3: estymacja godzinowa z rozbiciem na etapy i ryzyka (1–3 dni). Dostajesz tabelę: analiza, development, testy, wdrożenie, dokumentacja, wsparcie — z liczbami i listą ryzyk, np. „brak dostępu do środowiska testowego ERP wydłuża wdrożenie o 8–16 h”.
Krok 4: płatne discovery lub proof of concept — tylko przy dużych integracjach z ERP. Kwota jest ustalana przed startem, a efektem jest działający prototyp wymiany danych, nie dokument.
Krok 5: oferta z harmonogramem, kamieniami milowymi i warunkami płatności (typowo 30/40/30).
Całość trwa od 2 dni przy prostym module do 2 tygodni przy integracji z ERP. Co przygotować: opis procesu krok po kroku, próbki danych (eksport CSV z Subiekta, przykładowy XML z API), dostępy testowe oraz osobę, która podejmuje decyzje i jest dostępna.
| Krok | Co się dzieje | Czas | Co dostajesz |
|---|---|---|---|
| 1. Rozmowa wstępna | Cele biznesowe, przykładowe scenariusze | 30–60 min | Ustalony zakres rozmowy |
| 2. Analiza | Wersja sklepu, wtyczki, motyw, dostępne API i sandbox | 1–3 dni robocze | Lista ograniczeń i założeń |
| 3. Estymacja | Rozbicie na etapy + ryzyka | 1–3 dni | Tabela godzin z rezerwą |
| 4. Discovery / PoC | Tylko duże integracje, np. ERP | zwykle 1–2 tygodnie | Działający prototyp wymiany danych |
| 5. Oferta | Harmonogram, kamienie milowe, płatności | 1–2 dni | Dokument z zakresem i wyłączeniami |
Wycena modułu to jedno. Drugie to wydatki, które pojawiają się po odbiorze i których nie ma w żadnym cenniku na stronie. Poniżej sześć pozycji do wpisania w budżet jeszcze przed startem prac.
Aktualizacje PHP i platformy. PrestaShop i WooCommerce podnoszą minimalne wymagania PHP co kilka lat. Moduł pisany pod PHP 7.4 na PHP 8.2 potrafi sypać błędami deprecated, a część funkcji przestaje działać. Dla prostego modułu to 4-12 godzin rocznie, dla integracji z magazynem 20-40 godzin. Zmiany w API modułów PrestaShop opisuje dokumentacja dla deweloperów PrestaShop.
Środowisko staging. Kto je utrzymuje i kto płaci za serwer? Bez stagingu każda poprawka wchodzi na produkcję i testują ją klienci. W praktyce: subdomena staging.twojadomena.pl, osobna baza danych, wyłączone indeksowanie (noindex + wpis w robots.txt), cron zrzucający kopię bazy raz na dobę. To 1-2 godziny pracy miesięcznie plus koszt serwera.
Backup, monitoring i VPS. Moduł synchronizujący stany magazynowe co 5 minut albo generujący raporty PDF dokłada obciążenie CPU i dysku. Serwer, który obsługiwał 20 wizyt na minutę, może przestać wystarczać. Dochodzi wyższy plan VPS, monitoring uptime, kolejki zadań i czasu odpowiedzi API.
Poprawki po wdrożeniu. Standard to 30 dni na defekty w cenie. Wszystko, czego nie było w briefie, jest nowym zleceniem, nawet jeśli brzmi jak drobiazg. W umowie zapisz, ile godzin poprawek masz w cenie i jaka stawka obowiązuje powyżej tego limitu.
Przekazanie projektu. Bez repozytorium i dokumentacji kolejny wykonawca wyceni odtworzenie, nie rozwój. 50-100% pierwotnego kosztu to realny scenariusz, nie straszenie.
SLA i czas reakcji. Czas reakcji to nie czas naprawy. Ustal oba, godziny pracy (9-17 czy 24/7) i kanał zgłoszeń. Bez tego opieka techniczna bywa obietnicą bez pokrycia.
Godziny i stawki rozbijamy w części o cenie i organizacji niestandardowych modułów w Zamościu.
| Ukryty koszt | Kiedy się pojawia | Jak go ograniczyć |
|---|---|---|
| Aktualizacja PHP / platformy | Raz na 1-3 lata, przy podnoszeniu wersji | Zapis w umowie: kto aktualizuje moduł i w jakim terminie |
| Staging | Od pierwszego wdrożenia | Ustalone z góry: kto płaci za serwer i kto robi kopie bazy |
| Backup i monitoring | Po wejściu modułu na produkcję | Backup poza serwerem, alerty na kolejkę zadań i czas API |
| Poprawki po odbiorze | Pierwsze 30 dni i później | 30 dni na defekty w cenie, nowe funkcje jako osobne zlecenie |
| Przekazanie projektu | Przy zmianie wykonawcy | Repozytorium i dokumentacja u zamawiającego od pierwszego commita |
| SLA | Pierwsza awaria | Czas reakcji i naprawy w godzinach, kanał zgłoszeń, godziny pracy |
Umowa podpisana w pośpiechu kosztuje więcej niż sam moduł. Te pytania zadaj przed podpisaniem, a odpowiedzi wpisz do umowy, nie do maila.
Przed rozmową przygotuj brief ze scenariuszami użytkownika i listą przypadków brzegowych. Sposób opisujemy w tekście o organizacji pracy nad niestandardowym modułem dla firmy.
Lokalny wykonawca nie jest tańszy z definicji. Ma za to przewagi, które widać dopiero przy drugim i trzecim zleceniu.
Warsztat na miejscu. Przy zbieraniu wymagań 2-3 godziny przy jednym stole w Zamościu albo Lublinie robią więcej niż trzy telekonferencje. Można na żywo pokazać, jak działa magazyn, kto klika co w panelu i co się dzieje, gdy w Subiekcie zmieni się stan towaru. Wymagania spisane przy takim warsztacie rzadziej wracają jako płatna zmiana zakresu.
Polskie integracje. InPost (ShipX API, paczkomaty), DPD, DHL, Subiekt GT i nexo, Comarch ERP Optima, Przelewy24, e-faktury i KSeF. Te systemy mają swoje kwiatki: brakująca stawka VAT w kartotece towaru, limity zapytań do API, kolejność zdarzeń przy zmianie statusu zamówienia. Wykonawca, który mierzył się z tym kilka razy, nie odkrywa tych problemów na twoim budżecie.
Bez pośredników. Rozmawiasz z osobą, która pisze kod, a nie z handlowcem przekazującym wymagania dalej. Mniej tłumaczenia, mniej nieporozumień, szybciej domykane decyzje. Jeśli w projekcie pojawia się podwykonawca, powinieneś wiedzieć o tym przed podpisaniem umowy.
Rozliczenie i język. Faktura w PLN, bez różnic kursowych i przewalutowań, komunikacja po polsku również w sprawach prawnych i RODO.
Oferta, którą da się porównać. Wycena oparta na liczbie godzin i etapach jest zestawialna z ofertą z Warszawy czy Krakowa. Uczciwie: przy wąskiej, nietypowej integracji ERP praca zdalna z innego miasta bywa tańsza. Lokalność wygrywa wtedy, gdy liczy się dostęp do ludzi i zrozumienie twojego procesu.
Jak przygotować taki projekt od strony zamawiającego, opisujemy w materiałach o organizacji pracy nad modułami dla firm z Chełma i o projektach z Hrubieszowa.
Oferta bez rozbicia na godziny i etapy – tylko jedna kwota na końcu.
Jak wykryć: W dokumentach od wykonawcy nie ma pozycji typu analiza, development, testy, wdrożenie, dokumentacja. Trudno powiedzieć, za co dokładnie płacisz.
Jak naprawić: Poproś o kosztorys z liczbą godzin w każdej pozycji i stawką. Nawet jeśli rozliczasz się ryczałtowo, estymacja pokazuje, gdzie są ryzyka i co się stanie, gdy zakres urośnie.
Brak procedury obsługi zmian w trakcie prac.
Jak wykryć: Pojawia się myśl w rodzaju „a jeszcze dodajcie przycisk do faktury” i nikt nie wie, czy to wchodzi w cenę, czy nie.
Jak naprawić: Ustal na piśmie stawkę godzinową za prace dodatkowe i jedno miejsce, w którym zgłaszacie zmiany (mail, tablica, arkusz). Każda zmiana dostaje szacunek godzin i akceptację przed rozpoczęciem.
Praca bez środowiska testowego – moduł wgrywany od razu na produkcję.
Jak wykryć: Pytanie wykonawcy „mogę to wgrać na sklep?” pojawia się częściej niż raz w tygodniu. Nie ma adresu staging z kopią bazy i produktów.
Jak naprawić: Zorganizuj kopię sklepu na subdomenie z osobną bazą i wyłączonym wysyłaniem maili do klientów. Wdrożenie na produkcję to wtedy jeden zaplanowany moment, nie seria drobnych zmian w godzinach sprzedaży.
Zaczynanie prac bez dokumentacji i konta testowego od zewnętrznego dostawcy (kurier, płatności, ERP).
Jak wykryć: Wykonawca pyta o dokumentację API dopiero w połowie prac albo dostajesz informację, że „trzeba to napisać po naszemu, bo dokumentacji nie ma”.
Jak naprawić: Przed startem developmentu zdobądź sandbox, dane dostępowe, limity zapytań i kontakt do wsparcia technicznego partnera. Brak dokumentacji to nie problem wykonawcy, tylko pozycja w kosztorysie – lepiej wiedzieć o niej wcześniej.
Rozmyta odpowiedzialność po stronie klienta – decyzje podejmuje kilka osób albo nikt.
Jak wykryć: Akceptacja ekranu panelu administracyjnego trwa dłużej niż jego wykonanie. Pojawiają się uwagi od osób, które nie brały udziału w ustalaniu zakresu.
Jak naprawić: Wyznacz jedną osobę decyzyjną z realnym czasem na odbiory (2–3 dni robocze na etap) i listą osób opiniujących. Opinie zbieraj przed przekazaniem wykonawcy, nie po.
Brak zdefiniowanego „gotowe” – kryteriów odbioru ustalonych przed developmentem.
Jak wykryć: Przy odbiorze padają zdania „no i jeszcze powinno robić X”, mimo że X nie było w opisie. Każda strona rozumie zakres inaczej.
Jak naprawić: Spisz 5–15 przypadków użycia w formie „jeżeli klient zrobi A, system pokaże B”. To jednocześnie kryterium odbioru i podstawa testów. Ten dokument skraca spory o tygodnie.
Organizacja projektu wpływa na koszt modułu lub wtyczki tak samo mocno jak sama technologia. Estymacja godzin, lista integracji, środowisko testowe, kryteria odbioru i jedna osoba decyzyjna to minimalny zestaw, który chroni budżet przed nieprzewidzianymi dopłatami. Zanim wybierzesz ofertę, porównaj nie tylko kwotę, ale też to, co jest w niej wliczone, a co zostanie doliczone później. Reszta rozliczeń i tak sprowadza się do prostego wzoru: liczba godzin razy stawka plus testy i wdrożenie.
Opisz problem, a nie rozwiązanie techniczne: co ma się dziać, kto tego używa i po czym poznasz, że działa. Dołącz zrzuty ekranu obecnego procesu i listę integracji z nazwami systemów. Dobry brief mieści się na dwóch stronach, a nie na dwudziestu.
Ryczałt daje przewidywalny budżet, ale wykonawca musi gdzieś wliczyć ryzyko – zwykle zawyża godziny o 20–40%. Rozliczenie godzinowe jest tańsze, gdy zakres jest dobrze opisany i nie zmienia się w trakcie. Rozsądny kompromis to ryczałt na analizę i development I etapu plus stawka godzinowa na prace dodatkowe.
Powinno to być zapisane w umowie, bo domyślnie bywa różnie. Standardem jest przeniesienie autorskich praw majątkowych na zamawiającego po zapłacie, z przekazaniem repozytorium i dokumentacji. Bez tego nie zmienisz wykonawcy bez przepisywania modułu od zera.
Zestaw estymację z widełkami dla podobnych prac i zapytaj, co dokładnie obejmuje każda pozycja. Oferta bez listy założeń i bez wskazania ryzyk to sygnał ostrzegawczy. Jeżeli kwota jest wyraźnie niższa od pozostałych, prawdopodobnie brakuje w niej testów, wdrożenia lub wsparcia.
Tak i zwykle warto. Typowy podział to: analiza i prototyp, development z działającym zakresem podstawowym, integracje zewnętrzne, wdrożenie i wsparcie. Płatność po etapie daje Ci możliwość zatrzymania projektu, jeśli pierwszy etap pokaże, że współpraca nie działa.
To sytuacja normalna, zwłaszcza przy starszych systemach ERP i mniejszych operatorach. Dlatego w kosztorysie powinien być bufor na nieprzewidziane prace po stronie integracji – realistycznie 10–20% budżetu. Ustal wcześniej, że takie prace są rozliczane godzinowo po zatwierdzeniu szacunku.
Zaplanuj 2–5 godzin w tygodniu na konsultacje, akceptacje i testy – przy prostym module mniej, przy integracji z ERP więcej. Jeśli nie masz na to czasu, projekt wydłuży się i podrożeje, bo wykonawca będzie czekał. Warto wyznaczyć jedną osobę, która zbiera uwagi zespołu.
Jeśli chcesz mieć estymację godzin rozbitą na pozycje, zamiast jednej kwoty na końcu oferty, napisz do nas – powiemy wprost, ile pracy wymaga Twój przypadek i czego w briefie brakuje. Zakres prac i organizację projektu omówimy na spokojnie, bez zgadywania.