Programista WooCommerce w Liverpoolu

Sklep WooCommerce w Liverpoolu stoi obok katalogu części zamiennych dla operatora portowego z Peel Ports, sklepu merchu instytucji kultury przy Albert Dock z checkoutem w GBP i dostawą przez Royal Mail, hurtowni B2B z cenami według ról dla dystrybutorów z Merseyside oraz subskrypcji boxa z rozliczeniem cyklicznym przez Stripe dla marki z Baltic Triangle. To nie jest powód, żeby Woo udawało system rezerwacji rejsów ani platformę biletową Tate Liverpool. To powód, żeby checkout, bramki, VAT, dostawa i integracje magazynowe były napisane tak, jak oczekuje brytyjski dział compliance, magazyn w Speke albo Knowsley i zespół finansowy, który czyta wytyczne ICO, a nie tylko wynik Lighthouse na stronie kategorii.

WPPoland realizuje programowanie WooCommerce z polskiego zespołu seniorów dla firm w Liverpoolu i w szerszym regionie Merseyside, które mają siedzibę, magazyn albo klientów Wielkiej Brytanii. Zakres to checkout, Stripe, PayPal, strefy dostaw, logika podatkowa, hooki zamiast modyfikacji rdzenia i QA end-to-end na ścieżkach zamówień. Motyw WordPress, abonament opieki i kontakt są osobnymi tematami, z linkami na końcu.

#Programowanie WooCommerce dla sklepów Liverpoolu

Liverpool to port morski z międzynarodowym zasięgiem, silny sektor kultury i turystyki oraz ekosystem cyfrowy skoncentrowany wokół Baltic Triangle. Albert Dock, terminal rejsowy i Peel Ports generują inne wzorce ruchu niż produkcja medialna w MediaCityUK. Premiera wystawy w Tate Liverpool albo ogłoszenie nowej trasy promowej to skok odwiedzin w godzinach, nie w tygodniach. Sklep WooCommerce w tym układzie często nie jest „wizytówką z koszykiem”, tylko kanałem sprzedaży merchu wydarzeniowego, katalogiem B2B dla partnerów logistycznych albo subskrypcją dla marki z Liverpoolu Digital.

Brief od klienta w Liverpoolu często brzmi: „mamy Elementor i czterdzieści wtyczek, checkout trwa wieczność, PayPal działa losowo, a po aktualizacji Woo zamówienia wiszą na oczekującym”. To jest problem architektury checkoutu i webhooków Stripe, nie problem szablonu z marketplace. Typowy projekt, który trafia do seniorów Liverpoolu, nie brzmi „zróbcie sklep”. Brzmi: odziedziczony Woo z page builderem, Stripe skonfigurowany przez agencję trzy lata temu, magazyn klei statusy ręcznie po Black Friday, a dział prawny pyta, czy checkbox zgody w checkout i polityka prywatności da się obronić przed ICO. To jest dług integracyjny, który wychodzi w listopadzie albo w sezonie rejsów, nie w audycie SEO.

#Checkout, Stripe, PayPal i bramki brytyjskie

Sklep brytyjski zbiera płatności w GBP, czasem przez Stripe, PayPal, Apple Pay albo Google Pay. Webhooki bramki i status zamówienia muszą przeżyć aktualizację WooCommerce i patch wtyczki płatności. W Liverpoolu do Stripe dochodzi PayPal - metody, których kupujący w Wielkiej Brytanii oczekują w kasie, nie ciekawostka z ulotki integratora.

Przykład z audytu: zamówienie opłacone przez Apple Pay, a w panelu WooCommerce wciąż „oczekujące na płatność”, bo webhook Stripe nie dotarł po patchu wtyczki albo bo środowisko testowe i produkcja miały różne URL webhooków. To nie jest błąd UX. To incydent operacyjny, który w Black Friday, w szczycie sezonu rejsów albo w tygodniu premiery wystawy w Albert Dock, kosztuje więcej niż w styczniu, bo magazyn wysyła ręcznie albo anuluje zamówienia, które klient już opłacił.

Co wpisujemy w runbook bramki:

WooCommerce Blocks Checkout ma sens, gdy checkout ma być lekki i spójny z motywem blokowym. Klasyczny shortcode checkout zostaje, gdy odziedziczona warstwa pól i integracji jest zbyt kosztowna do migracji przed sezonem rejsów. Decyzja trafia do pisemnego kompromisu technicznego, nie do mody na bloki.

Skrypt bramki Stripe nie może blokować LCP na stronie checkout. Ładujemy go po interakcji albo z defer, testujemy na stagingu z tym samym CDN co produkcja. Właściciel sklepu z Baltic Triangle nie akceptuje argumentu „strona produktu jest szybka”, kiedy checkout na mobile wisi trzy sekundy przed polem karty albo przyciskiem Apple Pay.

Integracja PayPal Express wymaga osobnej ścieżki testowej. Klient płaci w oknie PayPal, a Woo musi dostać potwierdzenie w czasie, który nie pozostawia zamówienia w limbo. W runbooku jest timeout, retry i alert, gdy webhook nie dotrze w ustalonym oknie. Magazyn nie powinien pakować paczek na podstawie „klient twierdzi, że zapłacił”.

#VAT brytyjski, faktury i dostawa po Wielkiej Brytanii

Brytyjski sklep WooCommerce musi umieć VAT krajowy (20% stawka standardowa, 5% obniżona, 0% zero-rated tam gdzie przepisy pozwalają), obsługę sprzedaży do Irlandii Północnej i do UE po Brexicie oraz OSS tam, gdzie sprzedaż transgraniczna wymaga scentralizowanej deklaracji. Pola VAT number w checkout B2B, numer faktury w eksporcie do Xero albo Sage i zgodność z wymogami HMRC to decyzje w wtyczce checkoutu i integracji, nie w motywie. Making Tax Digital dotyczy księgowości po stronie klienta, ale eksport zamówień z Woo musi dostarczać dane, które księgowość może wciągnąć bez ręcznego przepisywania.

Dostawa w Liverpoolu to nie jedna stawka „Wielka Brytania”. Klienci oczekują Royal Mail, DPD, Evri albo Parcelforce, czasem odbioru w punkcie locker. Kalkulator wysyłki musi liczyć wagę, wymiary i strefy (Liverpool i Merseyside, reszta Anglii, Szkocja, Walia, Irlandia Północna, wyspy, UE) bez trzydziestu ręcznych reguł w panelu, które nikt nie aktualizuje po zmianie cennika przewoźnika. Integracja API przewoźnika dostaje log błędów i test na stagingu z adresem testowym, nie tylko „działa u mnie na localhost”.

Waluta GBP jest domyślna, ale sklepy z Liverpoolu obsługują też turystów z UE i klientów B2B z zagranicy. Wielojęzyczność wymaga osobnej decyzji: czy checkout w angielskim i niemieckim idzie przez te same bramki, czy pola adresowe mają walidację kodu pocztowego per kraj. Kampania w funtach bez poprawnego VAT na produkcie cyfrowym albo bez OSS dla klienta z Niemiec kończy się porzuconymi koszykami i pytaniami od księgowości, których analytics nie wyjaśni bez nagrania sesji.

#Liverpool: Baltic Triangle, port i sezon rejsów

Liverpool nie jest Manchesterem ani Londynem. Tu liczy się Baltic Triangle między centrum a dokami, Liverpool Digital, sektor morski przy Mersey, Albert Dock i Knowledge Quarter. Te osie ustawiają priorytety techniczne dla sklepu, który ma działać w Liverpoolu, a nie tylko nosić to w tytule strony usługowej.

#Baltic Triangle i sklepy z ekosystemu tech

Wokół Baltic Triangle i Liverpool Digital siedzą startupy, agencje kreatywne i marki D2C, które testują produkty na rynku brytyjskim przed ekspansją. WooCommerce w Liverpoolu nie wystawia certyfikatu ISO. Sklep merchu firmy z Baltic Triangle, która ma landing korporacyjny i osobny sklep subskrypcyjny, musi przeżyć aktualizację wtyczki płatności w tym samym tygodniu, w którym compliance pyta o hosting w UK i retencję logów. Awaria checkoutu po patchu cache albo regresja w mailach transakcyjnych boli w tygodniu demo day, nie w sierpniu.

#Sektor morski i sklepy B2B

Sektor morski w Liverpoolu to operatorzy logistyczni, agencje żeglugowe, firmy cargo i podmioty obsługujące łańcuch dostaw przez port na Mersey. Ich sklepy WooCommerce muszą obsługiwać ceny według ról, minimalne wielkości zamówień, procesy zapytań ofertowych i dedykowane portale dla kont klientów biznesowych. Formularz zamówienia B2B zbierający dane kontaktowe pod UK GDPR, integracja z CRM i eksport do ERP to decyzje w wtyczce, nie w motywie. Motyw, który nie wytrzyma skoku zamówień po ogłoszeniu nowej trasy w szczycie sezonu, produkuje incydent operacyjny, nie „drobny ticket po weekendzie”.

#Sezon rejsów i zamrożenie wdrożeń

Od wiosny do jesieni ruch na sklepach z merchu turystycznego, produktami wydarzeniowymi i lokalnymi specjałami w Liverpoolu rośnie wielokrotnie. Albert Dock, terminal rejsowy i wydarzenia w Tate Liverpool to nie abstrakcyjne nazwy w stopce - to osobne landingi, osobne strefy dostaw i osobne formularze leadów, które muszą działać jednocześnie. Awaria po aktualizacji wtyczki cache albo regresja w WPML boli w lipcu, kiedy każda godzina przestoju to zamówienie, które poszło do konkurencji.

Runbook developmentu dla klientów Liverpoolu ma wpisane zamrożenie wdrożeń produkcyjnych na szczyt sezonu rejsów, zwykle od maja do września, z wyjątkiem łatek krytycznych bezpieczeństwa przechodzących przez środowisko testowe i okno nocne. Aktualizacje planowe idą w październiku albo w lutym, kiedy ruch spada, a zespół redakcyjny ma czas na testy. Kto robi „drobny patch checkoutu Stripe” w sobotę lipca, uczy się tego na własnej skórze, kiedy webhook zwraca błąd, a magazyn ma pełną kolejkę paczek.

#Instytucje kultury i sklepy wydarzeniowe

Instytucje kultury w Liverpoolu (muzea, galerie, festiwale, obiekty dziedzictwa UNESCO) mają inny profil niż firma logistyczna z portu. Więcej treści wydarzeniowych, więcej materiałów multimedialnych, więcej pytań o dostępność publicznego sektora i mniej o integrację z systemem magazynowym. WooCommerce w tym środowisku to sklep merchu wystawy, kalendarz wydarzeń z produktami limitowanymi albo strona fundacji, która zbiera darowizny i musi respektować UK GDPR w formularzach. Premiera wystawy w Tate Liverpool to skok ruchu w godzinach. Checkout, który pada w pierwszych pięćdziesięciu minutach, to utracone przychody i reputacja u partnerów.

#UK GDPR, ICO i hosting w Wielkiej Brytanii

Po stronie brytyjskiej klient pyta o coś innego niż polski zespół domyślnie zakłada: gdzie leżą dane po Brexicie, czy serwer jest „w UK albo przynajmniej w EOG”, jak długo trzymamy logi, kto jest administratorem danych, czy mamy Data Processing Agreement. Te pytania trzeba umieć obsłużyć procesem, nie sloganem o „zgodności z GDPR”.

#UK GDPR i ICO

Po Brexicie Wielka Brytania zachowała własną wersję RODO, powszechnie nazywaną UK GDPR, oraz Data Protection Act 2018. Information Commissioner’s Office (ICO) nadzoruje zgodność. Dla WooCommerce w Liverpoolu wynika z tego konkretny zakres developmentu: lista podprocesorów (host, CDN, poczta, analityka, bramka płatności), umowa powierzenia tam, gdzie agencja przetwarza dane, procedura naruszenia w 72 godziny, minimalizacja danych w checkout, polityka prywatności zgodna z art. 13 UK GDPR.

Development nie zastępuje DPO klienta. Dostarcza konfigurację techniczną, którą właściciel może opisać w dokumentacji. Nikt po stronie agencji nie podpisuje się pod „jesteście GDPR-compliant, bo macie WAF”. ICO publikuje wytyczne na ico.org.uk; runbook projektu powinien być z nimi zgodny co do tego, co agencja dokumentuje, a co zostaje po stronie administratora danych.

Co wpisujemy w brief i w kod:

• Checkout zbierający dane kupującego dostaje jawną podstawę prawną, checkbox zgody tam, gdzie consent jest wymagany, i minimalizację pól.
• Wtyczki consent (CookieYes, Complianz, podobne popularne w Wielkiej Brytanii) konfigurujemy tak, żeby skrypty marketingowe i analityczne nie ładowały się przed akceptacją.
• Polityka prywatności i cookie policy są szablonami z polami, nie blokami, które redaktor może usunąć z drzewa.
• Integracje z ERP, magazynem i bramką Stripe dostają dokumentację przepływu danych: co trafia do systemu zewnętrznego, jak długo, kto jest administratorem.

#Hosting w UK i jurysdykcja danych po Brexicie

Dane osobowe pod UK GDPR ciągną pytanie: w której jurysdykcji stoi serwer. AWS w Londynie (eu-west-2), hosting u brytyjskiego providera (Krystal, 20i, SiteGround UK), Hetzner w Falkenstein (Niemcy, EOG) albo DigitalOcean w Londynie to różne odpowiedzi dla compliance officer. Ashburn albo Hillsboro to Stany i zwykle veto bez Standard Contractual Clauses albo innej podstawy transferu.

Pytanie „czy hosting jest w Liverpoolu” wraca rzadziej niż „czy w UK”. Odpowiedź operacyjna jest dwuczęściowa. Jurysdykcja: UK albo EOG, kopia nie wyjeżdża nocą na bucket w regionie US bez uzgodnienia. Latencja: origin w UK plus CDN z terminałem TLS w UK zwykle wystarcza dla użytkowników Liverpoolu i na całym terytorium Wielkiej Brytanii. Rozmowa o hostingu w onboardingu jest merytoryczna, nie wizerunkowa.

Backupy muszą trzymać tę samą jurysdykcję co produkcja. Jeśli produkcja stoi w Londynie, a backup ląduje w Virginii, compliance officer ma powód do pytania. Konfiguracja backupów WordPressie (UpdraftPlus, WPVivid, backup na poziomie hostingu) jest dokumentowana w runbooku wraz z regionem docelowym.

#Hooki WooCommerce zamiast modyfikacji rdzenia

Sklep w Liverpoolu musi przetrwać aktualizacje WooCommerce co kwartał. Customizacje idą przez udokumentowane hooki action i filter, plus podział na własną wtyczkę checkoutu i motyw tam, gdzie powinno. Modyfikacje plików rdzenia nie są wykonywane.

Granica jest prosta i zapisana w runbooku. Motyw umie pokazać. Wtyczka umie wiedzieć. Logika cen B2B, reguły dostaw per strefa, endpoint REST dla panelu magazynu, mapowanie webhooków Stripe: to wtyczka. Kolory, siatka, wzorzec hero z widokiem na Mersey: to motyw. Jeśli po zmianie motywu znika kalkulator wysyłki albo przycisk Apple Pay, architektura była zła.

Porównanie warstw przy kickoffie:

Własna wtyczka ma własny prefix, autoload PSR-4, plik główny z nagłówkiem Plugin Name i wersją semver oraz testy tam, gdzie logika liczy (mapowanie stawek VAT, walidacja kodu pocztowego UK, idempotencja webhooków). Logika biznesowa nie trafia do functions.php motywu, bo functions.php umiera razem z motywem, a firma w Liverpoolu zmienia partnera brandingowego częściej niż model checkoutu.

#B2B, subskrypcje i złożone katalogi

Firmy w Liverpoolu regularnie zgłaszają się z tymi problemami:

• Zgodność podatkowa w wielu jurysdykcjach: automatyczne obliczanie VAT, obsługa sprzedaży transgranicznej do UE po Brexicie (OSS tam gdzie wymagane) i generowanie zgodnych faktur per jurysdykcja.
• Złożone konfiguracje produktów z setkami wariantów: niestandardowe typy produktów z logiką warunkową, kalkulacją cen w czasie rzeczywistym i wizualnymi konfiguratorami obsługującymi tysiące kombinacji SKU bez degradacji wydajności.
• Wskaźniki porzucania koszyka powyżej średniej branżowej: odzyskiwanie exit-intent, trwałe sesje koszyka, sekwencje e-mail remarketingowych i layouty checkout testowane A/B.

WooCommerce Subscriptions i systemy członkowskie z rozliczeniami cyklicznymi, bramkami do treści, katalogami członków i wielopoziomowym dostępem wymagają osobnego runbooku bramek. Subskrypcja, która nie odnawia się po patchu wtyczki płatności, to churn i rozmowa z działem prawnym, nie ticket supportu.

Funkcjonalność B2B: ceny według ról, minimalne wielkości zamówień, procesy zapytań ofertowych i dedykowane portale do zarządzania kontami klientów biznesowych. Operator portowy z Merseyside, który sprzedaje części zamienne partnerom w całej Europie, potrzebuje checkoutu, który rozróżnia klienta B2B z numerem VAT od klienta detalicznego bez ręcznej interwencji w panelu.

#Przypadek: webhook Stripe po patchu wtyczki zostawił zamówienia w limbo

Sklep merchu instytucji kultury przy Albert Dock, checkout w GBP przez Stripe, integracja z magazynem przez REST. W kolejce do produkcji leżała aktualizacja wtyczki płatności plus patch cache, „drobny, na żywo, bo to tylko security fix”.

Na środowisku testowym, sklonowanym z produkcji razem z Redisem i z tym samym URL webhooków, zamówienie testowe przeszło płatność kartą, ale status w Woo zostawał „oczekujące na płatność”. Przyczyna: zmiana endpointu webhooków po patchu, stary handler w wtyczce nie logował idempotencji, a CDN trzymał odpowiedź 200 bez przekazania do PHP. Na produkcji ten sam zestaw poszedłby w piątek wieczorem przed weekendem wydarzeń. Magazyn wysłałby ręcznie albo anulował zamówienia, które klient już opłacił.

środowisko testowe zatrzymał promocję. wycofanie zmian na kopii testowej potwierdził, że sama wtyczka cache jest niewinna, gdy handler webhooków nie zapisuje payment_intent. Wtyczka checkoutu dostała poprawkę, checklista regresji (koszyk, płatność, webhook, mail, eksport magazynu, zwrot) przeszła, dopiero potem produkcja. Nie ma tu nazwy firmy, bo to kształt zdarzenia, nie case study z logotypem. Jest mechanizm: najpierw kopia, potem produkcja. Bez kopii zostałby post-mortem i rozmowa z compliance o danych kupujących.

Ten sam kształt wraca przy wtyczkach etykiet Royal Mail, przy checkoucie, który po aktualizacji gubi stawkę VAT, i przy „drobnej” aktualizacji SEO, która nadpisuje robots i wycina panel partnera B2B z indeksu. Liverpool nie wybacza tego ciszej niż inny rynek. Wygląda to gorzej, bo obok siedzi ktoś, kto pyta o UK GDPR, o numer VAT albo o slot w kalendarzu sezonu rejsów.

#Wydajność checkoutu i Core Web Vitals

Szybkość to przewaga konkurencyjna w Liverpoolu. Badania konsekwentnie pokazują, że opóźnienia rzędu setek milisekund mierzalnie obniżają wskaźniki konwersji w handlu elektronicznym. Nasze podejście do inżynierii wydajności sklepów WooCommerce obejmuje:

• Optymalizacja zasobów: obrazy przetwarzane przez proces budowania generujący responsywne srcset w formatach WebP i AVIF. CSS purgowany, dzielony per route i inlinowany dla treści above-the-fold. JavaScript tree-shaken, code-split i ładowany dynamicznymi importami.
• Architektura cachowania: wielowarstwowe cachowanie: cache przeglądarki, CDN (Cloudflare), cache aplikacji (Redis), cache zapytań do bazy (transienty z inteligentną invalidacją). Koszyk i checkout nie trafiają do pełnego page cache.
• Optymalizacja sieci: HTTP/3 z QUIC, kompresja Brotli, hinty preconnect, dns-prefetch i priorytetyzacja zasobów.
• Optymalizacja renderowania: inlining krytycznego CSS, asynchroniczne ładowanie stylów, lazy loading obrazów i iframów, triggery animacji oparte na Intersection Observer.

Każda decyzja wydajnościowa jest oparta na danych. Mierzymy przed i po na realnych URL-ach produktu, kategorii i checkoutu, dokumentujemy wpływ i dołączamy baseliny wydajności do dokumentacji projektu. INP psuje się od skryptów czatu, od playera wideo i od tag managera, który marketing dodał poza ticketingiem. Development, który nie widzi GTM, będzie gonić „optymalizację obrazków” w nieskończoność.

Dla sklepu z merchu wydarzeniowego albo B2B w Liverpoolu liczy się czas do pierwszego bajtu z sieci w całej Wielkiej Brytanii, nie tylko z telefonu w centrum. Monitoring z jednego regionu USA kłamie. Punkt pomiaru w UK albo przynajmniej w EOG jest częścią kontraktu operatorskiego, nie dodatkiem.

#Proces realizacji od audytu do przekazania

Każdy projekt w Liverpoolu realizujemy według ustrukturyzowanego procesu minimalizującego ryzyko i maksymalizującego transparentność:

1. Odkrywanie i audyt: przeglądamy architekturę obecnego sklepu, strukturę katalogu, dane analityczne i cele biznesowe. Dokumentujemy dług techniczny, identyfikujemy szybkie wygrane i definiujemy mierzalne kryteria sukcesu zanim napiszemy pierwszą linię kodu.
2. Specyfikacja techniczna: na podstawie audytu tworzymy szczegółową specyfikację obejmującą decyzje architektoniczne, wybory technologii, harmonogram, kamienie milowe i budżet. Zatwierdzasz plan zanim rozpoczną się prace programistyczne.
3. Zapewnienie jakości: każdy element pracy przechodzi przez przegląd kodu, testy automatyczne, testy w różnych przeglądarkach, walidację dostępności i pomiar wydajności względem ustalonych budżetów, zanim trafi na środowisko testowe.
4. Launch i przekazanie: obsługujemy zmiany DNS, konfigurację SSL, rozgrzewanie cache’u, weryfikację przekierowań i konfigurację monitoringu. Po uruchomieniu zostajemy w gotowości przez 72 godziny do natychmiastowego rozwiązywania problemów.
5. Wsparcie po uruchomieniu: po początkowym okresie stabilizacji przechodzimy do bieżącego wsparcia albo przekazujemy runbook zespołowi klienta.

przegląd kodu na każdej gałęzi funkcyjnej, środowisko testowe z tym samym stosem co produkcja i pisemny zapis decyzji architektonicznych to standard, nie dodatek. Sklep może następnie trafić do twojego zespołu albo na opcjonalny abonament opieki technicznej WordPress w Liverpoolu.

#Integracje magazynowe, ERP i headless tam gdzie ma sens

Rozszerzenia WooCommerce REST API do headless commerce, aplikacji mobilnych, systemów POS i integracji marketplace z uwierzytelnianiem OAuth 2.0 wchodzą do zakresu wtedy, gdy storefront tego faktycznie potrzebuje. Headless nie jest domyślną odpowiedzią. Jeśli redakcja pracuje w Gutenbergu, a problemem jest wolny checkout, naprawiamy checkout, nie budujemy Next.js od zera.

Integracja z ERP (Xero, Sage, NetSuite), magazynem (ShipStation, Linnworks) albo fulfilmentem wymaga dokumentacji przepływu danych: co trafia, kiedy, w jakim formacie, co się dzieje przy błędzie. Webhook z magazynu, który nadpisuje status zamówienia bez logu, to incydent, który wychodzi w Black Friday, nie w testach.

Personalizacja procesów zarządzania zamówieniami: automatyczne przejścia statusów, niestandardowe statusy, powiadomienia e-mail, generowanie listów przewozowych i integracje z magazynami. Tworzenie kalkulatorów wysyłki ze stawkami strefowymi, regułami waga/wymiary, integracjami API przewoźników (Royal Mail, DPD, Evri) i śledzeniem w czasie rzeczywistym.

#Rodzeństwo w Wielkiej Brytanii

Ten sam model WooCommerce działa w innych brytyjskich miastach, z tym samym runbookiem i innym kontekstem lokalnym:

• Programista WooCommerce w Manchesterze
• Programista WooCommerce w Leeds
• Programista WooCommerce w Londynie

Powiązane usługi w Liverpoolu:

• Programista WordPress w Liverpoolu
• Opieka techniczna WordPress w Liverpoolu

#Jak zaczynamy, bez cennika na stronie

Zakres, harmonogram i cena są indywidualne i lądują w umowie przed startem. Na tej stronie nie ma tabeli pakietów i nie ma podziału płatności na transze procentowe. Krótki opis sklepu, stacku, bramek, hostingu i tego, czy jest środowisko testowe, wystarczy, żeby zaproponować audyt checkoutu.

Kontakt: formularz. W zgłoszeniu przydaje się lokalizacja hostingu, lista wtyczek albo dostęp do stagingu, oraz informacja, czy sklep musi zostać w UK albo w EOG. Z tego powstaje plan: co naprawiamy w checkoutu, jakie bramki testujemy, jakie integracje magazynowe dokumentujemy i jakie kryteria odbioru obowiązują przed wdrożeniem.

WooCommerce w Liverpoolu ma sens, gdy sklep już niesie przychód albo ma go nieść po migracji z platformy, która nie skaluje się z katalogiem. Gdy trzeba go dopiero zbudować od zera bez modelu biznesowego, wracamy do programowania WordPress w Liverpoolu. Gdy trzeba go utrzymać przy checkoucie w GBP, formularzach pod UK GDPR i hostingu w Wielkiej Brytanii, zostajemy przy tym, co ta strona opisuje: hooki zamiast rdzenia, runbook bramek, QA end-to-end i proces, który przeżyje sezon rejsów.