Programista WooCommerce w Radomiu

Sklep WooCommerce w Radomiu nie konkuruje w próżni. Konkuruje z Allegro, na którym kupuje większość polskich konsumentów online, i robi to w mieście o wyraźnej tożsamości przemysłowej: od dziedzictwa Fabryki Broni „Łucznik” (część Polskiej Grupy Zbrojeniowej, w 2025 roku zakład obchodził stulecie działalności) po sieć dostawców B2B, producentów części i firm usługowych z południowego Mazowsza. Buduję sklepy Woo pod te realia - pod katalog części i materiałów dla zakładów z regionu, pod hurt z indywidualnymi cennikami, pod bliskość Warszawy po S7 bez przenoszenia warszawskich kosztów wdrożenia.

#Tworzenie sklepów WooCommerce w Radomiu

Radom leży w korytarzu S7 między Warszawą a Kielcami, więc typowe zlecenie e-commerce wygląda inaczej niż w stolicy. Pierwszy profil to producent albo dystrybutor z Radomia, Pionek, Kozienic, Szydłowca albo okolic, który sprzedaje elementy, narzędzia, odzież roboczą, chemię techniczną albo komponenty do innych zakładów i chce własny kanał zamiast oddawać marżę pośrednikom. Drugi to firma usługowa albo handlowa, która korzysta z bliskości stolicy (klient, logistyka, kadry), ale prowadzi sklep i magazyn lokalnie, bo stawki i tempo decyzji są tu inne niż na Mokotowie. Oba przypadki wymagają tego samego: checkoutu pod polskiego kupującego, spięcia z Subiektem albo Comarchem i kodu, który przeżyje aktualizacje Woo. To jest zakres tej usługi.

Przejście od czysto przemysłowej tożsamości miasta do usług i sprzedaży online nie oznacza porzucenia B2B. Wręcz przeciwnie - wiele radomskich firm nadal żyje z kontraktów między firmami, a Woo staje się witryną katalogową z logowaniem, indywidualnymi cenami i fakturą, a nie tylko półką dla detalu. Jeśli brief wygląda jak „sklep jak Allegro”, weryfikuję to na starcie: czasem lepszy jest portal B2B z koszykiem i proformą niż pełny storefront konsumencki.

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

W polskim e-commerce BLIK jest dominującą metodą płatności, a kolejne raporty Izby Gospodarki Elektronicznej i Polskich Standardów Płatności konsekwentnie pokazują, że jest to pierwsza opcja, po którą sięgają kupujący online. Druga warstwa to szybkie przelewy pay-by-link przez Przelewy24, PayU lub Tpay, dopiero potem karta i pobranie. Praktyczne konsekwencje dla wdrożenia Woo w Radomiu:

• Bramka musi natywnie obsługiwać BLIK (kod sześciocyfrowy plus potwierdzenie w aplikacji bankowej), a nie tylko kartę. Najczęściej oznacza to Przelewy24 albo PayU jako agregatora.
• Kolejność i widoczność metod płatności na checkoucie ustawiam pod realne udziały: BLIK na górze, szybki przelew zaraz pod nim. Domyślny szablon Woo z kartą na pierwszym miejscu działa wbrew nawykom rynku.
• Dla każdej bramki dokumentuję webhooki, matrycę statusów (opłacone, oczekujące, zwrot, częściowy zwrot, 3DS) i historię idempotencji, bo to one decydują o tym, czy zamówienie poprawnie zmienia status po płatności BLIK-iem.
• W B2B dorzucam przelew tradycyjny z terminem, fakturę proformę i czasem odroczoną płatność dla kontrahentów z historią - to nie jest „dodatek marketingowy”, tylko warunek zamknięcia sprzedaży hurtowej.

#Dostawa: Paczkomaty InPost i logistyka południowego Mazowsza

Polski rynek odbioru paczek opanowały automaty InPost. Sklep Woo bez wygodnego wyboru Paczkomatu na checkoucie traci konwersję, niezależnie od tego, jak dobrze wygląda reszta strony. Radom ma tu własną logikę: bliskość Warszawy po S7 skraca czas dostawy do stolicy i aglomeracji, a jednocześnie lokalne nadania z magazynu w Radomiu albo Pionkach często wygrywają z wysyłką z centrum logistycznego po drugiej stronie kraju. 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 albo InPost Kurier dla przesyłek przekraczających skrytkę. Dla producentów i hurtowników z regionu kluczowa jest też ścieżka paletowa albo odbiór własny z magazynu.
• 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.
• Strefy dostaw dopasowane do realnego zasięgu: południowe Mazowsze, województwo mazowieckie, potem reszta kraju - bez udawania, że każdy SKU jedzie w tej samej cenie i tym samym terminem.

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

Krajowy System e-Faktur (KSeF) wchodzi w pełnym wymiarze etapami: od lutego 2026 dla największych podatników (sprzedaż powyżej 200 mln zł w 2024), od kwietnia 2026 dla pozostałych czynnych podatników VAT. Faktura ustrukturyzowana to plik XML wystawiany przez KSeF z nadanym numerem, równolegle nadal funkcjonuje JPK_V7. Faktury B2C dla osób fizycznych pozostają poza obowiązkiem. Dla sklepu Woo 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) do tego systemu, a numer KSeF odebrać z powrotem do zamówienia.
• Pole NIP na checkoucie i walidacja po stronie formularza decydują o tym, czy faktura B2B w ogóle da się wystawić. To drobny element interfejsu z dużą wagą zgodności, szczególnie u dostawców przemysłowych, gdzie niemal każde zamówienie wymaga faktury.
• 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ł to najczęstsze źródło rozjazdu w numeracji.

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

Radomski producent albo dystrybutor rzadko prowadzi sklep w oderwaniu od reszty firmy. Stany, ceny i dokumenty żyją w systemie magazynowo-księgowym, 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ę (na przykład konektor Subiekt GT, SellIntegro, łącznik Comarch Optima) tam, gdzie sprzedaż idzie głównie przez własny sklep.
• BaseLinker jako warstwę pośrednią tam, gdzie firma sprzedaje wielokanałowo, Woo plus Allegro plus inne marketplace. BaseLinker odejmuje stany ze wspólnej puli niezależnie od kanału, co realnie chroni przed nadsprzedażą, a na Allegro nadsprzedaż to negatywne oceny i ryzyko konta.
• Mapowanie pól (SKU, jednostki, stawki VAT, kategorie, numery katalogowe części) ustalam na etapie architektury, bo to ono, a nie sama wtyczka, decyduje, czy synchronizacja jest spójna po obu stronach.
• Dla katalogów B2B osobne reguły widoczności cen: gość widzi zapytanie ofertowe, zalogowany kontrahent widzi swój cennik i limity kredytowe.

#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ć aktualizacje 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ę.

#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. Pracujemy w iteracjach 1-2 tygodniowych 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 Comarch Optima 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 Radomia i południowego Mazowsza regularnie zgłaszają się do nas z tymi problemami:

• Katalogi B2B z setkami SKU, numerami katalogowymi i wariantami (materiał, wymiar, klasa), typowe u dostawców przemysłowych i producentów komponentów. Budujemy typy produktów z logiką warunkową i wyszukiwaniem po kodzie, bez degradacji wydajności listy.
• 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, Comarch Optima lub BaseLinkerem tak, żeby pula towaru była jednym źródłem prawdy dla Woo i dla Allegro.
• Hurt z cenami zależnymi od kontrahenta: role klientów, indywidualne cenniki, minimalne wartości zamówienia, kredyt kupiecki i faktury proforma spięte z polską księgowością.
• Zgodność podatkowa: automatyczne stawki VAT, sprzedaż transgraniczna w UE (procedura OSS) i przygotowanie przepływu danych pod fakturę KSeF.

#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.
• Stabilność stanów magazynowych między Woo a pozostałymi kanałami, czyli koniec z nadsprzedażą na Allegro w szczycie (Black Friday, sezon świąteczny, okna zamówień przemysłowych przed końcem kwartału).

#Dlaczego firmy w Radomiu wybierają WPPoland

Bezpośrednia komunikacja z seniorami, żadnych project managerów przekazujących wiadomości, żadnych juniorów uczących się na Twoim projekcie. Osoba, z którą rozmawiasz, jest osobą piszącą kod.

Bliskość Warszawy po S7 nie oznacza, że wycena ma wyglądać jak w centrum stolicy. Zakres, ryzyka i integracje wyceniam indywidualnie, na piśmie, przed startem - z jasnym rozróżnieniem tego, co jest konieczne do sprzedaży w Polsce (BLIK, Paczkomat, NIP, ERP), a co jest opcjonalnym rozwinięciem.

Po uruchomieniu zapewniamy ciągłą opiekę nad sklepem: monitoring lejka konwersji, aktualizację feedów produktowych (także do Allegro i porównywarek) oraz utrzymanie zgodności bramek i fakturowania w miarę zmian regulacji, w tym kolejnych etapów KSeF. Zmiany zakresu omawiamy otwarcie, z jasnymi konsekwencjami. Bez faktur-niespodzianek.

#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 przetwarzają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 szczytach sprzedaży, a polski rynek ma ich kilka jasno wyznaczonych: Black Friday, przedświąteczny grudzień i okna zamówień B2B przed zamknięciem okresów rozliczeniowych. 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. W katalogach części i materiałów technicznych liczy się też lekka karta produktu z czytelną tabelą parametrów, nie tylko galeria.
• 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 cenników B2B zależnych od roli.
• 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.
• 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.

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

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

Jak przygotowujecie sklep pod KSeF? Sklep przekazuje poprawne dane zamówienia (NIP, stawki, pozycje) do systemu księgowego, który wystawia fakturę ustrukturyzowaną, a numer KSeF wraca do zamówienia. 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.

Czy wdrażacie hurt B2B na Woo? Tak. Dedykowane role klientów, indywidualne cenniki, minimalne wartości zamówienia, faktury proforma i kredyt kupiecki to ścieżka, którą prowadzimy dla dostawców i producentów z Radomia oraz okolic, gdzie hurt często przeważa nad detalem.

Czy pracujecie z firmami spoza Radomia? Tak. Znam kontekst południowego Mazowsza i korytarza S7 (Warszawa blisko, ale decyzje i koszty lokalne), a współpracujemy z klientami w całej Polsce i poza nią.

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.

#Lokalne SEO i widoczność cyfrowa w Radomiu

Widoczność sklepu Woo w Radomiu 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 części i materiałów wdrażamy IndexNow i porządkujemy canonicale, żeby warianty i parametry nie zjadały budżetu crawlowania.

Dane strukturalne, każdy produkt dostaje schema Product z ceną, dostępnością i ocenami, a sklep odpowiednie typy Organization 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 (siedziba w Radomiu to konkretny sygnał dla lokalnego pakietu), 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.

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

#Checkout i rzetelność zamówień: status ustala serwer, nie powrót klienta

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 dystrybutora z Radomia albo hurtowni z Pionek, 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ę, traci zasięg albo wraca do sklepu z cache. 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, czyli przez akcję z rodziny woocommerce_api_... rejestrowaną przez samą bramkę. Handler po weryfikacji wywołuje metodę payment_complete na obiekcie zamówienia i przenosi je z pending do processing. Sygnaturę webhooka sprawdzamy na surowym ciele żądania odczytanym ze strumienia php://input, zanim cokolwiek zostanie sparsowane. Cięższą pracę po weryfikacji, czyli synchronizację z ERP czy nadanie przesyłki, zdejmujemy do Action Scheduler przez as_enqueue_async_action, żeby odpowiedź 200 wracała szybko i bramka nie zaczęła ponawiać.

Powtórzony sygnał z bramki musi być bezpieczny, bo powtórzenie jest normą, a nie awarią. Bramki ponawiają webhook przy timeoutach i przy każdym błędzie po stronie sklepu, więc ta sama płatność potrafi przyjść kilka razy. Identyfikator zdarzenia z bramki zapisujemy w metadanych zamówienia i sprawdzamy przed przetworzeniem, a sam blok obsługi obudowujemy blokadą: wp_cache_add na trwałym cache obiektowym (Redis) albo add_option z wyłączonym autoloadem. Do tego dochodzi warunek na aktualnym statusie i na numerze transakcji: 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 przez wc_reserve_stock_for_order, zwalnia ją przez wc_release_stock_for_order, a czas trzymania bierze z opcji woocommerce_hold_stock_minutes. Bez tego dwoje kupujących może wejść w płatność na ostatnią sztukę i oboje dostaną potwierdzenie. Faktyczne odjęcie stanu robi wc_maybe_reduce_stock_levels i pilnuje go flaga _order_stock_reduced. Przy sprzedaży wielokanałowej rezerwacja Woo nie wie nic o Allegro, więc źródłem prawdy zostaje wspólna pula w BaseLinkerze albo w ERP, a Woo trzyma stan przez synchronizację.

Płatność odrzucona i zwrot częściowy to dwie osobne ścieżki. Odrzucenie ustawia status failed, a nie cancelled, bo zamówienie ma nadal dać się opłacić: klient dostaje link do ponowienia z metody get_checkout_payment_url. Zwrot częściowy realizujemy przez wc_create_refund z listą pozycji i kwot oraz z flagą zwrotu na bramce; zamówienie zostaje wtedy w processing lub completed, a zwróconą kwotę czyta się z get_total_refunded, nie ze statusu.

Log ma pozwolić odtworzyć historię zamówienia bez dostępu do panelu bramki. Do dziennika przez wc_get_logger z własnym źródłem trafia identyfikator zdarzenia, status przed i po, kwota, wynik weryfikacji sygnatury i decyzja (przetworzono albo pominięto jako duplikat), nigdy pełny payload z danymi płatniczymi. Równolegle każda istotna zmiana dostaje notatkę przez add_order_note. Przy włączonym HPOS zamówienia żyją w tabelach wp_wc_orders i wp_wc_orders_meta, więc zapytania diagnostyczne idą przez wc_get_orders, a nie przez bezpośrednie odpytywanie wp_posts.

#Powiązane usługi w Radomiu

Jeśli potrzebujesz strony albo portalu poza samym sklepem, zobacz programowanie WordPress w Radomiu - dedykowane motywy, wzorce bloków Gutenberg i integracje z tym samym lokalnym kontekstem korytarza S7 i przemysłu.

#Rozpocznij swój projekt w Radomiu

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 hurt B2B ma być wydzielony od detalu. Na tej podstawie sprawdzamy konfigurację, wskazujemy ryzyka i proponujemy praktyczny plan działania.

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