Programista WooCommerce w Toruniu

Sklep WooCommerce w Toruniu działa w konkretnym krajobrazie: średniowieczne Stare Miasto na Liście światowego dziedzictwa UNESCO od 1997 roku, sezonowy ruch turystyczny, silna marka pierników, Uniwersytet Mikołaja Kopernika oraz aglomeracja bydgosko-toruńska z dojazdami po A1. Kupujący jest jednak ten sam co w reszcie Polski: płaci BLIK-iem, odbiera z Paczkomatu i potrzebuje faktury, która przejdzie przez KSeF. Pod te realia buduję sklepy Woo, a nie pod ogólny “globalny” wzorzec checkoutu.

#Tworzenie sklepów WooCommerce w Toruniu

Toruń generuje trzy wzorce zleceń, które wracają regularnie. Pierwszy to handel i usługi wokół Starego Miasta: sklepy z piernikami i słodyczami, rzemiosło, pamiątki, hotele i apartamenty z dopłatą online, gastronomia z przedsprzedażą voucherów. Drugi to spożywka i przetwórstwo z regionu kujawsko-pomorskiego, od lokalnych producentów po dystrybutorów B2B, którzy potrzebują sklepu spójnego z magazynem w Subiekcie albo Comarchu. Trzeci to firmy z otoczenia UMK i usług B2B, które sprzedają produkt fizyczny albo cyfrowy i traktują Woo jako jeden kanał obok Allegro. We wszystkich trzech przypadkach potrzebny jest ten sam fundament: checkout pod polskiego kupującego, integracja z systemem magazynowo-księgowym i kod, który przeżyje kolejne wydania WooCommerce.

#Płatności pod polskiego kupującego: BLIK, Przelewy24, PayU

W polskim e-commerce BLIK to dominująca metoda płatności online. Drugą warstwą są szybkie przelewy pay-by-link (Przelewy24, PayU, Tpay), karta i pobranie są dalej, a płatności odroczone w stylu PayPo lub Klarna mają sens głównie w wyższych koszykach. W Toruniu dochodzi jeszcze jedna ścieżka: turyści z UE i spoza kraju, którzy nie mają BLIK-a i kończą zakup kartą albo PayPalem. Praktyczne konsekwencje dla wdrożenia Woo:

• Bramka musi natywnie obsługiwać BLIK (kod sześciocyfrowy plus potwierdzenie w aplikacji bankowej), a nie tylko kartę. Najczęściej oznacza to Przelewy24, PayU albo Tpay jako agregatora.
• Kolejność metod na checkoucie ustawiam pod realne udziały rynkowe: BLIK na górze dla klientów z Polski, szybki przelew zaraz pod nim, karta i PayPal widoczne dla gości z zagranicy. Domyślny szablon Woo z kartą na pierwszym miejscu działa wbrew nawykom rynku krajowego.
• Dla każdej bramki dokumentuję webhooki, matrycę statusów (opłacone, oczekujące, zwrot, częściowy zwrot, 3DS) i lokalną historię idempotencji. Status zamówienia ustala callback serwer do serwera, nigdy sam powrót klienta na stronę podziękowania.

#Dostawa: Paczkomaty InPost i odbiór w mieście turystycznym

W Polsce automaty paczkowe to pierwszy wybór dla większości kupujących, a wśród nich zdecydowana większość trafia do Paczkomatów InPost. W Toruniu sieć pokrywa osiedla od Rubinkowa i Jaru przez Bielany po Mokre, a dodatkowo pojawia się odbiór osobisty przy punkcie w centrum albo przy magazynie na obrzeżach. Sklep Woo bez wygodnego wyboru paczkomatu na checkoucie traci konwersję niezależnie od tego, jak wygląda reszta strony. W praktyce wdrażam:

• Mapę wyboru punktu InPost (geowidget) wbudowaną w checkout, z zapamiętaniem ostatnio wybranego automatu, zamiast wysyłania klienta na zewnętrzną stronę.
• Reguły dostaw oparte na wadze i gabarycie, z automatycznym przełączeniem na kuriera DHL, DPD, GLS albo InPost Kurier dla przesyłek przekraczających skrytkę. Dla spożywki i pierników często dochodzi też okno termiczne albo ograniczenie dni wysyłki przed świętami.
• Opcję odbioru osobistego z jasnym adresem i godzinami, przydatną dla klientów z aglomeracji bydgosko-toruńskiej oraz dla turystów, którzy chcą odebrać zamówienie podczas pobytu w mieście.
• Integrację nadań z systemem przewoźnika, tak żeby etykieta i numer śledzenia wracały do zamówienia Woo i do maila klienta, a nie były klejone ręcznie z panelu kuriera.

#Faktury i KSeF: zgodność, której nie da się odłożyć

Krajowy System e-Faktur (KSeF) wchodzi w 2026 roku etapami: od lutego dla największych podatników (sprzedaż powyżej 200 mln zł w 2024), od kwietnia dla pozostałych czynnych podatników VAT. Faktura ustrukturyzowana to plik XML wystawiany przez KSeF z nadanym numerem; równolegle nadal funkcjonują pliki JPK_V7M i JPK_V7K. Faktury B2C dla osób fizycznych pozostają poza obowiązkiem. Dla sklepu Woo w Toruniu oznacza to konkretne decyzje:

• Sklep zwykle nie wystawia faktur ustrukturyzowanych sam, robi to system księgowo-magazynowy. Rolą wdrożenia Woo jest poprawnie przekazać dane zamówienia (NIP nabywcy, stawki VAT, pozycje, formę płatności) do tego systemu, a numer KSeF odebrać z powrotem i podpiąć do zamówienia oraz do maila potwierdzającego.
• Pole NIP na checkoucie wraz z walidacją i pobraniem danych z bazy GUS przesądza, czy faktura B2B w ogóle da się wystawić. To drobny element interfejsu o dużej wadze zgodności, szczególnie przy hurtowej sprzedaży spożywczej i upominkowej do firm.
• Granicę “co liczy podatek i wystawia fakturę” zapisuję w runbooku: czy robi to wtyczka fakturująca w Woo, czy zewnętrzny ERP. Mieszanie obu źródeł jest najczęstszą przyczyną rozjazdu numeracji i błędów plikach JPK.

#Integracja z magazynem i księgowością: Subiekt, Comarch, BaseLinker

Producent spożywczy z regionu, dystrybutor upominków z piernikami w ofercie albo hurtownik z okolic Torunia rzadko prowadzą sklep w oderwaniu od reszty firmy. Stany, ceny i dokumenty żyją w systemie magazynowo-księgowym - w regionie najczęściej w InsERT Subiekt GT lub nexo, w Comarch ERP Optima albo XL, czasem w WAPRO Mag. Sklep Woo musi się z tym zsynchronizować dwukierunkowo: produkty i stany z systemu do sklepu, zamówienia ze sklepu do systemu. W zależności od skali wdrażam:

• Bezpośrednią integrację (konektor Subiekt GT, SellIntegro, FirmesLink) tam, gdzie sprzedaż idzie głównie przez własny sklep, a katalog jest stabilny.
• BaseLinker jako warstwę pośrednią tam, gdzie firma sprzedaje wielokanałowo: Woo plus Allegro, plus ewentualnie inne marketplace. BaseLinker odejmuje stany ze wspólnej puli niezależnie od kanału, co chroni przed nadsprzedażą. Dla sezonowych produktów spożywczych i upominkowych przed Bożym Narodzeniem nadsprzedaż to nie tylko strata towaru, ale i fala reklamacji.
• Mapowanie pól (SKU, jednostki miary, stawki VAT, kategorie, atrybuty daty przydatności albo warianty smaku) ustalam na etapie architektury, bo to ono, a nie sama wtyczka, decyduje, czy synchronizacja jest spójna po obu stronach.

#Handel turystyczny i spożywka: katalog, który nie psuje się w sezonie

Stare Miasto Torunia przyciąga ruch krajowy i zagraniczny przez cały rok, z wyraźnymi szczytami w wakacje, długie weekendy i przed świętami. Sklepy z piernikami, zestawami upominkowymi i regionalną spożywką mają wtedy inne problemy niż typowy sklep odzieżowy:

• Warianty produktów (gramatura, smak, opakowanie prezentowe, zestaw firmowy) muszą być czytelne na telefonie, bo duża część zamówień spływa z mobilnego ruchu turystycznego i z social media.
• Zdjęcia produktów i karty opisowe potrzebują lekkich formatów (WebP, AVIF) oraz sensownego lazy loadingu, inaczej strony kategorii padają pod ciężarem galerii.
• Reguły wysyłki muszą uwzględniać produkty wrażliwe na temperaturę i czas: niektóre pozycje nie powinny wychodzić w piątek po południu, jeśli kurier dostarczy je dopiero w poniedziałek.
• Dla sprzedaży B2B (kosze prezentowe dla firm, zamówienia hurtowe do sklepów i hoteli) potrzebne są role cenowe, minimalne ilości i pole NIP już na etapie koszyka, a nie dopiero w mailu do obsługi.

#Aglomeracja bydgosko-toruńska i logistyka na A1

Toruń i Bydgoszcz tworzą wspólny rynek pracy i zakupów. Klienci z jednej strony aglomeracji kupują u sprzedawców z drugiej, a firmy magazynują towar tam, gdzie mają tańszy lub bliższy magazyn. Autostrada A1 skraca drogę na północ do Trójmiasta i na południe w głąb kraju, więc sklep z Torunia realnie obsługuje zamówienia daleko poza granicami miasta. W praktyce Woo musi:

• Obsługiwać strefy dostaw i progi darmowej wysyłki bez sztucznego cięcia na “tylko Toruń”.
• Dawać odbiór osobisty albo punkt partnerski także klientom dojeżdżającym z Bydgoszczy.
• Trzymać spójne stany, gdy firma ma magazyn w jednym mieście aglomeracji, a obsługę zamówień w drugim.
• Przy sprzedaży eksportowej do Niemiec i Skandynawii uwzględniać procedurę OSS oraz osobne metody płatności i dostawy dla koszyków zagranicznych.

#Standardy techniczne

Customizacje Woo idą wyłącznie przez udokumentowane hooki action i filter oraz podział na własną wtyczkę i motyw, nigdy przez modyfikację plików rdzenia, bo sklep musi przeżyć kolejne wydania WooCommerce i WordPressa. Infrastruktura testowa obejmuje PHPUnit do logiki biznesowej, testy e2e ścieżki checkoutu oraz Lighthouse CI dla budżetów wydajnościowych. Każde wdrożenie uruchamia testową transakcję na bramce (płatność testowa BLIK i kartą) przed promocją na produkcję. Hosting trzymam u polskich dostawców z zapleczem w kraju (cyber_Folks, OVH PL, home.pl), bo to upraszcza umowy powierzenia danych i obsługę incydentów po polsku.

#Jak pracujemy

Każdy projekt prowadzę według ustrukturyzowanego procesu, który ogranicza ryzyko i utrzymuje przejrzystość:

1. Audyt i ustalenie granic. Przegląd checkoutu, bramek, stref dostaw, podatków i integracji, plus baseline Lighthouse na najczęściej odwiedzanych stronach produktu i kategorii. Na tym etapie zapada decyzja, co liczy podatek, co wystawia fakturę i gdzie żyje stan magazynowy.
2. Sprinty deweloperskie. Iteracje 1-2 tygodniowe z demo na koniec każdego sprintu. Widzisz postęp na bieżąco, dajesz uwagi na czas i możesz zmieniać priorytety bez wykolejania projektu.
3. Zapewnienie jakości. Każdy element 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. Przegląd na środowisku testowym. Kompletne rozwiązanie działa na kopii identycznej z produkcją. Testujesz z prawdziwą treścią, weryfikujesz integrację z Subiektem albo Comarchem i zatwierdzasz do uruchomienia.
5. Launch i wsparcie. Obsługujemy zmiany DNS, SSL, rozgrzewanie cache’u, weryfikację przekierowań i monitoring. Po uruchomieniu zostajemy w gotowości przez 72 godziny, a po okresie stabilizacji przechodzimy do bieżącej opieki z miesięcznymi przeglądami.

#Typowe wyzwania, które rozwiązujemy

Firmy z Torunia i regionu kujawsko-pomorskiego regularnie zgłaszają się z tymi problemami:

• Sezonowe skoki ruchu przy produktach upominkowych i spożywczych, porządkujemy cache, media i ścieżkę checkoutu tak, żeby Black Friday i grudzień nie wywracały sklepu.
• Wolny checkout tracący konwersje, redukujemy czas ładowania koszyka i checkoutu przez cachowanie fragmentów, odroczone ładowanie skryptów, zoptymalizowaną inicjalizację bramki płatniczej i uproszczoną walidację formularza, włącznie z polem NIP i wyborem Paczkomatu.
• Rozjazd stanów między sklepem a magazynem, porządkujemy synchronizację z Subiektem, Comarchem lub BaseLinkerem tak, żeby pula towaru była jednym źródłem prawdy dla Woo i dla Allegro.
• Zgodność podatkowa, automatyczne stawki VAT, obsługa sprzedaży transgranicznej w UE (procedura OSS, częsta przy wysyłkach do Niemiec przez węzeł A1) i przygotowanie przepływu danych pod fakturę KSeF.
• Katalog z dużą liczbą wariantów smakowych i gramatur, budujemy czytelne typy produktów z logiką warunkową bez degradacji wydajności stron kategorii.

#Rezultaty, jakich możesz oczekiwać

Mierzymy sukces konkretnymi metrykami, nie subiektywnymi ocenami. To, na co realnie pracujemy:

• Krótszy czas ładowania stron produktów, kategorii i checkoutu, mierzony przed i po, z poprawą Core Web Vitals na najczęściej odwiedzanych adresach.
• Mniej porzuconych koszyków dzięki checkoutowi dopasowanemu do polskich nawyków: BLIK na wierzchu, wybór Paczkomatu w jednym kroku, sensowna walidacja danych do faktury z polem NIP.
• Stabilność stanów magazynowych między Woo a pozostałymi kanałami, czyli koniec z nadsprzedażą na Allegro w szczycie sprzedaży (Black Friday, przedświąteczny sezon pierników i upominków firmowych).

#Dlaczego firmy w Toruniu wybierają WPPoland

Bezpośrednia komunikacja z seniorami: żadnych pośredników przekazujących wiadomości, żadnych juniorów uczących się na Twoim projekcie. Osoba, z którą rozmawiasz, jest osobą piszącą kod i podejmującą decyzje architektoniczne.

Po uruchomieniu zapewniamy ciągłą opiekę nad sklepem: testy A/B checkoutu, monitoring lejka konwersji, aktualizację feedów produktowych (także do Allegro i porównywarek typu Ceneo) oraz utrzymanie zgodności bramek i fakturowania w miarę zmian regulacji, w tym kolejnych etapów KSeF.

Wycena jest indywidualna i przedstawiana na piśmie przed startem. Zmiany zakresu omawiamy otwarcie, z jasnymi konsekwencjami. Bez faktur-niespodzianek na koniec etapu.

#Bezpieczeństwo i zgodność

W projektach WooCommerce bezpieczeństwo traktujemy jako zestaw decyzji architektonicznych, a nie uniwersalną obietnicę zgodności. Typowy zakres obejmuje HTTPS z HSTS tam, gdzie pasuje do infrastruktury, nagłówki Content Security Policy ograniczające XSS, skanowanie podatności zależności w CI, uwierzytelnianie dwuskładnikowe dla kont administracyjnych i regularne testowanie kopii zapasowych. Przy sklepach przetwarzujących dane klientów przygotowujemy konfigurację zgód, umowy powierzenia, minimalizację danych i procedury reakcji na incydenty do weryfikacji z właścicielem procesu. Dla klientów na bieżącej opiece prowadzimy cykliczne przeglądy bezpieczeństwa: testy odtworzenia kopii, audyt dostępów, przegląd aktualizacji i listę ryzyk do decyzji biznesowej.

#Inżynieria wydajności

W e-commerce szybkość przekłada się wprost na przychód: opóźnienia rzędu setek milisekund mierzalnie obniżają konwersję (potwierdzają to publikowane analizy Akamai i Amazon). To szczególnie istotne w polskich szczytach sprzedaży i w toruńskim kalendarzu: Black Friday, przedświąteczny grudzień, wakacyjny ruch turystyczny przy Starym Mieście oraz weekendy z dużym napływem gości. Nasze podejście do wydajności sklepu Woo obejmuje:

• Optymalizacja zasobów, obrazy przetwarzane w procesie budowania do responsywnych srcset w WebP i AVIF, CSS purgowany i inlinowany dla treści above-the-fold, JavaScript code-split i ładowany dynamicznie.
• Architektura cachowania, wielowarstwowo: przeglądarka, CDN (Cloudflare), cache aplikacji (Redis) i cache zapytań do bazy z inteligentną inwalidacją, z osobnym potraktowaniem dynamicznych fragmentów koszyka i mini-koszyka w nagłówku.
• Optymalizacja sieci, HTTP/3 z QUIC, kompresja Brotli oraz hinty preconnect i dns-prefetch do bramek płatniczych i geowidgetu InPost, żeby zewnętrzne skrypty nie blokowały renderu pierwszego widoku.
• Optymalizacja renderowania, inlining krytycznego CSS, asynchroniczne style, lazy loading obrazów i iframów oraz animacje wyzwalane przez Intersection Observer.

Każda decyzja wydajnościowa jest oparta na danych. Mierzymy przed i po, dokumentujemy wpływ i dołączamy baseline wydajności do dokumentacji projektu.

#UMK i lokalny kontekst B2B

Uniwersytet Mikołaja Kopernika kształtuje lokalny rynek usług: studenci, absolwenci, spin-offy i firmy obsługujące kampus potrzebują sklepów z kursami, materiałami, sprzętem albo usługami B2B. W takich wdrożeniach często pojawiają się konta firmowe, ceny hurtowe, faktury z NIP-em i ograniczenia dostępu do katalogu dla zalogowanych klientów. WooCommerce radzi sobie z tym przez role, reguły katalogu i własne wtyczki oparte na hookach, bez budowania osobnego “portalu” od zera, o ile granice uprawnień są spisane na starcie.

#Pytania, które zadają nam firmy w Toruniu

Czy obsługujecie BLIK i Paczkomaty od razu po wdrożeniu? Tak, dla polskiego sklepu to punkt wyjścia, a nie dodatek. Konfigurujemy bramkę z BLIK-iem (zwykle Przelewy24, PayU albo Tpay) i wybór punktu InPost wbudowany w checkout, z testową transakcją na każdej metodzie przed startem. Dla sklepów z ruchem turystycznym dokładamy też kartę i PayPal w widocznej pozycji.

Jak przygotowujecie sklep pod KSeF? Sklep przekazuje poprawne dane zamówienia (NIP, stawki VAT, pozycje, forma płatności) do systemu księgowego, który wystawia fakturę ustrukturyzowaną, a numer KSeF wraca do zamówienia i do maila potwierdzającego. Ustalamy jedno źródło fakturowania, żeby uniknąć rozjazdu numeracji, i zapisujemy to w runbooku.

Integrujecie się z Subiektem albo Comarchem? Tak. Dla sprzedaży głównie przez własny sklep używamy bezpośredniego konektora (Subiekt GT/nexo, Comarch Optima/XL, WAPRO Mag), dla sprzedaży wielokanałowej z Allegro warstwą pośrednią jest zwykle BaseLinker. Decyzja zapada po przeglądzie skali sprzedaży i liczby kanałów, nie z automatu.

Czy możecie zmigrować nasz istniejący sklep? Tak. Obsługujemy migracje z dowolnego CMS do WordPressa, między platformami sklepowymi (IdoSell, Shoper, PrestaShop do WooCommerce) i między dostawcami hostingu. Każda migracja obejmuje mapowanie URL, przekierowania 301, transfer historii zamówień i monitoring SEO przez 90 dni po migracji.

Czy pracujecie z firmami spoza Torunia? Tak. Mamy klientów całym regionie kujawsko-pomorskim, w Bydgoszczy, w Trójmieście, w Warszawie i poza Polską. Lokalność jest ważna dla zrozumienia kontekstu (UNESCO i turystyka, spożywka, Subiekt, BaseLinker, Allegro, A1), ale nie jest wymogiem.

Ile trwa typowy projekt sklepu WooCommerce? Zależy od zakresu, gotowości treści i złożoności integracji. Prosty sklep z gotowym katalogiem to kilka tygodni, wdrożenie z integracją ERP, wieloma bramkami i synchronizacją z Allegro zwykle dłużej. Szczegółowy harmonogram przedstawiamy w fazie specyfikacji. Wycena jest indywidualna.

#Lokalne SEO i widoczność cyfrowa w Toruniu

Widoczność sklepu Woo w Toruniu to nie tylko słowa kluczowe, to architektura techniczna, która pozwala wyszukiwarce zrozumieć ofertę. Budujemy ją od fundamentów:

Indeksowanie i odkrywanie treści, dbamy, żeby wyszukiwarki szybko znajdowały i indeksowały ważne podstrony produktowe i kategorie. Przy dużych katalogach wdrażamy IndexNow, żeby zmiany cen i dostępności szybciej trafiały do indeksu Google i Bing.

Dane strukturalne, każdy produkt dostaje schema Product z ceną, dostępnością i ocenami, a sklep odpowiednie typy Organization, LocalBusiness (z adresem w Toruniu dla firm z fizyczną siedzibą lub punktem odbioru) i BreadcrumbList. To one decydują o bogatych wynikach w Google.

Sygnały E-E-A-T, strukturyzujemy treść pokazując doświadczenie i wiarygodność: dane firmy, NIP i REGON, polityki dostaw i zwrotów, realne opinie. Dla sklepu zaufanie to bezpośredni czynnik konwersji, nie tylko SEO.

Widoczność w wyszukiwaniu wspieranym przez AI, treść układamy tak, żeby była czytelna również dla Google AI Overviews, ChatGPT i Perplexity: jasne definicje, konkretne fakty o dostawie i płatnościach, uporządkowane dane techniczne produktu.

Połączenie solidnej techniki i przemyślanej architektury treści pomaga sklepowi z Torunia budować trwały ruch organiczny zarówno w klasycznych wynikach, jak i w odpowiedziach generowanych przez AI, a to ważne na rynku, gdzie część popytu przechwytuje Allegro i porównywarki.

#Checkout i rzetelność zamówień

Najczęstsza wada wdrożeń, które trafiają do nas na naprawę, nie leży w wyglądzie checkoutu, tylko w tym, co dzieje się po kliknięciu “zapłać”. Sklep spożywczy albo upominkowy z Torunia, który sprzedaje równolegle przez własne Woo i przez Allegro, płaci za ten błąd dwa razy: raz utraconym zamówieniem, drugi raz nadsprzedażą towaru, który był już komuś obiecany.

Status zamówienia ustala powiadomienie serwer do serwera, nigdy powrót klienta na stronę podziękowania. Powrót na endpoint order-received to zdarzenie przeglądarki, a przeglądarka jest zawodna: klient po autoryzacji BLIK-iem zamyka kartę albo traci zasięg. Dlatego hook woocommerce_thankyou służy wyłącznie do wyświetlenia treści i nie zmienia statusu. O pieniądzach decyduje callback bramki, w Woo odbierany na własnym adresie zwrotnym z parametrem wc-api. Handler po weryfikacji wywołuje payment_complete i przenosi zamówienie z pending do processing. Cięższą pracę po weryfikacji, czyli synchronizację z ERP czy nadanie przesyłki, zdejmujemy do Action Scheduler, żeby odpowiedź 200 wracała szybko.

Powtórzony sygnał z bramki musi być bezpieczny. Bramki ponawiają webhook przy timeoutach, więc ta sama płatność potrafi przyjść kilka razy. Identyfikator zdarzenia zapisujemy w metadanych zamówienia i sprawdzamy przed przetworzeniem. Zamówienie już opłacone nie zmienia stanu drugi raz, tylko dostaje notatkę o zignorowanym duplikacie.

Stan magazynowy rezerwujemy w momencie rozpoczęcia płatności, nie po jej potwierdzeniu. WooCommerce od wersji 4.3 zapisuje rezerwację w tabeli wp_wc_reserved_stock. Przy sprzedaży wielokanałowej źródłem prawdy zostaje wspólna pula w BaseLinkerze albo w ERP, a Woo trzyma stan przez synchronizację.

#Powiązane usługi w Toruniu

Jeśli potrzebujesz strony albo portalu poza samym sklepem, zobacz programowanie WordPress w Toruniu - dedykowane motywy, wzorce bloków Gutenberg i integracje z tym samym lokalnym kontekstem UNESCO i UMK.

#Rozpocznij swój projekt w Toruniu

Jeśli chcesz omówić budowę albo rozwój sklepu WooCommerce, wyślij krótki opis obecnej sytuacji, celu biznesowego i ograniczeń technicznych: jaki masz system magazynowy, przez jakie kanały sprzedajesz, jakie bramki i dostawy są w grze, czy faktury wystawia Subiekt, Comarch czy zewnętrzne biuro księgowe. Na tej podstawie sprawdzamy konfigurację, wskazujemy ryzyka (zwłaszcza w kontekście KSeF) i proponujemy praktyczny plan działania.

Jeśli planujesz nową budowę, migrację z IdoSell, Shopera albo PrestaShopa do WooCommerce lub stałe wsparcie techniczne, zacznij od spisania celów, ograniczeń i obecnego stanu projektu.