Programista WooCommerce w Szczecinie

Prowadzisz sklep WooCommerce i sprzedajesz ze Szczecina, do Niemiec po drugiej stronie Odry albo w całej Polsce. Buduję i naprawiam sklepy oparte o WordPress i WooCommerce tak, żeby checkout, płatności, dostawy i faktury działały zgodnie z tym, czego oczekuje polski kupujący, a sklep przetrwał aktualizacje Woo bez grzebania w plikach rdzenia.

Ta strona dotyczy jednej usługi, czyli programowania WooCommerce dla firm ze Szczecina i regionu zachodniopomorskiego. Lokalny kontekst pojawia się tu po to, żeby ustawić priorytety techniczne, a nie żeby udawać znajomość rynku.

#Programista WooCommerce dla sklepów ze Szczecina

Szczecin leży kilkanaście kilometrów od granicy z Niemcami, a port Szczecin-Świnoujście robi z miasta naturalny węzeł handlu i logistyki. To zmienia profil typowego sklepu, z którym pracuję. Sprzedawca z lewobrzeżnego Szczecina równie często wysyła paczkę do Pasewalku czy Berlina, co do Poznania, więc checkout musi obsłużyć równolegle polskiego i niemieckiego kupującego, dwie waluty, dwie logiki podatkowe i dwa zestawy oczekiwań co do płatności.

Konkretne braki, które najczęściej znajduję w istniejących sklepach WooCommerce z regionu:

• Brak BLIK i Przelewy24 jako domyślnych metod, przez co polski kupujący trafia na sam przelew tradycyjny albo kartę i porzuca koszyk. BLIK i P24 (lub PayU, Autopay) powinny być na górze listy, nie na końcu.
• Brak punktów odbioru InPost (Paczkomaty) w checkoucie. Dla zamówień krajowych to dziś domyślny wybór dostawy, a nie opcja dodatkowa.
• Faktura VAT generowana ręcznie albo wtyczką, która nie jest przygotowana na KSeF. Od 1 lutego 2026 obowiązek wystawiania faktur ustrukturyzowanych objął największych podatników, a od 1 kwietnia 2026 pozostałych płatników VAT, więc sklep musi umieć przekazać dane faktury do systemu zewnętrznego z numerem KSeF.
• Sprzedaż do Niemiec rozliczana tak samo jak krajowa, bez progu i procedury OSS dla VAT od sprzedaży wysyłkowej w UE.

#Co realizuję

• Dedykowany checkout: skrócona ścieżka, BLIK i Przelewy24/PayU/Autopay jako pierwsze metody, pole NIP do faktury, walidacja kodu pocztowego pod strefy dostawy
• Integracja punktów odbioru InPost (mapa Paczkomatów koszyku), Paczki Allegro, kurierów DPD i DHL ze strefami i regułami waga/wymiary
• Most do fakturowania: przekazanie zamówienia do systemu księgowego (Subiekt GT/nexo, Comarch, fakturownia.pl) i do KSeF, z numerem KSeF zapisanym przy zamówieniu
• Sprzedaż transgraniczna: druga waluta, ceny brutto zgodne z oczekiwaniem niemieckiego kupującego, obsługa VAT OSS dla wysyłki do UE
• Synchronizacja stanów i ofert z Allegro oraz integracje przez BaseLinker tam, gdzie sklep sprzedaje wielokanałowo
• Rozszerzenia WooCommerce REST API pod headless storefront, aplikację albo system magazynowy, bez modyfikacji rdzenia

#Rynek i zaplecze techniczne w Szczecinie

Szczecin nie jest już tylko stocznią i portem. Działa tu Klaster IT Pomorze Zachodnie skupiający blisko 90 firm z branży, z biurem w Technoparku Pomerania przy ulicy Cyfrowej. Zachodniopomorski Uniwersytet Technologiczny, który w maju 2026 obchodził 80-lecie, oraz Uniwersytet Szczeciński zasilają lokalny rynek programistów i specjalistów e-commerce. Dla sklepu to znaczy tyle, że stos technologiczny nie musi być zachowawczy: znajdziesz tu zespół utrzymujący headless storefront na Astro czy Next.js, a nie tylko klasyczny motyw na PHP.

Z drugiej strony duża część sklepów regionie to firmy handlowe i produkcyjne związane z portem i logistyką, dla których WooCommerce jest dodatkiem do istniejącego systemu ERP albo Subiekta, a nie sercem firmy. Tam priorytetem jest niezawodna synchronizacja stanów i poprawna faktura, nie efektowny frontend. Te dwa profile klienta wymagają innej architektury, więc pierwsze pytanie zawsze brzmi: czym dla Twojej firmy jest ten sklep.

Bliskość granicy ma jeszcze jeden praktyczny skutek. Sklep ze Szczecina, który chce sprzedawać przez Odrę, częściej niż sklep z głębi kraju potrzebuje od pierwszego dnia dwujęzycznego frontendu i niemieckiej ścieżki płatności, a nie dokłada tego po roku. Lepiej zaplanować to w architekturze na starcie niż przebudowywać checkout, gdy zamówienia z Niemiec zaczną przychodzić, bo dokładanie drugiej waluty i strefy OSS do dojrzałego sklepu jest droższe niż uwzględnienie ich w specyfikacji.

#Standardy techniczne

Stos sklepowy to WooCommerce na PHP 8.2 lub nowszym, z object cache na Redis, wyszukiwarką produktów wydzieloną z bazy przy większych katalogach i CDN przed warstwą statyczną. Rozszerzenia idą przez hooki action i filter oraz osobną wtyczkę funkcjonalną, z czytelną granicą między rdzeniem Woo, kodem wtyczki i kodem motywu. Procesy w tle (synchronizacja, e-maile, eksport do KSeF) obsługuje Action Scheduler, żeby checkout nie czekał na zewnętrzne API.

#Jak wygląda współpraca

Pracuję w krótkich iteracjach z demem na koniec każdego etapu, ale kolejność jest stała:

1. Audyt istniejącego sklepu: taksonomia produktów, ścieżka checkoutu, aktywne bramki, strefy dostaw, sposób wystawiania faktur, integracje z księgowością i Allegro, pomiar Lighthouse na najczęściej odwiedzanych stronach produktu i kategorii.
2. Specyfikacja: decyzje architektoniczne, wybór bramek i przewoźników, sposób przekazania danych do KSeF, granica między rdzeniem a kodem własnym, kryteria odbioru. Zatwierdzasz plan, zanim zacznie się kodowanie.
3. Implementacja w gałęziach funkcyjnych, zgodnie ze standardami kodowania WordPress i WooCommerce, z testami na ścieżkach płatności i zamówień.
4. Przegląd na środowisku testowym identycznym z produkcją: testujesz prawdziwy checkout, weryfikujesz integracje, zatwierdzasz do uruchomienia.
5. Wdrożenie i opieka: udokumentowany proces wydania z przetestowaną ścieżką wycofania, a po stabilizacji opcjonalny abonament utrzymaniowy.

#Typowe problemy, z którymi przychodzą sklepy z regionu

• Faktura nie trafia do KSeF albo dane są niekompletne (brak NIP nabywcy, zła stawka). Porządkuję zbieranie NIP w checkoucie i przekazanie zamówienia do systemu wystawiającego fakturę ustrukturyzowaną.
• Wysoki odsetek porzuceń na płatności, bo brakuje BLIK i Paczkomatów. Po dołożeniu obu metod ścieżka skraca się o kilka kroków, a porzucenia spadają.
• Rozjazd stanów magazynowych między sklepem, Allegro i magazynem. Buduję synchronizację z rozwiązywaniem konfliktów i logiem zmian, zwykle przez BaseLinker albo bezpośrednie API.
• Sprzedaż do Niemiec rozliczana błędnie pod VAT, bez progu OSS i bez poprawnych cen brutto. Konfiguruję drugą strefę podatkową i walutę.

#Czego możesz oczekiwać

Zamiast obietnic procentowych podaję mierzalne kryteria, które ustalamy na starcie i sprawdzamy po wdrożeniu: stabilny czas ładowania stron produktu i kategorii w polu Core Web Vitals, kompletna ścieżka koszyk → płatność → zamówienie → faktura → e-mail działająca na każdej aktywnej bramce, poprawne przekazanie faktury do KSeF z zapisanym numerem oraz zgodna z OSS sprzedaż do UE. Co dokładnie mierzymy, zależy od sklepu, dlatego liczby wpisujemy do specyfikacji, a nie do oferty.

#Bezpieczeństwo i obsługę wymagań RODO

Sklep przetwarza dane osobowe i dane płatnicze, więc bezpieczeństwo jest częścią architektury, nie dodatkiem. W praktyce oznacza to: parametryzację zapytań do bazy przeciw SQL injection, escapowanie wyjścia przeciw XSS, weryfikację nonce na formularzach, limitowanie prób na endpointach logowania i koszyka oraz reguły WAF dostrojone do typowych wektorów ataku na WordPress. Pod RODO porządkuję podstawę zbierania danych w checkoucie, retencję zamówień i zgody marketingowe, a płatności przechodzą przez bramkę zgodną z PCI DSS, żeby dane kart nie dotykały Twojego serwera.

#Wydajność i Core Web Vitals

Core Web Vitals wpływają na pozycję w Google i na konwersję, a strony WooCommerce psują je najczęściej na trzech polach: ciężki motyw, fragmenty koszyka blokujące cache oraz nieoptymalizowane zdjęcia produktów. Pracę zaczynam od pomiaru (Lighthouse plus profil WP-CLI i Query Monitor na realnych stronach), żeby znaleźć rzeczywisty bottleneck, zamiast dokładać kolejną wtyczkę cache. Dalej idzie optymalizacja ścieżki krytycznej, obrazy w AVIF/WebP z jawnymi wymiarami przeciw przesunięciom layoutu (CLS), ograniczenie JavaScriptu pod responsywność interakcji (INP) i edge caching tam, gdzie treść jest statyczna. Regresje wyłapuje pomiar w procesie wdrożeniowym.

#Pytania, które zadają firmy ze Szczecina

Czy przygotujecie sklep pod KSeF? Sklep WooCommerce nie wystawia faktur ustrukturyzowanych sam, robi to system księgowy albo dedykowana usługa. Moja rola to poprawne zebranie danych do faktury w checkoucie (w tym NIP) i przekazanie zamówienia do systemu, który wystawia fakturę w KSeF i zwraca jej numer, zapisywany przy zamówieniu. Konkretne narzędzie dobieramy do Twojej księgowości.

Sprzedajemy też do Niemiec, ogarniecie płatności i podatki? Tak. Konfiguruję drugą walutę i strefę podatkową, ceny brutto zgodne z oczekiwaniem niemieckiego kupującego, popularne tam metody (PayPal, karty, przelew), oraz obsługę VAT OSS dla wysyłki wewnątrz UE. Polskim kupującym zostawiam BLIK, Przelewy24 i Paczkomaty.

Czy modyfikujecie rdzeń WooCommerce? Nie. Customizacje idą przez hooki i osobną wtyczkę, żeby sklep przetrwał aktualizacje Woo. Granica między rdzeniem, wtyczką i motywem zapada na etapie architektury i jest opisana w runbooku.

Czy zoptymalizujecie istniejący wolny sklep? Tak, i zaczynam od pomiaru, nie od zgadywania. Profil Lighthouse plus Query Monitor wskazuje, czy problem to motyw, autoload optionów, wolne zapytania wtyczek, czy waga obrazów, i rozwiązuję go u źródła.

Jak wygląda przekazanie projektu? Dostajesz żyjącą dokumentację dla managera sklepu i programisty, runbook dla każdej bramki i integracji oraz sesję przekazania. Sklep może potem trafić do Twojego zespołu albo na opcjonalny abonament opieki.

#Lokalne SEO dla sklepu ze Szczecina

Sklep musi być znaleziony, więc SEO jest częścią architektury od pierwszego szkicu: czyste adresy URL, mapa XML, poprawne canonical i hierarchia nagłówków, dane strukturalne Product, Offer i FAQ na kartach produktu. Dla firmy z fizycznym adresem w Szczecinie dokładam dane LocalBusiness, spójność NAP i Google Business Profile, a dla sprzedaży krajowej i niemieckiej hreflang oraz osobne metadane dla każdej wersji językowej. Treść układam tak, żeby strona kategorii odpowiadała na realne zapytanie zakupowe, a nie była pustą listą produktów.

#Rozpocznij projekt

Jeśli chcesz omówić sklep WooCommerce, opisz krótko obecną sytuację, cel biznesowy i ograniczenia: co sprzedajesz, dokąd wysyłasz, jak dziś wystawiasz faktury i gdzie sklep boli. Na tej podstawie sprawdzam konfigurację, wskazuję ryzyka i proponuję praktyczny plan, niezależnie od tego, czy to nowy sklep, migracja do architektury headless, czy stałe wsparcie. Wycena jest indywidualna i zależy od zakresu ustalonego w audycie.