Vestra Studio – koncepcyjny sklep e-commerce z dedykowaną logiką sprzedaży

Vestra Studio to projekt koncepcyjny dedykowanego sklepu internetowego dla marki streetwear. Nie jest to sklep wykonany na zlecenie istniejącej marki ani opis wyników rzeczywistego biznesu.

Zbudowałem go jako najbardziej rozbudowany projekt e-commerce w portfolio. Celem było sprawdzenie, jak zaprojektować nie tylko frontend sklepu, ale również zaplecze operacyjne: warianty produktów, rezerwacje magazynowe, płatności, wysyłkę, faktury, wiadomości transakcyjne, panel administracyjny i kontrolę dostępu.

Co chciałem pokazać

• projektowanie pełnego flow zakupowego,
• modelowanie produktów z kolorami, rozmiarami i stanami wariantów,
• ochronę przed oversellingiem przez czasowe rezerwacje,
• integrację Tpay i bezpieczną obsługę webhooków,
• integracje logistyczne InPost i Furgonetka,
• automatyzację faktur i komunikacji transakcyjnej,
• panel administracyjny z rolami i 2FA,
• testowanie scenariuszy błędów, powtórzeń i współbieżności.

Status projektu: projekt koncepcyjny / portfolio. Opisane mechanizmy i testy dotyczą wersji demonstracyjnej, a nie wyników sprzedaży prawdziwej marki.

Jak zbudowałem projekt

Prace rozpocząłem od rozpisania pełnej drogi zamówienia oraz wszystkich sytuacji wyjątkowych. Projektowaliśmy nie tylko scenariusz, w którym płatność kończy się sukcesem, ale również porzucony checkout, powtórzone kliknięcie, opóźniony webhook, błąd zewnętrznego API, wygaśnięcie rezerwacji, anulowanie oraz zwrot.

Architekturę podzieliliśmy na moduły o jasno określonej odpowiedzialności. Frontend nie ustala ceny ani dostępności — prezentuje dane, natomiast ostateczne decyzje podejmuje backend na podstawie aktualnego katalogu, stanów magazynowych i reguł rabatowych.

Etapy realizacji

1. Discovery i architektura: model katalogu, wariantów, zamówień, rezerwacji i integracji.
2. Design system i publiczny sklep: strona główna, katalog, produkt, wishlist, koszyk i checkout.
3. Silnik sprzedaży: walidacja cen, rabaty, rezerwacje, płatności oraz idempotencja.
4. Automatyzacje: wysyłka, tracking, faktury, wiadomości i analityka.
5. Panel administracyjny: produkty, magazyn, zamówienia, rabaty, pracownicy i treści.
6. Hardening produkcyjny: bezpieczeństwo (semgrep scan ai/rule based 0 podatności), rate limiting, testy regresji, E2E i audyt responsywności.

UX sklepu: marka na pierwszym planie, zakupy bez tarcia

Interfejs zaprojektowałem w ciemnej, oszczędnej estetyce pasującej do segmentu streetwear. Unikaliśmy dekoracji, które konkurują z produktem. Kolor akcentowy prowadzi użytkownika przez najważniejsze działania, a typografia, odstępy i kontrast budują wyraźną hierarchię.

Strona główna łączy komunikację marki z bezpośrednimi wejściami do oferty. Katalog pozwala szybko filtrować produkty, a na telefonie zaawansowane filtry pozostają zwinięte, dopóki użytkownik ich nie potrzebuje. Na karcie produktu wybór koloru aktualizuje właściwe zdjęcia, a rozmiary i dostępność są prezentowane bez odrywania użytkownika od decyzji zakupowej.

Koszyk ma dwa poziomy: szybki podgląd wysuwany z interfejsu oraz pełną stronę z formularzem dostawy. Autouzupełnianie adresu działa jako pomoc, nie blokada — klient zawsze może wpisać dane ręcznie, a backend ponownie je waliduje przed utworzeniem zamówienia.

Kluczowe decyzje UX

• mobile-first dla katalogu, formularzy i panelu klienta,
• wyraźny wybór wariantu koloru i rozmiaru,
• wishlist oraz koszyk dostępne bez przeładowania strony,
• ograniczenie liczby pól i decyzji w checkoutcie,
• jednoznaczne stany ładowania, błędu i powodzenia,
• responsywne widoki dla szerokości 390, 768 i 1440 px,
• dedykowana strona 404 oraz bezpieczna strona sukcesu dostępna tylko dla poprawnej sesji zamówienia.

Model produktu i magazynu

Produkt nie jest pojedynczym rekordem z jedną liczbą sztuk. Osobno modelujemy produkt, kolory, rozmiary, zdjęcia przypisane do wariantów oraz stan magazynowy dla konkretnej kombinacji. Pozwala to pokazywać właściwą galerię po wyborze koloru i kontrolować dostępność na poziomie, na którym klient faktycznie kupuje towar.

Każdy produkt ma także wagę i wymiary. Pola te są wymagane oraz walidowane zarówno w formularzu panelu, jak i po stronie serwera. Dane nie są wyłącznie informacyjne — uczestniczą w kalkulacji gabarytu przesyłki.

Rezerwacja zamiast sprzedaży „na słowo”

Podczas rozpoczęcia checkoutu system tworzy tymczasową rezerwację konkretnego wariantu. Dostępność jest obliczana jako stan fizyczny pomniejszony o aktywne rezerwacje innych klientów. Po poprawnym potwierdzeniu płatności rezerwacja przechodzi w sprzedaż, a przy błędzie lub wygaśnięciu jest zwalniana.

Mechanizm uwzględnia również powtarzane żądania. Ten sam klucz idempotencji nie tworzy kolejnych zamówień ani następnych blokad magazynu, tylko zwraca wcześniej rozpoczętą sesję. Jest to szczególnie ważne na urządzeniach mobilnych, gdzie klient może dwukrotnie dotknąć przycisku lub ponowić żądanie po chwilowej utracie połączenia.

Płatności Tpay odporne na powtórzenia i opóźnienia

Integracja Tpay obejmuje utworzenie transakcji, przekierowanie klienta, powrót do sklepu, podpisane powiadomienia oraz późniejszą rekoncyliację. Sam powrót użytkownika z bramki nie jest dowodem zapłaty — zamówienie zmienia status dopiero po wiarygodnym potwierdzeniu po stronie serwera.

Webhooki są weryfikowane kryptograficznie na surowej treści żądania. Implementacja sprawdza podpis JWS, dozwolony algorytm, źródło certyfikatu, środowisko, identyfikator sprzedawcy, CRC, kwotę, opłaconą kwotę i walutę. Ograniczenie rozmiaru payloadu chroni endpoint przed nadużyciem, a idempotencja zabezpiecza przed wielokrotną obsługą tego samego powiadomienia.

Dodatkowy proces rekoncyliacyjny porównuje zamówienia oczekujące z aktualnym stanem po stronie operatora płatności. Dzięki temu pojedynczy niedostarczony webhook nie pozostawia poprawnie opłaconego zamówienia w niewłaściwym statusie.

Wysyłka obliczana z rzeczywistych produktów

Koszt i sposób dostawy nie są wpisane na stałe w formularzu. System wykorzystuje wagę oraz wymiary pozycji, aby oszacować gabaryt paczki. Następnie może pobrać ofertę właściwego przewoźnika i zapisać wybraną metodę razem z zamówieniem.

Sklep obsługuje integracje InPost ShipX i Furgonetka. Użytkownik może wybrać Paczkomat lub dostępne formy kurierskie, a po nadaniu zamówienia otrzymuje stronę trackingu. Tracking został zaprojektowany jako jeden spójny widok: status, oś postępu, dane dostawy, zawartość zamówienia, historia przesyłki i opcje posprzedażowe znajdują się w jednej logicznej strukturze.

Automatyczne faktury i komunikacja transakcyjna

Po opłaceniu zamówienia system przygotowuje dane dokumentu i komunikuje się z API inFakt. Rozróżnia zakup konsumencki oraz firmowy, waliduje NIP i dane adresowe, a po wygenerowaniu dokumentu może dołączyć go do komunikacji z klientem.

Wiadomości transakcyjne są wysyłane przez Resend. Szablony obejmują między innymi potwierdzenie zamówienia, zmianę statusu, anulowanie, zwrot oraz reset hasła. Dane klienta i treści dynamiczne są escapowane, a testy sprawdzają kluczowe warianty wiadomości, aby zmiana w jednym szablonie nie popsuła pozostałych.

Panel administracyjny zaprojektowany do codziennej pracy

Panel nie jest dodatkiem technicznym do sklepu. To właściwe centrum operacyjne, dlatego dostosowaliśmy go do pracy na komputerze i telefonie. Dashboard pokazuje przychód, liczbę zamówień, status realizacji, najlepiej sprzedające się produkty i ostatnie transakcje. Zakres wykresu można ustawić jako 7, 30 lub 90 dni, cały okres albo własne daty.

Zespół może zarządzać:

• produktami, wariantami, zdjęciami oraz wymiarami,
• stanami magazynowymi i historią zmian,
• zamówieniami, płatnościami, wysyłką i dokumentami,
• rabatami oraz warunkami ich użycia,
• rezerwacjami magazynowymi,
• treścią strony, motywem i integracjami,
• pracownikami, rolami i dostępem do konkretnych sekcji.

Widok zamówień ma osobny układ mobilny zamiast szerokiej tabeli zmniejszonej do szerokości telefonu. Formularz produktu zabezpieczyliśmy przed poziomym przepełnieniem, a pola kluczowe dla wysyłki są walidowane w UI oraz w Server Action.

Bezpieczeństwo panelu i odzyskiwania dostępu

Dostęp administracyjny chronimy warstwowo. Samo hasło nie jest jedyną granicą bezpieczeństwa, a pracownik nie otrzymuje automatycznie dostępu do wszystkich operacji.

Zastosowane zabezpieczenia

• role administratora i pracownika oraz osobne uprawnienia do sekcji,
• serwerowy stan sesji i bezpieczne ustawienia cookies,
• 2FA oparte na jednorazowych kodach TOTP,
• osobne limity prób dla logowania, 2FA i resetu hasła,
• neutralna odpowiedź resetu hasła, która nie ujawnia istnienia konta,
• token resetu przechowywany w bazie wyłącznie jako hash,
• atomowe, jednorazowe zużycie tokenu i jego wygaśnięcie,
• unieważnienie wszystkich aktywnych sesji po zmianie hasła,
• jednolite odpowiedzi 401, 403 i 429 dla API,
• ochrona formularzy przez Cloudflare Turnstile,
• brak danych wrażliwych w logach aplikacji.

Rate limiting jest dopasowany do operacji, a nie narzucony jako jeden globalny limit IP. Checkout, logowanie, reset hasła, formularz kontaktowy i autouzupełnianie adresu mają osobne polityki. Podpisane webhooki dostawców nie są blokowane wspólnym limitem użytkowników, ponieważ ich bezpieczeństwo opiera się na podpisie, ograniczeniu payloadu oraz idempotencji.

Analityka, która nie dubluje sprzedaży

Zdarzenie zakupu dla GA4 powstaje na podstawie potwierdzonego zamówienia, a nie samego wejścia na stronę sukcesu. Identyfikator zdarzenia jest deterministyczny, dzięki czemu ponowne odwiedzenie strony lub retry nie zawyża raportowanego przychodu. Wartość produktów jest rozdzielona od wysyłki i podatku zgodnie z kontraktem danych analitycznych.

Analityka respektuje zgodę użytkownika. Zdarzenie może czekać w bezpiecznym outboxie i zostać wysłane dopiero wtedy, gdy spełnione są warunki zgody, bez utraty kontroli nad deduplikacją.

Stack technologiczny

Quality assurance i przygotowanie produkcyjne

Sklep testowaliśmy na kilku poziomach. Testy jednostkowe i integracyjne obejmują między innymi bezpieczeństwo webhooków Tpay, reset hasła, polityki rate limitingu, autouzupełnianie adresów, dane faktur, szablony e-maili oraz deduplikację analityki.

Playwright sprawdza publiczne ścieżki na telefonie, tablecie i desktopie, w tym logowanie, odzyskiwanie hasła, stronę główną, sklep, koszyk, kontakt, stronę sukcesu i 404. Testy korzystają z odizolowanej bazy oraz nie wysyłają prawdziwych płatności ani wiadomości.

Przed wydaniem uruchamiana jest wspólna bramka jakości:

1. ESLint,
2. kontrola typów TypeScript,
3. testy logiki biznesowej,
4. testy end-to-end,
5. produkcyjny build Next.js.

Takie podejście jest szczególnie ważne w e-commerce. Drobna zmiana wyglądu formularza nie może przypadkowo wpłynąć na cenę, rezerwację, dostęp do panelu lub obsługę powiadomienia płatniczego.

W tym projekcie najważniejsze były nie fikcyjne wyniki sprzedażowe, ale zachowanie systemu w konkretnych scenariuszach technicznych: równoległe próby zakupu ostatniej sztuki, ponowione żądania, powtórzone webhooki, błędy płatności i automatyzacja procesów po opłaceniu zamówienia.

Co pokazuje ten projekt

Vestra Studio pokazuje, że potrafię pracować nad e-commerce'em znacznie głębiej niż na poziomie samego layoutu. Projekt obejmuje model danych, backend, integracje, bezpieczeństwo, logistykę i scenariusze awaryjne.

To demonstracja rozwiązania dla sytuacji, w której gotowy szablon sklepu nie wystarcza i potrzebna jest własna logika procesu sprzedażowego.

Masz nietypowy proces sprzedaży albo sklep wymagający dedykowanych integracji? Porozmawiajmy o tym, co warto zbudować customowo, a czego nie ma sensu pisać od zera.