Programista WooCommerce w Krakowie

#Krakowska marka, która sprzedaje dalej niż Kraków

Najciekawsze sklepy WooCommerce w Krakowie nie obsługują klienta z sąsiedniej dzielnicy, tylko sprzedają markę na wynos: do Warszawy, do Berlina, do kogoś, kto zabrał ze sobą wspomnienie z wakacji i chce je zamówić spod Sztokholmu. Palarnia kawy, która pali pod Wieliczką, a wysyła paczki do Niemiec i Skandynawii. Marka kosmetyków naturalnych z etykietą po polsku i po angielsku. Studio ceramiki, które połowę obrotu robi na klientach anglojęzycznych, bo estetyka rozchodzi się szybciej niż język. Dla takich marek sklep nie jest wizytówką w internecie, tylko główną linią sprzedaży, i to on decyduje, czy zamówienie z zagranicy w ogóle dojdzie do końca.

To zmienia charakter pracy programisty. Sklep firmowy z lokalną obsługą można postawić na gotowym motywie i zestawie wtyczek. Marka, która sprzedaje bezpośrednio do konsumenta w trzech strefach walutowych i dwóch reżimach podatkowych, potrzebuje kogoś, kto rozumie, co się dzieje między kliknięciem “kupuję” a paczką na taśmie u kuriera. My tę część bierzemy na siebie, a stronę treściową i markową prowadzimy równolegle z zespołem od programisty WordPress w Krakowie, bo sklep i witryna rządzą się innymi prawami.

#Sprzedaż bezpośrednia do klienta, a nie do pośrednika

Model D2C, czyli sprzedaż bezpośrednio do konsumenta z pominięciem sieci i marketplace’ów, wygląda z zewnątrz prosto: postaw sklep, wrzuć produkty, włącz płatności. Trudność zaczyna się przy powtarzalności. Marka konsumencka żyje z tego, że klient wraca, więc sklep musi umieć rozpoznać wracającego, pamiętać jego adres i preferencje, zaproponować to, co pasuje do poprzedniego zamówienia, i nie zmuszać go do zakładania konta od zera przy każdej wizycie. To nie jest kwestia jednej wtyczki, tylko przemyślanej ścieżki, w której każdy zbędny ekran między produktem a płatnością to procent utraconej sprzedaży.

Druga rzecz, którą marki D2C zaniedbują, to spójność koszyka z rzeczywistością magazynu. Klient, który dodał do koszyka ostatnią sztukę limitowanej serii, a przy płatności dowiaduje się, że jej nie ma, drugi raz nie wróci. W sklepach z małymi seriami, typowych dla krakowskiego rękodzieła i marek producenckich, stan magazynowy musi być wiarygodny w czasie rzeczywistym, nie synchronizowany raz na dobę. Budujemy to od strony WooCommerce tak, żeby rezerwacja stanu przy checkoutcie była twarda, a nie orientacyjna, bo dla marki z limitowanym asortymentem błąd w dostępności boli bardziej niż wolniejsza strona.

#Subskrypcja i sprzedaż cykliczna: model, który się nie kończy na zamówieniu

Coraz więcej krakowskich marek konsumenckich odkrywa, że najzdrowszy przychód to ten, który wraca sam. Kawa co miesiąc, kosmetyk w cyklu, pudełko z rękodziełem w prenumeracie. Problem w tym, że sprzedaż cykliczna to zupełnie inna bestia niż sprzedaż jednorazowa, a większość sklepów wchodzi w nią, doklejając wtyczkę i licząc, że reszta ułoży się sama.

Zamówienie jednorazowe kończy się na potwierdzeniu. Subskrypcja w tym momencie dopiero się zaczyna. Trzeba obsłużyć cykl odnowienia, a przy nim najtrudniejszy fragment całej układanki: nieudaną płatność. Karta wygasła, bank odrzucił transakcję, na koncie zabrakło środków. Dobrze zbudowany sklep próbuje ponownie według sensownego harmonogramu, wysyła klientowi uprzejme przypomnienie o aktualizacji karty i dopiero po serii nieudanych prób zawiesza subskrypcję, zamiast po cichu ją skasować i stracić lojalnego klienta na pierwszej usterce technicznej. Do tego dochodzi pauza na wakacje, zmiana planu, zmiana częstotliwości i rezygnacja, która musi być łatwa, bo utrudnianie odejścia to najkrótsza droga do obciążenia zwrotnego i złej opinii.

W praktyce oznacza to logikę, którą trzeba przetestować na scenariuszach, a nie tylko na szczęśliwej ścieżce. Kiedy budujemy sprzedaż cykliczną, w QA przechodzimy odnowienie z ważną kartą, odnowienie z kartą odrzuconą, zmianę planu w połowie okresu i rezygnację przed kolejnym pobraniem, bo to na tych zdarzeniach subskrypcje się sypią, nie na pierwszym zakupie. Marka, która raz straci klienta na zepsutym odnowieniu, drugi raz nie namówi go na prenumeratę żadnym rabatem.

#Checkout, który mówi w walucie i języku klienta

Sprzedaż transgraniczna przegrywa najczęściej nie na produkcie, tylko na ostatnim ekranie. Klient z Niemiec, który przez cały sklep widział ceny w euro, a na checkoutcie dostaje nagle złotówki i informację o przewalutowaniu przez bank, waha się i wychodzi. Klient spoza Unii, któremu doliczono podatek tak, jakby był z Unii, czuje, że coś tu nie gra. Dlatego checkout dla marki sprzedającej za granicę projektujemy tak, żeby cena, waluta, podatek i koszt dostawy były spójne od strony produktu aż do potwierdzenia płatności.

Od strony technicznej to trzy zazębiające się warstwy. Wielowalutowość, w której cena pokazywana klientowi jest świadomą decyzją marki, a nie automatycznym przeliczeniem po kursie z rana. Obsługa VAT OSS dla sprzedaży wewnątrz Unii, gdzie stawka zależy od kraju konsumenta i musi trafić na fakturę we właściwej wysokości. Oraz osobny tryb dla wysyłek poza Unię, gdzie podatek zdejmuje się w koszyku, a klient wie z góry, że cło zapłaci przy odbiorze. Krakowska marka sprzedająca do klienta z Oslo i do klienta z Monachium obsługuje dwa różne reżimy w jednym sklepie, i to ta różnica, a nie sam język interfejsu, decyduje, czy zamówienie zagraniczne domknie się bez telefonu do obsługi.

Wielojęzyczność jest tu warstwą wierzchnią, nie fundamentem. Opis produktu po angielsku sprzedaje, ale dopiero poprawnie policzony podatek i przewidywalny koszt dostawy sprawiają, że klient klika ostatni przycisk. Kiedy sklep dorasta do skali, w której szablon opisów w kilku językach zaczyna zjadać czas zespołu, warto sięgnąć po wsparcie modeli językowych do przygotowania szkiców tłumaczeń z człowiekiem zatwierdzającym każdy tekst, co robimy w ramach integracji AI z WordPressem.

#Katalog wizualny: kiedy zdjęcie jest właściwie produktem

W modzie, rękodziele i kosmetyce naturalnej klient nie czyta specyfikacji, tylko ogląda. Zdjęcie decyduje o zakupie, więc marka wrzuca ich dużo i w wysokiej jakości, a sklep zaczyna się dławić własnym katalogiem. Strona kategorii z sześćdziesięcioma produktami, każdy z galerią po kilka ujęć, potrafi ładować kilka megabajtów obrazów, zanim klient w ogóle przewinie do pierwszego rzędu. Na telefonie, w drodze, na przeciętnym łączu, to jest różnica między przeglądaniem a zamknięciem karty.

Naprawianie tego przez kolejną wtyczkę optymalizującą zwykle nie działa, bo problem nie leży w cache, tylko w wadze i formacie samych obrazów oraz w tym, ile z nich ładuje się, zanim są potrzebne. Przechodzimy zdjęcia na format AVIF z poprawnymi wymiarami dla każdego widoku, wprowadzamy leniwe ładowanie galerii poniżej pierwszego ekranu i pilnujemy, żeby wersja miniaturki na liście nie była pełnowymiarowym plikiem przeskalowanym w przeglądarce. Efekt jest mierzony na danych rzeczywistych użytkowników z raportu CrUX, nie na jednym teście laboratoryjnym, bo sklep modowy ogląda głównie ruch mobilny, a ten test na szybkim łączu biurowym wygląda zawsze lepiej niż rzeczywistość klienta.

Granicę tej metody komunikujemy wprost. Jeśli sklep stoi na ciężkim motywie premium z demo importowanym lata temu, część problemów z wydajnością da się złagodzić, ale nie usunąć, bo motyw dokłada własny kod do każdej podstrony. Wtedy decyzja brzmi: świadomie zaakceptować kompromis albo zaplanować przebudowę na lekki motyw blokowy, a w projektach, w których liczy się maksimum szybkości katalogu, rozważyć migrację frontendu na Astro lub Next.js z WooCommerce jako zapleczem sprzedaży.

#Trzy sklepy, trzy różne wąskie gardła

Producent regionalny sprzedający za granicę zgłosił się z klasycznym objawem: sprzedaż w kraju rosła, a zamówienia zagraniczne urywały się na płatności. Diagnoza nie leżała w bramce, tylko w checkoucie, który klientowi z Niemiec pokazywał produkt w euro, a na ostatnim ekranie przełączał na złote i naliczał polski VAT niezależnie od kraju odbiorcy. Uporządkowaliśmy warstwę walutową i podatkową, rozdzieliliśmy sprzedaż wewnątrzunijną w reżimie OSS od wysyłek poza Unię i dopięliśmy faktury do właściwej stawki. Zamówienia zagraniczne przestały się urywać na ostatnim kroku, co było widać w spadku porzuconych koszyków z zagranicznymi adresami IP.

Marka subskrypcyjna z asortymentem odnawianym co miesiąc traciła klientów w miejscu, którego nie widać w statystykach sprzedaży: przy odnowieniu. Sklep przy pierwszej odrzuconej płatności po prostu kasował subskrypcję, więc klient z wygasłą kartą znikał bez śladu i bez maila. Zbudowaliśmy logikę ponownych prób z uprzejmym przypomnieniem o aktualizacji karty, pauzą zamiast natychmiastowego skasowania i czytelnym panelem, w którym klient sam zmienia plan i częstotliwość. Odpływ na odnowieniach wyraźnie zmalał, bo większość utraconych subskrypcji nie była decyzją klienta, tylko usterką techniczną, której nikt nie obsłużył.

Sklep sprzedający bilety i doświadczenia turystyczne walczył z czymś jeszcze innym: nadsprzedażą terminów. Warsztaty i zwiedzania miały limit miejsc, ale system dopuszczał do kupna więcej biletów, niż było miejsc, bo dostępność sprawdzała się zbyt późno w procesie. Przenieśliśmy kontrolę limitu na moment dodania do koszyka z twardą rezerwacją na czas płatności, spięliśmy potwierdzenie z kodem na wejście i mailem, a zwroty ustawiliśmy zgodnie z zasadami organizatora. Nadsprzedaż zniknęła, a obsługa przestała ręcznie odwoływać nadmiarowe rezerwacje w niedzielny poranek.

#Bilety, doświadczenia i rezerwacje jako produkty

Kraków sprzedaje przeżycia, nie tylko rzeczy, a to otwiera dla WooCommerce zastosowanie, które wiele marek załatwia osobnym, drogim systemem rezerwacyjnym. Bilet na koncert, miejsce na warsztacie ceramiki, wejściówka na zwiedzanie z przewodnikiem, voucher na doświadczenie w prezencie: to wszystko są produkty z ograniczoną dostępnością, terminem i zasadami zwrotu. Zamiast utrzymywać drugi system i płacić prowizję od każdej sprzedaży, modelujemy je jako typy produktów w tym samym sklepie, w którym marka sprzedaje rzeczy fizyczne.

Praktyczna korzyść jest podwójna. Marka ma jeden panel na cały asortyment: kubek, kurs online i warsztat na żywo leżą obok siebie, rozliczają się przez tę samą bramkę i tę samą logikę podatkową. Klient przechodzi jeden checkout, niezależnie od tego, czy kupuje przedmiot, plik do pobrania czy termin. Voucher prezentowy, szczególnie wdzięczny w mieście żyjącym z turystyki, staje się produktem cyfrowym z kodem, który obdarowany realizuje na konkretne doświadczenie. To samo dotyczy merchu dla firm technologicznych: studio gier czy zespół SaaS sprzedający koszulki i gadżety społeczności potrzebuje sklepu, który obsłuży zarówno wysyłkę fizycznej paczki, jak i kod do pobrania cyfrowego dodatku, bez dwóch osobnych narzędzi.

#Fulfillment, magazyn i świat fizyczny za checkoutem

Sklep konsumencki kończy się nie na płatności, tylko na paczce u klienta, a między jednym a drugim leży najbardziej niedoceniana warstwa: fulfillment. Dla małej marki producenckiej pakowanie ręczne jeszcze się spina, ale przy pierwszym większym sezonie albo współpracy z operatorem logistycznym pojawia się potrzeba spięcia sklepu z systemem, który zajmuje się magazynem i wysyłką. Bez tego zamówienia trzeba ręcznie przepisywać między panelami, a każde ręczne przepisanie to okazja do pomyłki w adresie i straconego dnia w dostawie.

Budujemy te integracje od strony WooCommerce: przekazanie zamówienia do systemu magazynowego albo operatora fulfillmentu, odbiór numeru przesyłki i statusu, aktualizacja stanów w obie strony, żeby sklep nie sprzedał czegoś, czego już nie ma na półce. Dla marki sprzedającej za granicę dochodzi generowanie właściwych dokumentów wysyłkowych i etykiet, a dla sklepów z limitowanymi seriami twarda synchronizacja stanu, o której była mowa wyżej. Robimy to dedykowaną integracją po API zamiast kolejnej wtyczki pośredniczącej, bo każda warstwa pośrednia to następny element, który trzeba aktualizować i który potrafi się rozjechać w najgorszym momencie sezonu.

#Kiedy nie potrzebujesz dedykowanego developera WooCommerce

Nie każdy sklep w Krakowie potrzebuje programisty, i lepiej to ustalić przed podpisaniem umowy niż po. Jeśli sprzedajesz kilkanaście produktów jednej kategorii, w jednej walucie, do klientów w Polsce, z jedną bramką płatniczą i standardową wysyłką kurierem, to gotowy, sprawdzony motyw sklepowy i wąski zestaw dobrze utrzymywanych wtyczek zawiozą cię dalej, niż myślisz. Płacenie za dedykowany development na tej skali to przepalanie budżetu, który lepiej wydać na zdjęcia produktów i reklamę. W takim wypadku uczciwiej jest skonfigurować sklep raz porządnie i oddać go pod opiekę techniczną WordPress z aktualizacjami i monitoringiem, niż budować coś szytego na miarę.

Dedykowany developer zaczyna się zwracać, gdy pojawia się przynajmniej jedno z poniższego: sprzedaż w kilku walutach i reżimach podatkowych, subskrypcje albo inna sprzedaż cykliczna, nietypowy typ produktu w rodzaju biletu czy doświadczenia, integracja z magazynem, ERP albo operatorem fulfillmentu, mierzalny problem wydajności widoczny w danych CrUX, albo sklep, który rósł latami i zebrał tyle wtyczek, że nikt już nie wie, która za co odpowiada. Jeśli żaden z tych warunków nie zachodzi, powiemy to wprost i wycenimy tylko konfigurację oraz opiekę, bo klient, któremu nie sprzedano nadmiarowego projektu, wraca później z tym właściwym.

#Jak pracujemy: ścieżka zamówienia pod kontrolą

Sklep różni się od strony firmowej jednym: ma ścieżkę, którą klient płaci, i ta ścieżka nie może pęknąć. Dlatego pracę porządkujemy wokół zamówienia. Zaczynamy od audytu katalogu i modelu sprzedaży, w którym rozpoznajemy, czy sprzedaż jest jednorazowa, cykliczna czy mieszana, jak wygląda ruch transgraniczny i gdzie realnie tracisz klientów. Z tego powstaje pisemny plan z podziałem na etapy i granicą między rdzeniem WooCommerce, dedykowaną wtyczką i motywem, ustaloną tak, żeby sklep przetrwał każdą aktualizację Woo.

Implementacja idzie zgodnie ze standardami kodowania WordPress i WooCommerce, przez hooki zamiast ruszania rdzenia, z przeglądem kodu na każdej gałęzi i środowiskiem testowym identycznym z produkcją. Kluczowy jest etap QA na ścieżce zamówienia: przechodzimy koszyk, checkout, płatność kartami testowymi na każdej aktywnej bramce, scenariusz odnowienia subskrypcji, zwrot, mail do klienta i edycję zamówienia w panelu, razem ze ścieżkami błędów, bo to na nich sklep się wykłada, nie na szczęśliwym scenariuszu. Wdrożenia mają przetestowaną ścieżkę wycofania, więc żadna zmiana nie zostawia produkcji bez wyjścia.

Rozliczamy się w modelu B2B, z umową, fakturą VAT, poufnością i przeniesieniem praw autorskich do kodu wytworzonego w projekcie. Kod trafia do repozytorium, do którego masz dostęp od pierwszego dnia, więc w każdej chwili możesz zabrać projekt i kontynuować z innym zespołem. Projekty o zamkniętym zakresie wyceniamy etapami, rozwój ciągły rozliczamy miesięcznie, a wycena jest zawsze indywidualna, bo widełki podawane bez audytu sklepu są zgadywaniem. Na koniec dostajesz dokumentację, runbooki bramek i integracji oraz sesję przekazania, a jeśli wolisz nie utrzymywać sklepu samodzielnie, przechodzi on na abonament opieki z tą samą dokumentacją.

Ostatnia aktualizacja: 10 lipca 2026