Wpisujesz „woocommerce łódź”, bo szukasz kogoś, kto zrobi sklep od zera, przeniesie go z innej platformy albo dokończy projekt, który utknął. Zamiast kursu WooCommerce dajemy trzy rzeczy, które realnie decydują o projekcie: orientacyjne widełki cenowe, harmonogram od briefu do startu i listę integracji obowiązkowych w Polsce. Znajdziesz tu też pytania, które warto zadać wykonawcy przed podpisaniem umowy, oraz błędy, które widzimy w przejmowanych projektach najczęściej. To materiał do porównywania ofert, nie do czytania dla samego czytania.
Fraza „woocommerce łódź” trafia do nas w trzech dość różnych typach zapytań i każdy oznacza inny projekt, inny budżet i inny harmonogram.
Czy lokalizacja wykonawcy ma znaczenie? Mniejsza, niż podpowiada intuicja. Realna praca i tak odbywa się przez internet — repozytorium, panel hostingu, mail, wideokonferencje. Łódź daje dwie konkretne przewagi: spotkanie na miejscu przy briefie i odbiorze (mniej nieporozumień, gdy katalog ma 2000 SKU i trzeba uporządkować dane produktowe) oraz wizytę w firmie przy projektach z nietypową logistyką. Nie daje natomiast niższych cen ani krótszych terminów — o tym decyduje zakres, nie kod pocztowy.
Dalej znajdziesz trzy rzeczy, które realnie pozwalają porównywać oferty: widelki cenowe z rozbiciem na zakres, harmonogram od briefu do startu z podziałem na tygodnie oraz listę integracji obowiązkowych w Polsce (Przelewy24, InPost, Fakturownia, Subiekt). Na końcu zestaw pytań do wykonawcy przed podpisaniem umowy.
Zanim zaczniesz zbierać oferty, ustal punkt odniesienia. Widełki poniżej to ceny netto za wdrożenie na gotowym motywie (Astra, Kadence, Blocksy) albo lekkim motywie customowym. Sklep na autorskim projekcie graficznym z pełnym UI/UX jest zwykle o 30–60% droższy od tych wartości.
Co wchodzi w cenę: konfiguracja WordPress i WooCommerce, struktura kategorii, szablon karty produktu i koszyka, 2–3 metody płatności, 2–3 integracje kurierskie, ustawienia podatków i stref wysyłki, podstawowa optymalizacja szybkości, szkolenie z panelu i 30 dni wsparcia powdrożeniowego. Co jest doliczane osobno: hosting (400–1200 zł/rok za serwer SSD w Polsce), certyfikat SSL (Let's Encrypt 0 zł, komercyjny 200–600 zł/rok), wtyczki premium (200–1500 zł/rok łącznie), zdjęcia i opisy produktów, teksty SEO, wejście do porównywarki Ceneo (od ok. 500 zł/mc) oraz opieka techniczna po gwarancji.
Pułapka: wycena 2999 zł. Za te pieniądze nie powstaje sklep, który sprzedaje — dostajesz instalację szablonu z marketplace'u i produkty wprowadzone ręcznie na próbce. Konsekwencje widać po trzech miesiącach: brak reguł podatkowych przy wysyłce zagranicznej, koszyk bez walidacji NIP, brak kopii zapasowych, motyw porzucony przez autora. Poprawki takiego sklepu kosztują zwykle więcej niż porządne wdrożenie od początku.
Łódź kontra firmy zdalne. Stawki w Łodzi to zwykle 100–180 zł/h, w Warszawie 150–250 zł/h, a firmy zdalne z mniejszych ośrodków pracują za 80–140 zł/h. Różnica w cenie projektu rzadko wynika z geografii — wynika z tego, czy wykonawca wycenia testy, migrację danych i optymalizację, czy tylko „postawienie sklepu”. Dla porównania warto zobaczyć, jak rozbijamy to na pozycje przy wdrożeniu WooCommerce w innym mieście — struktura kosztorysu jest identyczna niezależnie od lokalizacji.
| Zakres projektu | Orientacyjny koszt netto | Realistyczny czas |
|---|---|---|
| Mały sklep do 200 SKU, gotowy motyw, 2–3 płatności, 2 kurierów | 8 000 – 15 000 zł | 4–6 tygodni |
| Średni sklep 200–2000 SKU, import produktów, migracja lub integracja z Fakturownią, kody rabatowe, wielojęzyczność | 18 000 – 40 000 zł | 8–12 tygodni |
| Duży sklep z ERP (Subiekt GT/nexo, Comarch, WAPRO), B2B z cennikami klientów, hurtownie, stany magazynowe w czasie realnym | 45 000 – 90 000 zł i więcej | 12–20 tygodni |
Poniższe tygodnie dotyczą średniego projektu (200–2000 SKU) i zakładają, że po obu stronach jest jedna osoba decyzyjna. Projekty rozciągają się nie dlatego, że praca jest trudna, ale dlatego, że decyzje zapadają co dwa tygodnie.
Etapy zależne od klienta: brief (brakuje danych o marżach i strukturze katalogu), treści i zdjęcia (najczęstszy hamulec — bez opisów nie da się testować wydajności katalogu), dostęp do domeny i DNS, dane do integracji płatności (numer konta, umowa z operatorem), numerów kurierskich klienta (InPost, DPD, DHL) oraz decyzja o migracji historii zamówień. W naszych projektach dwie trzecie opóźnień to brak materiałów, nie błędy w kodzie.
Odbiór techniczny przed startem to osobny etap, nie formalność. Sprawdzamy: płatność testową i produkcyjną na 1 zł, poprawność maili transakcyjnych (SPF, DKIM, DMARC — bez tego potwierdzenia zamówień lądują w spamie), statusy zamówień i magazyn przy zamówieniu i anulowaniu, metryki Core Web Vitals (LCP poniżej 2,5 s, INP poniżej 200 ms, CLS poniżej 0,1 — opis w dokumentacji Web Vitals), dane strukturalne Product, Offer i BreadcrumbList, sitemap.xml, robots.txt, wyłączony tryb noindex, kopię zapasową i plan aktualizacji. Dopiero po tym zdejmujemy hasło z domeny.
| Etap | Czas | Kto blokuje |
|---|---|---|
| Brief i ustalenie zakresu | 3–5 dni | Klient — decyzje o katalogu, płatnościach, wysyłce |
| Makiety i struktura kategorii | 1–2 tygodnie | Wykonawca, akceptacja po stronie klienta |
| Konfiguracja sklepu, motyw, płatności i kurierzy | 3–5 tygodni | Wykonawca + dostępy od klienta |
| Import produktów, migracja i przekierowania 301 | 1–3 tygodnie | Klient — zdjęcia, opisy, baza starych adresów URL |
| Testy, odbiór techniczny, szkolenie, start | 1–2 tygodnie | Obie strony — lista poprawek i akceptacja |
Anglojęzyczne poradniki kończą się na Stripe i PayPal. W Polsce to nie wystarcza — bez BLIK-a i paczkomatu konwersja spada, a bez faktur w systemie księgowym księgowa zaczyna dzwonić po dwóch tygodniach.
Przelewy24 i PayU mają oficjalne wtyczki do WooCommerce i obie obsługują BLIK jako osobną metodę. Różnica jest w szczegółach: PayU wymaga konfiguracji punktu płatności (POS) i przekazania klucza OAuth, Przelewy24 pracuje na ID sprzedawcy plus CRC. Prowizje ustalasz indywidualnie w umowie z operatorem — nie ma jednej publicznej stawki, więc nie wierz ofercie, w której wykonawca ją „gwarantuje”. Warto negocjować osobno BLIK, bo zwykle jest tańszy niż karta.
Pułapka techniczna: webhooki. Jeśli status zamówienia nie zmienia się automatycznie po płatności, w 90% przypadków przyczyną jest zablokowany URL powiadomień (WAF, basic auth na stagingu przeniesiony na produkcję) albo cache na endpointzie /?wc-api=.
Integracja z wFirmą, iFirmą czy Subiektem oznacza wystawianie faktury automatycznie po zmianie statusu zamówienia. Ustal jasno przy briefie: faktura po opłaceniu czy po wysyłce? To jedna linijka w konfiguracji, ale zmiana po starcie oznacza bałagan w numeracji.
Integracja z Allegro ma sens, gdy masz 200+ SKU i realnie sprzedajesz tam już teraz. Przy 30 produktach ręczne wystawianie jest tańsze niż utrzymanie synchronizacji stanów. Ceneo i Google Merchant wymagają poprawnego feedu XML z GTIN — bez tego oferty są odrzucane.
| Integracja | Typowy nakład wdrożenia | Na co uważać |
|---|---|---|
| Przelewy24 / PayU + BLIK | 1–3 h przy oficjalnej wtyczce | Webhooki blokowane przez WAF lub cache |
| InPost Paczkomaty | 2–4 h | Konflikt JS geowidgetu z page builderem |
| DPD / DHL etykiety | 4–8 h | Numer listu nieprzekazywany do maila klienta |
| Program księgowy (wFirma, iFirma, Subiekt) | 4–12 h | Moment wystawienia faktury i numeracja |
| Feed do Ceneo / Google Merchant | 3–6 h | Brak GTIN, EAN i cen z dostawą |
Lokalizacja jest przydatna na etapie briefu i szkolenia — spotkanie w Łodzi zamiast trzeciego calla oszczędza tydzień. Ale kodu nie ocenisz po adresie. Oceniaj po odpowiedziach na konkretne pytania.
Weź trzy linki z portfolio i przepuść je przez PageSpeed Insights na mobile. Sprawdź, czy koszyk obsługuje paczkomat, czy da się wybrać fakturę na firmę i czy strona kategorii z filtrami nie ładuje się 6 sekund. Zajmuje to 10 minut i mówi więcej niż cała prezentacja. Więcej o tym, co realnie poprawia wyniki, opisaliśmy w poradniku o optymalizacji prędkości sklepu WooCommerce.
Jedna kwota bez etapów i kamieni milowych. Brak zapisu o hostingu i jego parametrach (PHP, limit pamięci, liczba workerów). Brak SLA. Brak wyceny migracji danych, gdy przenosisz sklep. I klasyk: „SEO w cenie” bez ani jednego zdania o tym, co to konkretnie znaczy.
To lista z projektów, które przejmowaliśmy po innych wykonawcach. Każdy z tych błędów da się naprawić, ale naprawa kosztuje więcej niż zrobienie tego dobrze na starcie.
Sklep z 47 aktywnymi wtyczkami to nie wyjątek, to standard w przejmowanych projektach. Trzy z nich zwykle robią to samo (SEO, cache, galeria), dwie mają wygasłe licencje, a jedna dodaje 300 kB JavaScriptu do każdej podstrony, choć obsługuje tylko formularz na stronie kontakt. Zasada praktyczna: jeśli funkcja to 30 linii kodu w functions.php lub małej wtyczce własnej, nie instaluj pakietu z 40 opcjami. Audyt zaczynaj od Query Monitor — pokaże, która wtyczka generuje najwięcej zapytań SQL.
Aktualizacja WooCommerce na produkcji w piątek po południu to najkrótsza droga do weekendu bez sprzedaży. Staging to nie luksus — większość hostingów oferuje go w panelu jednym kliknięciem. Minimum: kopia bazy i plików, test pełnej ścieżki zakupowej (koszyk, płatność testowa, e-mail, faktura), dopiero potem produkcja. Zasady aktualizacji i migracji opisuje dokumentacja WooCommerce.
Gotowy motyw jest w porządku, gdy masz standardowy katalog i budżet do kilkunastu tysięcy. Problem pojawia się przy motywach „all-in-one” z 15 demami i własnym page builderem — ładują kod wszystkich wariantów, a po roku aktualizacja łamie układ. Dedykowany motyw na bazie bloków ma sens przy nietypowej karcie produktu, konfiguratorze albo B2B.
Optymalizacja po starcie to zawsze droższa robota. Zamiast tego ustaw na starcie: WebP dla zdjęć, lazy load poza pierwszym ekranem, cache stron z wyłączeniem koszyka i checkoutu, PHP 8.2+, obiektowy cache (Redis). Cele mierz według definicji Core Web Vitals na web.dev, a nie „na oko”.
Przy przejściu z innej platformy spisz przed startem: mapowanie URL-i (stare adresy → 301), historię zamówień, konta klientów z hasłami (zwykle wymagają resetu), warianty produktów i pliki cyfrowe. Jeśli jeszcze wybierasz platformę, porównanie znajdziesz w tekście PrestaShop czy WooCommerce.
Sklep po starcie nie jest skończony. Wtyczki dostają aktualizacje co kilka dni, PHP zmienia wersję raz na rok, a kurier zmienia API bez pytania. Umowa serwisowa powinna to opisywać liczbami, nie zdaniem "zapewniamy wsparcie".
SLA w praktyce. Rozdziel dwa parametry, bo klienci je mylą. Czas reakcji to moment, w którym ktoś potwierdza zgłoszenie i mówi, co robi dalej. Czas naprawy to usunięcie problemu. Realne widełki na polskim rynku: reakcja 4 godziny robocze dla awarii krytycznej (koszyk lub płatność nie działają), 1 dzień roboczy dla usterki, 3 dni dla drobnych zmian. Ustal jeden kanał zgłoszeń — system ticketowy albo dedykowany adres e-mail. Zgłoszenia na prywatnym WhatsAppie developera nie da się rozliczyć ani odtworzyć po tym, jak ten developer odejdzie z firmy.
Aktualizacje. Nigdy nie aktualizuj wtyczek na produkcji. Standard to kopia sklepu na staging, aktualizacja, ręczne przejście ścieżki zakupowej (dodanie do koszyka, przeliczenie dostawy, płatność testowa, wysyłka faktury), dopiero potem produkcja. Największe ryzyko w WooCommerce to wtyczki płatności i integracje z ERP — łamią się najczęściej. Zmiany w bazie po aktualizacji WooCommerce opisuje dokumentacja WooCommerce.
Backup. Umowa powinna mówić: baza codziennie, pliki raz na tydzień, retencja minimum 30 dni, kopia w innej lokalizacji niż serwer sklepu. I najważniejsze zdanie, którego brakuje w 90% umów, jakie widzimy: raz na kwartał wykonawca odtwarza backup na staging i potwierdza, że sklep działa. Kopia, której nikt nie przywracał, jest tylko plikiem.
Kiedy opieka nie wystarcza. Sygnały: co miesiąc zgłaszasz zmiany funkcjonalne, a nie usterki; czas realizacji zamówienia rośnie, bo ktoś ręcznie przepisuje dane; LCP nie schodzi poniżej 2,5 s nawet po cache. Wtedy potrzebujesz projektu rozbudowy, nie godzin serwisowych. Jeśli problemem jest wydajność, zacznij od optymalizacji prędkości sklepu WooCommerce.
| Element umowy | Co powinno być zapisane | Częsty błąd |
|---|---|---|
| Czas reakcji | 4 h robocze dla awarii krytycznej | "Niezwłocznie" |
| Czas naprawy | 1 dzień roboczy dla usterki | Brak zapisu |
| Kanał zgłoszeń | Ticket lub dedykowany e-mail | Prywatny komunikator |
| Backup bazy | Codziennie, retencja 30 dni | Tylko backup hostingu |
| Test backupu | Odtworzenie raz na kwartał | Nigdy nie testowany |
| Aktualizacje | Staging + test ścieżki zakupowej | Auto-update na produkcji |
Powiedzmy to wprost: lokalizacja wykonawcy ma znaczenie w kilku konkretnych sytuacjach, a w pozostałych nie ma żadnego.
Za lokalnym wykonawcą. Spotkanie na miejscu wygrywa, gdy brief jest niejasny albo złożony. Przykłady z naszej praktyki: migracja z systemu magazynowego, którego nikt w firmie nie umie opisać słowami, sklep B2B z indywidualnymi cennikami dla 40 kontrahentów, integracja z produkcją. Dwie godziny przy jednym stole z magazynierem i księgową skraca ustalenia o dwa tygodnie mailowej wymiany. Lokalny wykonawca ma też sens, jeśli w firmie nikt nie pracuje na dokumentach online i wszystko ustala się rozmową.
Kiedy lokalizacja nie ma znaczenia. Gdy wiesz, co chcesz sprzedawać, masz zdjęcia i opisy produktów, wybrane integracje (kurier, płatności, faktury) i akceptujesz pracę w narzędziu do zarządzania projektem. Standardowe wdrożenie WooCommerce z 200–500 produktami, jedną bramką płatniczą i kurierem to projekt, w którym spotkanie na żywo nie wnosi nic ponad rozmowę wideo z udostępnionym ekranem. Migracja z innej platformy również — tam liczy się dostęp do bazy i eksportów, nie geografia.
Jak weryfikować firmę zdalną. Poproś o dwa sklepy z ostatnich 12 miesięcy i kontakt do tych klientów, nie tylko zrzuty ekranu. Sprawdź w umowie: kto ma prawa autorskie do kodu, gdzie trafiają dane dostępowe po zakończeniu projektu, jaki jest tryb wypowiedzenia serwisu. Płatność rozbij na etapy powiązane z efektem (podpisanie makiet, sklep na stagingu, start produkcyjny), nie z kalendarzem. Zapytaj też, kto konkretnie będzie pracował nad projektem i czy zobaczysz jego commity.
DropDigital pracuje zdalnie z klientami z całej Polski — od Łodzi po Zieloną Górę, gdzie prowadziliśmy wdrożenie WooCommerce z pełnym harmonogramem i kosztorysem. Jeśli wciąż wybierasz platformę, warto najpierw przejrzeć porównanie WooCommerce i Shopify pod kątem kosztów w PL.
Dokładanie wtyczek premium zamiast jednego rozwiązania dedykowanego. Efekt to dziesiątki zapytań do bazy na każde wejście, konflikty skryptów i sklep, który na kartach produktu ładuje się kilka sekund.
Jak wykryć: Policz wtyczki aktywne w panelu i sprawdź, ile z nich odpowiada za to samo (np. trzy wtyczki do koszyka, dwie do pól dodatkowych). Zajrzyj też do zapytań o czas generowania strony w narzędziu do monitoringu.
Jak naprawić: Zostaw jedną wtyczkę na funkcję, a logikę specyficzną dla sklepu (np. konfigurator, nietypowe ceny, reguły dostawy) przenieś do małego modułu w motywie lub własnej wtyczki. Usuwaj nieużywane wtyczki, nie tylko je wyłączaj.
Wdrożenie wprost na produkcji, bez środowiska stagingowego. Pierwszy test płatności albo aktualizacji robi się na żywym sklepie, przy klientach.
Jak wykryć: Zapytaj przed startem, czy istnieje kopia sklepu na osobnym adresie i na osobnej bazie. Jeśli wykonawca mówi, że „będzie robił ostrożnie”, to nie jest środowisko testowe.
Jak naprawić: Ustal staging jeszcze przed pierwszym commitem: osobna baza, osobne wtyczki płatnicze w trybie testowym, blokada indeksowania w robots.txt. Każdą większą zmianę i każdą aktualizację przechodzimy najpierw tam.
Kupiony motyw z marketplace jako fundament sklepu o nietypowych wymaganiach. Wygląda dobrze na demie, ale przy pierwszej potrzebie „dodajmy pole na NIP i inne reguły wysyłki” trzeba go przepisać, często razem ze zmianą całego motywu.
Jak wykryć: Zadaj pytanie, czy motyw ma child theme i ile modyfikacji poszło bezpośrednio w pliki motywu. Jeśli aktualizacja motywu grozi utratą zmian, to sygnał ostrzegawczy. Kolejny test: spróbuj dodać prostą zmianę na stagingu i sprawdzić, czy nadpisuje ją aktualizacja.
Jak naprawić: Motyw z marketplace ma sens przy małym sklepie o standardowych funkcjach. Jeśli sklep jest twoim głównym kanałem sprzedaży albo masz nietypowe procesy, taniej wychodzi lekki motyw dedykowany lub child theme na sprawdzonym szkielecie – mniej wtyczek, mniej łatek, prostsze aktualizacje.
Pomijanie wydajności na starcie. Sklep startuje „żeby działał”, a optymalizację odkłada się na potem – i potem nigdy nie ma na nią czasu, a ruch z reklam przepala się na wolnym ładowaniu.
Jak wykryć: Zmierzyć Core Web Vitals dla realnych użytkowników po dwóch–trzech tygodniach od startu i porównać z danymi z raportu Google. Sprawdź osobno karty produktów i listingi kategorii, bo tam siedzi największy problem.
Jak naprawić: Ustaw budżet wydajności przed startem: priorytet dla LCP na kartach produktów, kompresja i właściwe rozmiary obrazów, ograniczenie liczby skryptów zewnętrznych. Metodykę masz w dokumentacji Google o Core Web Vitals i w artykule web.dev.
Brak planu migracji danych przy przejściu z innej platformy. Produkty przechodzą, ale gubią się warianty, stany magazynowe, kategorie, adresy i historia zamówień – a stare adresy URL przestają działać.
Jak wykryć: Przed startem poproś o arkusz mapowania: stary identyfikator produktu, nowy, przypisanie kategorii, liczba wariantów, status magazynu. Jeśli wykonawca nie potrafi pokazać takiego pliku, migracja będzie ręczna i droga.
Jak naprawić: Zrób eksport danych z obecnej platformy zanim cokolwiek ruszysz, ustal mapowanie na stagingu i przetestuj na próbce kilkudziesięciu produktów. Zaplanuj przekierowania 301 dla usuniętych adresów i sprawdź je po publikacji.
Niedokończona konfiguracja poczty i DNS. Maile z potwierdzeniem zamówienia lądują w spamie, klient pisze na czacie „nie dostałem potwierdzenia”, a dział obsługi nie wie, ile zamówień przepadło.
Jak wykryć: Złóż testowe zamówienie na stagingu i na produkcji i sprawdź, gdzie trafia wiadomość – Gmail, Outlook, WP.pl. Sprawdź też rekordy SPF, DKIM i DMARC dla domeny wysyłającej.
Jak naprawić: Skonfiguruj wysyłkę przez dedykowany serwis transakcyjny albo poprawnie podpisany SMTP, ustaw rekordy SPF i DKIM, dodaj DMARC. Testuj na kilku skrzynkach przed startem, po zmianie hostingu rób to ponownie.
Wdrożenie WooCommerce to projekt z jasno policzalnym zakresem: liczba SKU, lista integracji, migracja danych i opieka po starcie. Największe różnice między ofertami nie dotyczą stawek, tylko tego, czego w danej wycenie nie ma – środowiska testowego, przekierowań, konfiguracji poczty albo przekazania dostępów. Zanim podpiszesz umowę, sprawdź pięć rzeczy: zakres w punktach, staging, właściciela domeny i hostingu, plan migracji i SLA. Jeśli któryś punkt nie ma odpowiedzi na piśmie, przyjmij, że nie będzie go w projekcie.
W 2025 roku lokalizacja rzadko przesądza o jakości, ale zmienia sposób pracy. Plusem lokalnego wykonawcy jest możliwość spotkania, szybkie przekazanie dostępu i łatwiejsze rozwiązywanie spraw, które trudno opisać mailem. Plusem firmy zdalnej bywa węższa specjalizacja, na przykład wyłącznie WooCommerce albo wyłącznie integracje z ERP. Ważniejsze od adresu są: zakres w umowie, środowisko testowe, SLA i to, czy dostaniesz dostępy na siebie.
Nie ma jednej stawki, bo cena zależy od trzech rzeczy: liczby SKU i wariantów, liczby integracji oraz tego, czy przenosisz dane z innej platformy. Dwie oferty na pozornie ten sam sklep potrafią różnić się kilkukrotnie – w jednej brakuje wariantów, migracji i szkoleń, w drugiej nie. Dlatego porównuj oferty pozycja po pozycji, a nie po cenie końcowej. Widełki w tej samej kategorii wielkości sklepu w Łodzi i u firm z innych miast są zbliżone; różnicę robi zakres, nie kod pocztowy.
Realistycznie licz od kilku do kilkunastu tygodni od briefu do startu. Najdłużej trwają rzeczy po stronie klienta: treści, zdjęcia, decyzje o dostawach i umowy z bramką płatniczą. Konfiguracja, makiety i testy da się zaplanować, ale brak danych produktowych potrafi zatrzymać projekt na tygodnie. Dlatego harmonogram warto rozpisać na etapy z terminami po obu stronach.
Bez utraty pozycji – nie da się obiecać. Da się natomiast zrobić migrację, która nie zniszczy ruchu: zachować strukturę adresów albo ustawić przekierowania 301, przenieść treści kategorii i opisów, utrzymać dane strukturalne produktów. Kluczowe jest etapowe przejście i testy na stagingu. Więcej o wyborze platformy piszemy w porównaniu PrestaShop czy WooCommerce.
Konkretne czasy reakcji i naprawy, kanał zgłoszeń, zakres aktualizacji WordPressa i WooCommerce, częstotliwość i miejsce backupów oraz zasady testowania ich odtworzenia. Dopisz też, co jest poza abonamentem – prace rozwojowe, nowe integracje, zmiany szablonów. Bez tego opieka sprowadza się do deklaracji dobrej woli.
Dla prostego sklepu o standardowych funkcjach często tak – pod warunkiem że pracujesz na child theme i nie dokładasz do niego dziesiątek wtyczek. Problem pojawia się, gdy potrzebujesz nietypowych reguł dostawy, konfiguratora albo niestandardowego koszyka: wtedy koszt nadpisania motywu bywa wyższy niż motyw dedykowany. Zawsze pytaj, czy aktualizacja motywu skasuje twoje zmiany.
Tak, ale to już projekt, a nie instalacja wtyczki. Potrzebny jest porządny hosting z odpowiednim zapleczem, cache na poziomie serwera, optymalny motyw i przemyślane wyszukiwanie. Bez tego listingi kategorii i wyniki wyszukiwania zaczną zwalniać. Punktem wyjścia jest wydajność, którą opisujemy w artykule Jak zoptymalizować prędkość sklepu WooCommerce.
Jeśli porównujesz oferty na sklep WooCommerce albo przejmujesz projekt po kimś innym, możemy przejrzeć zakres i powiedzieć, czego w nim brakuje. Napisz, na jakim etapie jesteś – odpowiemy konkretnie, bez sprzedażowego lania wody.