O powodzeniu wdrożenia PrestaShop decyduje proces, nie odległość między Twoim biurem a biurem wykonawcy. Sklep w Poznaniu można zbudować zespołem zdalnym w trzy tygodnie, a można też utopić pół roku w spotkaniach i nie dojść do startu. Ten tekst porządkuje trzy rzeczy: jaki masz scenariusz startowy, ile realnie trwa wdrożenie i jak czytać kosztorys, żeby porównywać oferty na tych samych zasadach. Na końcu znajdziesz listę kontrolną i błędy, które najczęściej rozwalają harmonogram.
Zanim porównasz oferty, ustal, w którym z trzech scenariuszy jesteś. Każdy ma inne ryzyko i inne godziny pracy.
/override/ trzeba sprawdzić pod kątem zgodności z docelową wersją – opisuje to dokumentacja developerska PrestaShop.Lokalizacja firmy wdrożeniowej ma znaczenie tylko w jednym wymiarze: czy da się ustalić zasady współpracy. Sprawdź czas reakcji (np. odpowiedź w 4 godziny w dni robocze), kanał komunikacji (system zgłoszeń, nie Messenger), dostęp do stagingu i to, kto po Twojej stronie podejmuje decyzje. Dojazd na spotkanie raz w tygodniu nie zastąpi zdefiniowanego SLA. Mechanikę takiej współpracy rozpisaliśmy szerzej w materiale o organizacji wdrożenia PrestaShop w Poznaniu.
Wycena skraca się z tygodnia do jednego dnia, gdy odpowiesz na cztery pytania: ile masz SKU, jakie integracje są potrzebne (ERP, magazyn, marketplace, kurier, faktury), kto przygotowuje dane produktowe i w jakim formacie oraz jaki masz budżet na szablon. Gotowy motyw a projekt własny to różnica kilkunastu tysięcy złotych.
| Scenariusz | Główne ryzyko | Co przyspiesza start |
|---|---|---|
| Nowy sklep od zera | Brak decyzji po stronie klienta | Gotowe opisy kategorii, lista płatności i kurierów |
| Migracja ze starej platformy | Mapowanie danych i historia zamówień | Czysty eksport w UTF-8, zdjęcia w jednym katalogu |
| Rozbudowa działającego sklepu | Zgodność modułów i overrides | Kopia stagingu i lista modułów z wersjami |
Poniższy przebieg dotyczy sklepu do 500 SKU bez integracji ERP. Etapy częściowo się nakładają – import danych może iść równolegle z pracami nad szablonem, jeśli dane są gotowe.
Realne sumy: 3–5 tygodni dla sklepu do 500 SKU bez ERP, 6–10 tygodni z integracjami, 2–4 miesiące przy ERP i marketplace’ach. Jeśli wykonawca obiecuje duży sklep z ERP w trzy tygodnie, traktuj to jako sygnał ostrzegawczy.
Harmonogram rozwala najczęściej nie kod, a trzy rzeczy. Brak decyzji o treści kategorii – sklep stoi gotowy, ale nie ma opisów i zdjęć. Czekanie na dostęp do API kuriera – umowa i poświadczenia potrafią zająć dwa tygodnie, jeśli nie zaczniesz ich załatwiać na starcie. Nietestowane dane od dostawcy – CSV z innym separatorem, brak EAN, zdjęcia pod adresami, które zwracają 404. Więcej takich pułapek opisaliśmy w artykule o krytycznych błędach spowalniających sklep. Na koniec testów sprawdź wydajność według Core Web Vitals – LCP poniżej 2,5 s na mobile to dziś minimum.
| Tydzień | Etap | Efekt |
|---|---|---|
| 1 | Analiza i zakres | Dokument zakresu, lista integracji |
| 1–2 | Hosting i środowisko | Działający staging z SSL |
| 2–3 | Szablon | Strona główna, karta produktu, checkout |
| 3–5 | Moduły i integracje | Działające płatności, kurierzy, faktury |
| 4–5 | Import danych | Katalog z cenami i stanami |
| 5–6 | Testy | Zamówienie testowe end-to-end |
| 6 | Start | Przepięty DNS, sklep publiczny |
Wycena godzinowa to jedyny model, który pozwala porównywać oferty. Stawka zespołu wdrożeniowego w Polsce to orientacyjnie 120–220 zł/h netto. Różnica wynika z doświadczenia, nie z lokalizacji. Struktura pracy wygląda tak:
Widełki poglądowe: prosty sklep z gotowym motywem, standardowymi płatnościami i kurierami to zwykle 8–18 tys. zł netto. Sklep z modułami pisanymi na zamówienie, integracją ERP i nietypową logiką dostaw: 25–60 tys. zł netto i więcej. To rynkowe widełki do planowania budżetu, nie ceny konkretnego wykonawcy.
Co podnosi koszt najmocniej? Własne pismo zamiast modułu z marketplace’u – wtyczka za 300 zł kontra 20 godzin pracy programisty. Dalej: wielojęzyczność, cenniki B2B i grupy klientów, import katalogu powyżej 5 tys. SKU oraz migracja historii zamówień, jeśli chcesz zachować dane klientów. Zanim porównasz oferty z różnych miast, zobacz, jak wygląda wdrożenie i organizacja pracy nad sklepem we Wrocławiu – zasady wyceny są identyczne niezależnie od adresu biura.
W kosztorysie powinny znaleźć się cztery rzeczy: liczba godzin przy każdej pozycji, stawka, zakres poza budżetem (co się dzieje, gdy w trakcie wyjdzie dodatkowa integracja) oraz informacja, że hosting, domena i licencje płatnych modułów są poza wyceną. Bez tych punktów porównujesz nie oferty, a hasła.
| Pozycja | Typowy zakres godzin | Przykład przy 150 zł/h netto |
|---|---|---|
| Analiza i projekt | 8–16 h | 1 200–2 400 zł |
| Wdrożenie i szablon | 40–120 h | 6 000–18 000 zł |
| Integracja (np. ERP) | 20–80 h | 3 000–12 000 zł |
| Import katalogu do 1000 SKU | 3–7 h | 450–1 050 zł |
Zanim podpiszesz harmonogram, wypisz punkty styku sklepu z otoczeniem. W PrestaShop każdy z nich to osobny moduł, własne konto API i własne statusy zamówień. Poniżej lista do odhaczania.
Płatności. Przelewy24, PayU, BLIK, Stripe i płatności odroczone (PayPo, Klarna) to pięć różnych integracji, nie jedna. Kluczowa jest obsługa webhooków: bez nich sklep czeka na powrót klienta na stronę, a zamówienie zostaje w statusie „Oczekiwanie na płatność”, mimo że pieniądze wpłynęły. Zmapuj odpowiedzi bramki (success, failed, pending) na statusy PrestaShop i pamiętaj o idempotencji — ten sam webhook potrafi przyjść dwa razy i nie może wygenerować dwóch faktur.
Kurierzy. InPost ShipX, DPD i DHL: generowanie etykiet PDF, wybór punktu odbioru w koszyku, automatyczne statusy przesyłek. Numer listu przewozowego zapisuj w zamówieniu, a statusy pobieraj cronem co 30–60 minut i wysyłaj mailem do klienta zamiast klepać je ręcznie w panelu.
ERP i księgowość. Subiekt GT/nexo, Comarch Optima, Fakturownia, Wapro. Ustal jedno źródło prawdy dla stanów magazynowych — najczęściej ERP. Stany synchronizuj co 5–15 minut, ceny raz na dobę, faktury po zmianie statusu na „Zrealizowane”. Dwa źródła prawdy to gwarantowane nad sprzedaże.
KSeF. Sklep musi przekazać dane do faktury: NIP i nazwę nabywcy z walidacją na Białej liście, adres, numer zamówienia, kwoty netto i VAT według stawek oraz numer KSeF. Zaprojektuj to przed startem — dokładanie pola NIP po pierwszym okresie rozliczeniowym oznacza korekty i ręczną pracę księgowości.
Zdarza się, że trzy płatne wtyczki robią to samo i konfliktują się przy aktualizacji, bo nadpisują ten sam hook actionOrderStatusPostUpdate. Wtedy tańszy bywa jeden moduł pisany pod Twój proces — opisujemy to szerzej przy okazji integracji sklepu z systemem sprzedażowym. Dokumentację hooków znajdziesz w dokumentacji dla deweloperów PrestaShop.
| Obszar | Co dokładnie podłączyć | Typowa pułapka |
|---|---|---|
| Płatności | Przelewy24, PayU, BLIK, Stripe, płatności odroczone | Brak webhooków, statusy zamówień wiszące w „oczekiwaniu” |
| Kurierzy | InPost ShipX, DPD, DHL, punkty odbioru na mapie | Etykiety generowane ręcznie, brak numeru przesyłki w zamówieniu |
| ERP i księgowość | Subiekt GT/nexo, Comarch Optima, Fakturownia, Wapro | Dwa źródła prawdy dla stanów magazynowych |
| KSeF | NIP z Białą listą, kwoty netto/VAT, numer KSeF | Brak pola NIP w procesie zamówienia, korekty po fakcie |
Najczęstszy błąd techniczny nie wychodzi w testach — wychodzi przy pierwszej kampanii, gdy na sklep wchodzi 300 osób w ciągu minuty. Wtedy okazuje się, że hosting współdzielony dławi PHP, a baza czeka na wolne połączenia.
Minimum konfiguracji: PHP 8.1–8.3, MySQL 8 lub MariaDB 10.4+, OPcache włączony, memory_limit 256 MB (512 MB przy imporcie CSV z kilkoma tysiącami produktów), max_execution_time 300 s dla importów, realpath_cache_size podniesiony do 4096K. Te wartości sprawdzisz w panelu hostingu, nie w zakładce „Parametry zaawansowane” PrestaShop.
Hosting współdzielony wystarczy przy kilkudziesięciu zamówieniach miesięcznie i ruchu bez skoków. Problem nie leży w samym wolumenie, a w braku kontroli: nie ustawisz osobnej puli PHP-FPM, nie dostroisz OPcache, nie postawisz środowiska staging. A staging jest potrzebny — każdą aktualizację modułu i zmianę szablonu testujesz na kopii bazy, nie na żywym sklepie.
VPS 4–8 GB RAM z osobnym stagingiem (subdomena, osobna baza, noindex, wyłączone płatności i wysyłka maili) to standard przy kampaniach reklamowych. Do tego backupy poza serwer produkcyjny — S3 albo Backblaze, retencja 30 dni, test odtworzenia raz na kwartał. Monitoring dostępności z próbą co minutę i alertem SMS, z zapisanym czasem reakcji na awarię.
Konfiguracja serwera przekłada się na Core Web Vitals, przede wszystkim na TTFB, a przez to na LCP. Wolnej odpowiedzi serwera nie naprawi żaden cache w przeglądarce. Po wdrożeniu przejdź też przez listę krytycznych błędów spowalniających PrestaShop.
| Parametr | Hosting współdzielony | VPS 4–8 GB |
|---|---|---|
| Środowisko staging | Zwykle brak | Osobna subdomena i baza |
| Dostrajanie OPcache i PHP-FPM | Brak dostępu | Pełna kontrola |
| Skok ruchu z kampanii | Ryzyko dławienia PHP | Bufor zależny od konfiguracji |
| Backupy poza serwerem | Zależne od operatora | Konfigurujesz sam, z testem odtworzenia |
Zadaj te pytania w pierwszej rozmowie i zapisz odpowiedzi. Oferty bez odpowiedzi na pierwsze trzy odpadają same.
Czerwone flagi: brak etapu testów, wycena „ryczałtem do końca”, brak wskazanej osoby kontaktowej, brak SLA na piśmie, brak odpowiedzi, kto jest właścicielem repozytorium. Całe wdrożenie powinno biec na jednym repozytorium i jednym stagingu — więcej o tym w tekście o organizacji wdrożenia sklepu PrestaShop w Poznaniu.
| Pytanie | Dobra odpowiedź | Czerwona flaga |
|---|---|---|
| Kto pisze kod | Konkretne role w zespole | „Mamy sprawdzonych podwykonawców” bez nazwisk |
| Czas reakcji | Zapisany w SLA, np. 4 h dla błędu krytycznego | „Reagujemy na bieżąco” |
| Przekazanie projektu | Repozytorium, dokumentacja, dostępy | Kod tylko na serwerze wykonawcy |
| Wycena | Etapy z zakresem i stawką godzinową | Ryczałt do końca bez zakresu |
Największe spadki ruchu po przenosinach nie wynikają z designu, tylko z adresów URL. Zacznij od inwentaryzacji: w Search Console otwórz Indeksowanie → Raport stron i wyeksportuj wszystkie adresy ze statusem „Zindeksowano”, a równolegle przepuść stary sklep crawlerem (np. Screaming Frog z ustawieniem „0 błędów połączenia”). Zapisz osobno: produkty, kategorie i podkategorie, adresy filtrów z parametrami, wpisy blogowe, strony informacyjne oraz 404, które Google już zna.
Z tego powstaje mapa przekierowań 301 jeden do jednego: każdy stary adres ma dokładnie jeden cel, najlepiej odpowiednik tematyczny. Produkt → produkt (albo kategoria, gdy produkt zniknął ze sprzedaży), kategoria → ta sama kategoria, wpis → wpis. Filtry to najczęstszy problem: jeśli nie mają odpowiednika, przekieruj je na kategorię nadrzędną, nie na stronę główną — zbiorcze 301 na home Google potrafi potraktować jak soft 404. Reguły w .htaccess wstaw nad blokiem PrestaShop, inaczej mod_rewrite sklepu przechwyci adresy pierwszy. Struktura URL i reguły przepisywania są opisane w dokumentacji dla deweloperów PrestaShop.
Co przenosimy: opisy i treści, metadane (title, description, alt), dane klientów oraz historię zamówień — tę ostatnią głównie po to, by obsłużyć zwroty, reklamacje i ponowne faktury. Hasła kont są zahashowane, więc konta przenosi się z wymuszeniem resetu hasła przy pierwszym logowaniu. Statystyki sprzedaży z poprzedniej wersji często lepiej zacząć od zera, jeśli liczby mają opisywać nowy sklep od dnia startu.
Kolejność: nowa wersja na subdomenie z blokadą indeksowania, testy, przełączenie DNS, wdrożenie przekierowań, zgłoszenie zmiany adresu w Search Console i wysłanie nowej mapy witryny. Pełną kolejność prac, od briefu do odbioru, znajdziesz w materiale o organizacji wdrożenia PrestaShop w Poznaniu. Po starcie porównaj liczbę indeksowanych adresów, sprawdź łańcuchy 301 → 301 → 200 i monitoruj ruch przez 4 tygodnie, tydzień do tygodnia.
| Typ starego adresu | Cel przekierowania | Pułapka |
|---|---|---|
| Produkt istniejący | Ten sam produkt w nowym sklepie | Zmiana sluga bez 301 = utrata ruchu na frazę produktową |
| Produkt wycofany ze sprzedaży | Kategoria nadrzędna | Przekierowanie na stronę główną Google traktuje jak soft 404 |
| Kategoria i podkategoria | Ta sama kategoria | Zmiana drzewa kategorii bez mapy starego drzewa |
| Adres filtra z parametrami | Kategoria bazowa | Łańcuch 301 → 301 → 200 wydłuża czas odpowiedzi |
| Wpis blogowy | Ten sam wpis | Stary /blog/ vs nowy /aktualnosci/ bez reguły |
| Regulamin, kontakt, polityka | Ten sam adres | Pominięcie tych stron w mapie przekierowań |
Start to nie moment, w którym strona zaczyna działać, ale sekwencja kroków, z których każdy można jeszcze cofnąć. Wyłącz tryb serwisowy i noindex, usuń blokadę indeksowania z .htaccess, a dopiero potem podłączaj płatności i wysyłkę. Testowe zamówienie rób na produkcie za 1 zł z realną płatnością i realnym zwrotem — inaczej nie sprawdzisz księgowania i maili transakcyjnych. Sprawdź SPF i DKIM dla nowej domeny, bo maile potwierdzające potrafią wylądować w spamie, a klient zgłasza to jako „sklep nie działa”.
Zakres opieki technicznej ustal na piśmie, nie na zasadzie „jakoś to ogarniemy”. Minimum: aktualizacje PrestaShop i modułów w stałym oknie poza szczytem sprzedażowym, backupy bazy i plików (co najmniej raz dziennie, retencja 30 dni, test odtworzenia raz na kwartał), monitoring wydajności i dostępności, poprawki błędów popełnionych przy wdrożeniu oraz wsparcie przy kampaniach (np. przygotowanie sklepu na wzrost ruchu przed Black Friday).
Po starcie najczęściej wąskim gardłem nie jest hosting, a konfiguracja. Pierwszy winowajca to nieskompresowane obrazy — pliki PNG po 2 MB zamiast WebP i kilku rozmiarów generowanych przy uploadzie. Drugi: moduły ładujące skrypty globalnie, także tam, gdzie ich nie używacie. Trzeci: wyłączony cache — w Zaawansowane → Wydajność włącz cache szablonów i cache bazy, jeśli hosting wspiera APCu albo memcached. Czwarty: wolne zapytania do bazy przy tysiącach kombinacji atrybutów. Progi, które warto znać, opisuje dokumentacja web.dev o Web Vitals, a typowe błędy konfiguracji zebraliśmy w artykule o błędach spowalniających sklep PrestaShop.
Opiekę mierz trzema liczbami: czas reakcji na zgłoszenie (np. 4 godziny w dni robocze, 1 godzina dla sklepu niedostępnego), miesięczny czas niedostępności oraz liczba incydentów w miesiącu. Bez tych danych nie odróżnisz opieki od abonamentu za spokój sumienia.
| Krok startu | Co sprawdzasz | Sygnał, że jest OK |
|---|---|---|
| Wyłączenie trybu serwisowego | noindex, blokada w .htaccess, podgląd dla niezalogowanych | Produkt widoczny dla wycinka i w trybie incognito |
| Testowe zamówienie | Zmiana statusów, mail do klienta i do sklepu | Zamówienie widoczne w panelu z poprawnym statusem |
| Płatność | Realna transakcja i zwrot | Środki pobrane i zwrócone, status zgodny z panelem |
| Etykieta kurierska | Integracja z kurierem, waga i wymiary | Etykieta generuje się bez błędu API |
| Mail potwierdzający | SPF, DKIM, treść szablonu | Wiadomość trafia do skrzynki, nie do spamu |
| Faktura | Numeracja, dane sprzedawcy, VAT | Dokument zgodny z danymi firmy i stanem magazynu |
Wybór wykonawcy po mieście, a nie po procesie. Firma z Poznania nie znaczy, że ktoś będzie u Ciebie co tydzień, ani że szybciej odpisze na zgłoszenie.
Jak wykryć: W ofercie jest dużo o dojazdach i spotkaniach, a nie ma ani słowa o czasie reakcji na zgłoszenie, kanałach komunikacji i tym, kto odbiera zgłoszenia w piątek o 16:00.
Jak naprawić: Zapytaj wprost o SLA, godziny wsparcia, kanał zgłoszeń i jedną osobę prowadzącą projekt. Zapisz to w umowie. Odległość traktuj jako kwestię drugorzędną.
Brak decyzji o treściach i strukturze kategorii przed startem prac. Wdrożenie stoi, bo ktoś „musi jeszcze przemyśleć” układ menu.
Jak wykryć: Na etapie testów nie ma zatwierdzonej listy kategorii, opisów kategorii ani decyzji o tym, kto odpowiada za treści. Programista poprawia strukturę dwa razy.
Jak naprawić: Wyznacz jedną osobę po stronie firmy, która akceptuje treści, i ustaw termin zamknięcia struktury kategorii przed wdrożeniem szablonu. Zmiany po tym terminie traktuj jako osobną pozycję kosztorysową.
Czekanie z dostępami. API kuriera, panel hostingu, DNS, konto w bramce płatności i dane do ERP zamawiane są dopiero wtedy, gdy są potrzebne.
Jak wykryć: W harmonogramie jest pozycja „integracja z kurierem”, ale nikt nie wie, czy klucze API już istnieją i kto ma uprawnienia do ich wygenerowania.
Jak naprawić: Zrządź listę dostępów w dniu podpisania umowy i przypisz właściciela do każdej pozycji. Ustal, że brak dostępu w terminie przesuwa etap, a nie cały projekt „jakoś się dogada”.
Dane produktowe w pliku, którego nikt wcześniej nie przepuścił przez import testowy. Problem wychodzi dopiero przy pełnym imporcie katalogu.
Jak wykryć: Eksport z magazynu ma inne nazwy kolumn niż wcześniej ustalono, brakuje EAN, zdjęcia mają niespójne nazwy, ceny są raz netto, raz brutto, część SKU ma puste stany.
Jak naprawić: Zrób import próbny na 20–50 produktach, najlepiej reprezentujących różne przypadki: produkt z wariantami, produkt bez zdjęcia, produkt z ceną promocyjną. Dopiero po nim puszczaj cały katalog.
KSeF i integracja księgowa projektowane po starcie, a nie przed nim. Sklep sprzedaje, a faktury trzeba wystawiać ręcznie albo dublować pracę.
Jak wykryć: Pytanie „a jak sklep przekazuje faktury do księgowości?” pojawia się na spotkaniu po uruchomieniu, gdy pierwsze zamówienia już poszły.
Jak naprawić: Na etapie analizy ustal, jakie dane sklep musi przekazać dalej: numer zamówienia, NIP, stawki VAT, dane do KSeF, format pliku dla biura rachunkowego. Zaplanuj to jako część zakresu, nie jako dodatek.
Zakup trzech płatnych wtyczek, które robią to samo, plus czwartej „na wszelki wypadek”. Moduły konfliktują się przy aktualizacji.
Jak wykryć: Kilka modułów podpina się pod ten sam hook, nadpisuje te same szablony albo dubluje statusy zamówień. Po aktualizacji PrestaShop jedna funkcja przestaje działać.
Jak naprawić: Spisz wymagania w jednym dokumencie: jakie płatności, jakie statusy, jakie maile. Wybierz jedno rozwiązanie na obszar. Jeśli wymagania są nietypowe i pokrywają się w dwóch modułach, policz osobno własny moduł i porównaj koszt utrzymania, nie tylko koszt zakupu.
O tym, czy sklep PrestaShop w Poznaniu wystartuje w terminie, decyduje organizacja: zamknięta struktura kategorii, dostępy zebrane na starcie, dane produktowe sprawdzone importem próbnym i plan integracji spisany przed wyceną. Lokalizacja wykonawcy ma znaczenie wyłącznie wtedy, gdy zależy Ci na spotkaniach w siedzibie — czas reakcji i SLA da się ustalić równie dobrze z zespołem zdalnym. Zacznij od trzech liczb: liczba SKU, liczba integracji, liczba decyzji, które musisz podjąć sam. To one wyznaczają harmonogram i budżet, nie nazwa miasta na fakturze.
Nie. Znaczenie ma to, jak wygląda komunikacja, czas reakcji na zgłoszenia i czy ktoś realnie odpowiada za projekt. Zespół pracujący zdalnie może być dostępny w Twoich godzinach pracy, a firma z miasta obok może odzywać się raz w tygodniu. Dojazd na spotkanie to wygoda, nie kryterium techniczne.
Dla sklepu do 500 SKU, bez integracji z ERP, realny zakres to 3–5 tygodni. Z integracjami płatności, kurierów i księgowości rośnie do 6–10 tygodni. Przy integracji z ERP i marketplace trzeba liczyć 2–4 miesiące. Terminy krótsze niż dwa tygodnie dla sklepu z importem i integracjami są mało prawdopodobne.
Trzy rzeczy: brak decyzji o treściach i kategoriach, czekanie na dostępy do API kuriera lub bramki płatności oraz nietestowane dane produktowe od dostawcy. Każda z nich potrafi dodać tydzień lub dwa, mimo że nie jest pracą programistyczną. Dlatego warto zamknąć je jeszcze przed startem wdrożenia.
Poproś o rozbicie na stawki godzinowe i liczbę godzin na każdy etap: analiza, konfiguracja środowiska, motyw, moduły i integracje, import, testy, start. Dopiero wtedy zobaczysz, czy tańsza oferta pomija import, testy czy integrację z KSeF. Orientacyjne stawki zespołu wdrożeniowego mieszczą się w przedziale 120–220 zł/h netto, ale liczy się iloczyn stawki i godzin.
Nie zawsze w pierwszym dniu, ale warto zaprojektować ją na etapie analizy. Sklep musi przekazać dane potrzebne do wystawienia faktury: NIP, stawki VAT, dane nabywcy, numer zamówienia. Jeśli ustalisz to po starcie, pierwszy okres rozliczeniowy oznacza pracę ręczną i przepisywanie danych z panelu do systemu księgowego.
Wtedy, gdy trzy płatne moduły pokrywają się w połowie i konfliktują przy aktualizacji. Koszt zakupu bywa niski, ale utrzymanie — sprawdzanie zgodności po każdej aktualizacji — kosztuje co miesiąc. Policz osobno koszt wdrożenia własnego modułu i koszt utrzymania obu wariantów przez rok. Dokumentacja techniczna PrestaShop jest publiczna, co ułatwia wycenę takiej pracy.
Cztery rzeczy: liczbę SKU z wariantami, listę integracji, źródło danych produktowych i budżet na szablon. Do tego wskaż osobę decyzyjną po swojej stronie. Z tym zestawem wycena jest konkretna, a nie „od–do”, i można ją porównać z inną ofertą punkt po punkcie.
Jeśli chcesz przełożyć to na konkretny zakres i harmonogram dla swojego sklepu, napisz do DropDigital z liczbą SKU i listą integracji. Wrócimy z pytaniami, które domkną wycenę, zamiast zgadywać.