Biłgoraj nie zmienia praw WooCommerce, ale zmienia organizację projektu: domyślnie pracujemy zdalnie, a na miejsce przyjeżdżamy tylko wtedy, gdy to realnie skraca pracę — do serwera on-premise, integracji z lokalnym ERP albo na szkolenie zespołu. Poniżej rozkładamy wdrożenie i optymalizację WooCommerce na czynniki pierwsze: 9 etapów, budżet godzinowy i model wyceny, żebyś mógł porównać oferty i zobaczyć, za co płacisz. Zakres działań pokrywa Biłgoraj, Frampol, Zwierzyniec, Józefów, Krasnobród, Szczebrzeszyn, Tarnogród, Księżpol i Tereszpol. W jednym zdaniu: praca zdalna jako standard, rozliczenie godzinowe, zakres spisany w briefie i tolerancja 15% przed startem.
Obszar działania: Biłgoraj, Frampol, Zwierzyniec, Józefów, Krasnobród, Szczebrzeszyn, Tarnogród, Księżpol i Tereszpol. We wszystkich tych miejscowościach pracujemy w jednym modelu: zdalnie jako standard, dojazd tylko wtedy, gdy realnie skraca pracę. Każda godzina wyjazdu to koszt, który musi się obronić. Jeśli zadanie robi się w 2 h zdalnie, nie jedziemy na miejsce.
Typowe lokalne branże, z którymi się tu spotykamy, mają konkretne wymagania techniczne:
Kiedy dojazd jest uzasadniony: audyt serwera on-premise (brak dostępu zdalnego, pomiar dysku i backupu), integracja z lokalnym ERP działającym wyłącznie w sieci firmowej, szkolenie zespołu (2–4 h na miejscu zastępuje 3–4 spotkania online), uruchomienie odbioru osobistego i logistyki lokalnej — punkt wydania, godziny, kolejka zamówień.
Lokalne SEO opiera się na wizytówce Google (Google Business Profile) i na tym, czy sklep mówi to samo co wizytówka. Godziny otwarcia, adres punktu odbioru i informacja o dostawie lokalnej powinny być widoczne nie tylko w regulaminie, ale na karcie produktu i w koszyku — to element konwersji, nie przypis. Wizytówkę warto wspierać danymi strukturalnymi obsługiwanymi przez Google, a sam odbiór osobisty skonfigurować jako osobną strefę wysyłki — inaczej klient z Biłgoraja dostanie w koszyku stawkę kurierską. Sklepy z sąsiednich miejscowości opisujemy osobno, m.in. WooCommerce Frampol: organizacja projektu.
| Zadanie | Tryb pracy | Kiedy dojazd się opłaca |
|---|---|---|
| Konfiguracja sklepu, motyw, produkty, płatności | zdalnie | praktycznie nigdy — dojazd nie skraca tych prac |
| Audyt serwera on-premise | zdalnie + wizyta | brak dostępu zdalnego lub konieczny pomiar obciążenia dysku i backupu |
| Integracja z lokalnym ERP | zdalnie + wizyta | system dostępny tylko z sieci firmowej |
| Szkolenie zespołu | na miejscu | 2–4 h szkolenia zamiast 3–4 spotkań online |
| Odbiór osobisty i dostawa lokalna | wizyta | trzeba ustalić punkt wydania, godziny i obsługę zwrotów |
| Wizytówka Google i lokalne SEO | zdalnie | brak — wystarczy przekazanie danych |
Wybór platformy to nie kwestia gustu, tylko policzenia dwóch rzeczy: ile masz SKU z wariantami i ile zamówień dziennie ma obsłużyć sklep. Punkt odniesienia: WooCommerce działa komfortowo przy kilku do kilkunastu tysiącach SKU na poprawnie skonfigurowanym hostingu. Powyżej tego progu trzeba liczyć się z osobną pracą nad bazą i architekturą (indeksy, przeszukiwanie katalogu poza tabelami wpisy, cache dla zalogowanych), a nie tylko z „dokupieniem wtyczki”.
Kryteria decyzyjne, które realnie zmieniają budżet:
Koszty utrzymania liczy się rocznie: 8 wtyczek w abonamencie po 100–400 zł daje 800–3200 zł co roku, bez gwarancji, że któraś nie zmieni modelu licencjonowania. Jednorazowy własny moduł bywa tańszy w trzyletnim horyzoncie, ale wymaga kogoś, kto go utrzyma.
Kiedy nie warto migrować: gdy stara platforma ma poprawną bazę, a problemem jest wyłącznie szybkość lub UX. Wtedy taniej jest optymalizować — cache, obrazy, zapytania do bazy, sekcje na stronie głównej. Parametry szybkości warte pilnowania opisuje dokumentacja Core Web Vitals. Jeśli zastanawiasz się nad przeniesieniem sklepu z okolicy, punktem wyjścia jest taka sama analiza jak w wdrożeniach WooCommerce w Józefowie.
| Kryterium | WooCommerce wystarczy | Sygnał, że trzeba przeliczyć | Wpływ na budżet |
|---|---|---|---|
| SKU i warianty | do kilku–kilkunastu tys. SKU | katalog rośnie dalej lub ma tysiące wariantów | praca nad bazą i wyszukiwaniem: +20–60 h |
| Zamówienia dziennie | do ok. 200–300 | szczyt sezonowy powyżej tego progu | rozdzielenie zasobów, mocniejszy hosting |
| Sprzedaż B2B | grupy klientów + wtyczka cenowa | setki indywidualnych cenników | własny moduł: 40–120 h |
| Wielosklepowość | 1 sklep, 1 waluta | osobne sklepy lub waluty | dodatkowa konfiguracja i utrzymanie treści |
| Wielojęzyczność | 1–2 języki | 3 i więcej języków | wtyczka + treści + testy SEO |
| Utrzymanie | mało abonamentów | wiele płatnych wtyczek rocznych | 800–3200 zł rocznie w samych licencjach |
Wdrożenie rozbijamy na 9 etapów, żeby było widać, na co idą godziny:
Środowisko staging to nie luksus, a warunek bezpieczeństwa. Pracujemy na subdomenie z wyłączoną indeksacją, na kopii bazy produkcyjnej, z kluczami API w trybie sandbox. Procedura rollback: zrzut plików i bazy sprzed migracji, okno wdrożenia poza szczytem sprzedaży, a zamówienia złożone w trakcie — zebrane i przeniesione ręcznie. Bez tego nie ma jak cofnąć wdrożenia bez utraty zamówień.
Na koniec przekazujemy dokumentację: dostępy, mapa integracji, lista wtyczek z uzasadnieniem (każda wtyczka to ryzyko aktualizacji) i procedura backupu. Zakres i godziny pokazujemy w tabeli, a podobny układ znajdziesz w wdrożeniach WooCommerce w Zwierzyńcu.
| Etap | Zakres | Godziny (sklep prosty → rozbudowany) |
|---|---|---|
| 1. Audyt i brief | model sprzedaży, SKU, integracje | 6–12 h |
| 2. Hosting i staging | PHP, limity, cron, kopie | 4–8 h |
| 3. Motyw i szablony | karta produktu, koszyk, checkout, mobile | 12–30 h |
| 4. Produkty i warianty | import, atrybuty, stany | 10–60 h |
| 5. Płatności i dostawy | bramka, strefy, odbiór osobisty | 8–20 h |
| 6. Treści i SEO techniczne | URL, opisy, dane strukturalne, mapa | 10–40 h |
| 7. Testy | zamówienie end-to-end, faktura, zwrot | 8–20 h |
| 8. Migracja danych | produkty, klienci, przekierowania 301 | 6–40 h |
| 9. Start i monitoring | DNS, logi, kolejka e-maili | 4–10 h |
| RAZEM | sklep prosty do 300 SKU, 1–2 integracje | 60–100 h |
| RAZEM | sklep średni do 2000 SKU, 4–6 integracji | 120–200 h |
| RAZEM | sklep z ERP i wielojęzycznością | 250–400 h |
Nie wyceniamy „na oko”. Model jest arytmetyczny: stawka godzinowa × liczba godzin z briefu plus tolerancja 15% na rzeczy nieprzewidziane. Brief to dokument, nie rozmowa: liczba szablonów produktów, źródło danych (Excel, eksport z ERP, pliki od dostawcy), liczba zamówień miesięcznie, integracje, języki, sposoby dostawy i płatności oraz osoba po stronie klienta odbierająca prace. Bez tych danych nie podamy liczby, której potem obronimy.
Przed startem zapisujemy w umowie, co dzieje się przy przekroczeniu zakresu: informujemy, zanim godziny zostaną wypracowane, i pokazujemy, z czego wynikło. Jeśli nie masz dostępu do danych o ruchu i liczbie zamówień, wyceniamy wariant pesymistyczny albo prosimy o dostęp do analityki. Wycena „na telefon” kończy się albo dopłatami, albo pracą poniżej kosztu — jedno i drugie jest złe.
Osobno pokazujemy koszty jednorazowe i miesięczne, bo faktura za wdrożenie to nie całe TCO. Do miesięcznych dochodzą: VPS lub hosting (typowo 50–400 zł netto), licencje wtyczek premium i szablonu (najczęściej rozliczane rocznie) oraz opieka techniczna obejmująca aktualizacje, kopie i monitoring. Sklep bez opieki prędzej czy później zapłaci za to więcej przy pierwszej awarii.
Pracujemy zdalnie, a organizację projektu poza Biłgorajem opisujemy szerzej przy okazji wdrożeń i optymalizacji WooCommerce w Frampolu oraz wdrożeń WooCommerce w Zamościu.
| Zakres | Widełki netto | Główne czynniki wpływające na cenę |
|---|---|---|
| Wdrożenie sklepu | 8 000 – 25 000 zł | liczba szablonów produktów, migracja treści i zdjęć, integracje, wielojęzyczność, niestandardowy checkout |
| Optymalizacja szybkości i SEO technicznego | 2 000 – 6 000 zł | stan wyjściowy, liczba wtyczek, dostęp do serwera i CDN, budżet na infrastrukturę |
| Dedykowany moduł integracyjny | 1 500 – 5 000 zł | liczba pól i kierunków synchronizacji, jakość dokumentacji API po stronie systemu zewnętrznego |
Zaczynamy od pomiaru, nie od włączania kolejnej wtyczki. Punkt odniesienia: LCP poniżej 2,5 s, INP poniżej 200 ms, CLS poniżej 0,1 oraz TTFB na stronie produktu i kategorii w granicach 200–300 ms. Mierzymy na produkcji, na urządzeniu mobilnym, nie na biurowym laptopie z szybkim łączem. Progi i sposób interpretacji opisuje dokumentacja Web Vitals.
Cache stron ustawiamy z twardym wykluczeniem koszyka, kasy i strony „Moje konto”. To najczęstsza pułapka w WooCommerce — cache obejmujący koszyk potrafi pokazać klientowi zawartość cudzego zamówienia. Do tego cache obiektowy, Redis albo Memcached, dla zapytań do bazy.
Warstwa serwerowa: OPcache włączony, HTTP/2 lub HTTP/3, kompresja Brotli, CDN, obrazy w WebP/AVIF w poprawnych wymiarach (miniatura 300 px nie może ładować pliku 2000 px) i lazy loading poniżej pierwszej sekcji — obraz hero zostaje bez lazy loadingu, bo inaczej psuje LCP.
Baza danych to zwykle największe pole do zysku: nadmiarowe rekordy z autoload w tabeli wp_options, czyszczenie tabel Action Scheduler i wc_session, kontrola liczby wpisów w wp_postmeta. Włączamy HPOS (High-Performance Order Storage), czyli przechowywanie zamówień w dedykowanych tabelach zamiast jako wpisy — realny zysk widać na liście zamówień i w panelu przy kilku tysiącach zamówień.
Mity: „jedna wtyczka cache załatwi wszystko” (nie usunie wolnych zapytań), „im więcej wtyczek, tym więcej funkcji” (więcej zapytań i punktów konfliktu), „wystarczy zmienić hosting” (na źle napisanym szablonie szybszy serwer da kilka procent, nie zmianę klasy). Sposób pracy poza Biłgorajem opisujemy też przy optymalizacji WooCommerce w Józefowie i wdrożeniach WooCommerce w Zwierzyńcu.
| Metryka | Cel | Czym mierzyć |
|---|---|---|
| LCP | poniżej 2,5 s | PageSpeed Insights, DevTools, dane od realnych użytkowników |
| INP | poniżej 200 ms | DevTools (Performance), raporty z realnych sesji |
| CLS | poniżej 0,1 | PageSpeed Insights, DevTools |
| TTFB | 200–300 ms | zakładka Network → Timing, logi serwera, monitoring zewnętrzny |
Płatności online: Przelewy24, PayU, Autopay, tpay, Stripe. Różnią się nie tylko prowizją, ale też czasem wypłaty środków i prostotą konfiguracji. Nie podajemy stawek, bo zmieniają się co kwartał — pobierz aktualny cennik od operatora i policz koszt przy swojej średniej wartości zamówienia. Pytanie na start brzmi: czy operator obsługuje BLIK, płatności odroczone i zwroty z panelu, bo to oszczędza godziny obsługi po stronie twojego zespołu.
Kurierzy: InPost (Paczkomaty przez ShipX API), DPD, DHL. Typowy zakres integracji to automatyczne etykiety, aktualizacja statusów przesyłek i mapy punktów odbioru w koszyku. Przy wycenie ustal jedną rzecz: czy etykietę generuje sklep, czy pracownik klika w panelu kuriera. To różnica kilku minut na każdym zamówieniu, czyli przy 300 przesyłkach miesięcznie kilkunastu godzin pracy.
ERP i fakturowanie: Subiekt GT/nexo, Comarch Optima, Fakturownia, wFirma, BaseLinker. Najważniejsza decyzja przed kodowaniem to kierunek synchronizacji i źródło prawdy. Typowo stany i ceny płyną z ERP do sklepu, a zamówienia ze sklepu do ERP — i tylko jedna strona może być właścicielem stanu magazynowego, inaczej po miesiącu masz rozjazd i ręczną korektę. Dokumentację modułów i wymagań znajdziesz w dokumentacji WooCommerce.
Reguła decyzyjna: jeśli abonament wtyczki przekracza koszt jednorazowego modułu w 12–18 miesięcy, a moduł nie wymaga aktualizacji przy każdej zmianie WooCommerce — budujemy własny. Ryzyko, o którym trzeba powiedzieć wprost: wtyczki integracyjne są najczęstszą przyczyną konfliktów po aktualizacji WooCommerce i WordPressa. Testuj je na kopii przed produkcją, a nie w piątek po południu na żywym sklepie.
Szczegóły organizacji projektu poza Biłgorajem opisujemy przy okazji wdrożeń i optymalizacji WooCommerce w Szczebrzeszynie.
| Obszar | Co obejmuje wycena wdrożenia | Koszt odnawialny |
|---|---|---|
| Płatności | konfiguracja operatora, webhooki, zwroty, testy na produkcji | prowizja od transakcji, czasem abonament operatora |
| Kurierzy | API, etykiety, statusy przesyłek, mapa punktów w koszyku | abonament wtyczki lub utrzymanie własnego modułu |
| ERP / fakturowanie | mapowanie pól, kierunek synchronizacji, obsługa błędów | abonament, licencje API po stronie ERP |
Pierwszy tydzień po wdrożeniu to ostatni moment, w którym ustawienia SEO kosztują minuty. Po indeksacji każda poprawka oznacza czekanie na ponowne przetworzenie, a błędne adresy siedzą w wynikach tygodniami. Kolejność ma znaczenie: najpierw noindex, dopiero potem blokada w robots.txt — wpis w robots.txt odcina robotowi dostęp do strony, więc nie zobaczy on znacznika i nie zdejmie adresu z indeksu.
Lista do domknięcia w pierwszym tygodniu:
<a href>, nie generowane wyłącznie przez JavaScript.Sitemap: oraz Disallow dla admin-ajax.php, ?add-to-cart= i ?s=.Po 7 i 30 dniach sprawdzamy w Search Console raport błędów 404. Pierwszy przegląd łapie literówki w mapowaniu, drugi — adresy linkowane z zewnątrz. Równolegle PageSpeed Insights i dane z raportu użyteczności w Search Console. Core Web Vitals nie są osobnym projektem, tylko elementem widoczności: przy szablonie i kilkunastu wtyczkach to zwykle kwestia wyłączenia zbędnych skryptów i poprawy LCP na kartach produktu. Ten sam schemat stosujemy w mniejszych gminach — przykład: organizacja wdrożenia WooCommerce we Frampolu.
Pułapki po wdrożeniu rzadko wyglądają jak awaria. Wyglądają jak sklep, który działa — tylko codziennie trochę wolniej. Najczęstsze: wersja PHP starsza niż wymagana przez aktualne WooCommerce (działa do momentu, gdy wtyczka przestaje wspierać 7.4), backup, którego nikt nigdy nie odtworzył, i plik leżący na tym samym serwerze co sklep, niewywoływany cron WP (kolejki Action Scheduler rosną, maile z zamówieniami wychodzą z opóźnieniem), rosnąca tabela wc_session po botach i porzuconych koszykach oraz konflikt wtyczek po automatycznej aktualizacji — najczęściej między wtyczką płatności a wtyczką cache.
Diagnostyka w 10 minut: log błędów PHP na serwerze, Query Monitor (wolne zapytania, hooki, błędy), Health Check w trybie troubleshooting, jedno testowe zamówienie w tygodniu — najlepiej tanie, z realną płatnością i zwrotem — oraz podgląd kolejek Action Scheduler. Monitoring ustawiamy na uptime, czas odpowiedzi, błędy 5xx i zużycie CPU oraz RAM na VPS, z alertami na e-mail lub SMS. Backup w modelu 3-2-1 i obowiązkowy test odtworzenia raz na kwartał — backup, którego nie sprawdzono, nie istnieje.
| Objaw | Pierwsze narzędzie | Co sprawdzić |
|---|---|---|
| Długie dodawanie do koszyka | Query Monitor | Zapytania do wc_session i wc_cart, liczba hooków na stronie |
| Wolna strona zamówień w panelu | Query Monitor + log PHP | Meta-zapytania po _customer_user, brakujące indeksy |
| Maile z zamówieniami z opóźnieniem | Action Scheduler | Zaległe i nieudane zadania, wywołanie wp-cron |
| Skok liczby wierszy w wc_session | phpMyAdmin lub WP-CLI | Wzrost liczby wierszy wobec liczby zamówień |
| Biała strona po aktualizacji | Health Check + log PHP | Fatal error, konflikt wtyczki płatności z cache |
| Błędy 5xx w losowych momentach | Monitoring zewnętrzny | Korelacja z godziną crona i szczytem ruchu |
Zakres opieki jest stały i wypisany w umowie: aktualizacje WordPressa, wtyczek i szablonu (najpierw na środowisku testowym), backupy z testem odtworzenia, monitoring dostępności i wydajności, drobne zmiany w szablonie i konfiguracji oraz miesięczny raport z wykonanych prac i czasów reakcji. Bez tego raportu abonament zamienia się w płacenie za ciszę.
Proponowane SLA — liczby trafiają do umowy i są rozliczane:
| Model | Kiedy ma sens | Jak liczymy |
|---|---|---|
| Pakiet godzinowy | Sklep do ~50 zamówień miesięcznie, praca skokowa: wdrożenie zmian, sezon | Zakup puli godzin, rozliczenie w raporcie miesięcznym |
| Abonament miesięczny | Sklep ~1000 zamówień miesięcznie (ok. 33 dziennie), gdzie przestój kosztuje więcej niż opieka | Stała opłata: aktualizacje, monitoring, backup, pula drobnych zmian |
Brief ustalany na telefonie, bez spisanej listy funkcji
Jak wykryć: Po dwóch tygodniach pracy pojawiają się nowe wymagania, a zakres rozjeżdża się z ofertą i budżetem.
Jak naprawić: Spisz brief: liczba SKU i wariantów, płatności, dostawy (w tym odbiór osobisty), integracje, języki, docelowa liczba zamówień dziennie. Wycena to stawka × godziny z briefu.
Wdrożenie bezpośrednio na produkcji, bez środowiska staging
Jak wykryć: Testujesz na sklepie, do którego klienci już składają zamówienia, a każda poprawka to ryzyko przestoju.
Jak naprawić: Postaw kopię na subdomenie z własną bazą, testuj tam i wypchnij na produkcję po testach. Ustal procedurę rollbacku z kopią bazy i plików oznaczoną godziną.
Brak testu zamówienia end-to-end przed startem
Jak wykryć: Pierwsze prawdziwe zamówienie klienta jest jednocześnie pierwszym testem płatności i faktury.
Jak naprawić: Zrób pełną ścieżkę: zamówienie testowe, płatność w trybie sandbox, e-mail potwierdzający, faktura, etykieta kurierska, zwrot i korekta.
Płatne wtyczki kupowane na zapas
Jak wykryć: Roczny rachunek obejmuje kilkanaście abonamentów, z czego część nie jest używana w żadnym procesie.
Jak naprawić: Prowadź listę wtyczek z uzasadnieniem i kosztem rocznym. Zanim coś dokupisz, sprawdź, czy funkcji nie da się zastąpić konfiguracją lub własnym modułem.
Wycena jedną kwotą, bez rozbicia na etapy i godziny
Jak wykryć: Nie wiesz, ile godzin pochłonęła która część pracy ani co się stanie, gdy zakres się rozszerzy.
Jak naprawić: Wymagaj rozbicia na etapy z godzinami oraz zapisu, że przekroczenie tolerancji 15% jest komunikowane przed wykonaniem prac.
Optymalizacja szybkości bez pomiaru stanu wyjściowego
Jak wykryć: Nie masz zapisanych wyników sprzed zmian, więc po pracach nie da się powiedzieć, czy jest lepiej.
Jak naprawić: Zapisz Core Web Vitals i czas odpowiedzi serwera przed optymalizacją, potem porównaj te same metryki na tych samych szablonach.
Organizacja projektu waży więcej niż wybór motywu: brief, staging, testy end-to-end i dokumentacja to punkty, w których wdrożenie się udaje albo rozjeżdża. W Biłgoraju i okolicach domyślnie pracujemy zdalnie, a wyjazd planujemy tylko tam, gdzie realnie skraca pracę. Sklep prosty to 60–100 godzin, średni 120–200, rozbudowany z ERP 250–400 — te liczby pozwalają porównać oferty bez zgadywania. Podobnie układamy projekty w Frampolu i Krasnobrodzie.
Nie w każdym przypadku — domyślnie pracujemy zdalnie. Wyjazd ma sens przy konkretnych zadaniach: audyt serwera on-premise, integracja z lokalnym ERP, szkolenie zespołu albo uporządkowanie logistyki odbioru osobistego. Wtedy umawiamy dzień i zakres, a nie ogólne spotkanie zapoznawcze. Podobnie działamy w sąsiednich miejscowościach, np. przy wdrożeniach WooCommerce w Zwierzyńcu.
Prosty sklep do 300 SKU z jedną lub dwiema integracjami to zwykle 60–100 godzin pracy. Sklep średni (do 2000 SKU, 4–6 integracji) to 120–200 godzin, a rozbudowany z ERP i wielojęzycznością 250–400 godzin. Kalendarz zależy też od ciebie: treści, zdjęcia i dostępy do systemów zewnętrznych potrafią wydłużyć projekt bardziej niż sama konfiguracja.
Decydują cztery liczby: liczba SKU i wariantów, zamówienia dziennie, liczba integracji oraz to, czy sprzedajesz B2B z cenami indywidualnymi. WooCommerce działa komfortowo przy kilku–kilkunastu tysiącach SKU na poprawnie skonfigurowanym hostingu; powyżej tego progu trzeba liczyć się z pracą nad bazą i architekturą. Podstawę techniczną znajdziesz w dokumentacji WooCommerce.
Nie zawsze. Jeśli stara platforma ma poprawną bazę, a problemem jest tylko szybkość lub UX, taniej jest optymalizować niż migrować. Migracja ma sens, gdy platforma nie obsłuży twojego modelu sprzedaży, brakuje do niej specjalistów albo każda zmiana wymaga programisty. Przykład organizacji takiego projektu opisujemy przy wdrożeniach WooCommerce w Józefowie.
Typowy zakres to 2 000–6 000 zł netto, zależnie od liczby problemów i tego, czy trzeba przebudować szablony. Zaczynamy od pomiaru: Core Web Vitals i czas odpowiedzi serwera przed zmianami, żeby po pracach porównać liczby, a nie odczucia. Punkt odniesienia dla metryk znajdziesz na web.dev – Web Vitals oraz w dokumentacji Google o Core Web Vitals.
Wycena to stawka godzinowa pomnożona przez liczbę godzin z briefu. Przed startem przyjmujemy tolerancję 15% — jeśli prace mają ją przekroczyć, informujemy o tym przed wykonaniem, a nie na fakturze. Widełki orientacyjne netto: wdrożenie sklepu 8 000–25 000 zł, optymalizacja szybkości i SEO technicznego 2 000–6 000 zł. Dedykowany moduł integracyjny wyceniamy indywidualnie po briefie, bo jego koszt zależy od API systemu, z którym się łączy.
Tak, to element odbioru. Przekazujemy dostępy, mapę integracji, listę wtyczek z uzasadnieniem i kosztem rocznym oraz procedurę backupu i rollbacku. Bez tego każda kolejna zmiana — twoja albo innego wykonawcy — zaczyna się od zgadywania. Do tego dochodzi profil Google Business z godzinami i opcją odbioru osobistego; typy znaczników znajdziesz w przeglądzie danych strukturalnych Google.
Jeśli chcesz policzyć swój projekt, wyślij krótki brief: liczbę SKU, integracje i docelową liczbę zamówień dziennie. Odpowiemy zakresem z godzinami i kwotą, bez zobowiązania.