naevent

Wyzwanie

naevent to moja marka: robię strony wydarzeń i aplikacje PWA dla uczestników, a sprzedaję je agencjom eventowym, często pod ich własną marką (white-label). Nie miałem strony, a domena pokazywała stronę parkingową rejestratora. Potrzebowałem dwóch rzeczy. Po pierwsze strony, która w kilka sekund pokaże agencji, jak takie rozwiązanie działa w dniu wydarzenia, bez obiecywania rzeczy, których nie robię. Po drugie miejsca do prowadzenia sprzedaży: listy agencji, do których piszę, follow-upów, wycen z drobnych elementów i projektów po akceptacji. Wcześniej trzymałem to w mailach i notatkach.

Rozwiązanie

Strona ma stronę główną, stronę oferty, sześć podstron produktów (strona wydarzenia, rejestracja, check-in z kodem QR, aplikacja PWA, panel organizatora, galeria na żywo), stronę dla agencji, cennik, FAQ, kontakt i realizacje. Głównym materiałem wizualnym są interfejsy zbudowane w HTML i CSS, a nie zrzuty ekranu. Każdy produkt ma własny ekran i własną fikcyjną markę wydarzenia.

Pierwsza wersja była celowo oszczędna w ruchu. Gdy obejrzałem ją na iPhonie, uznałem, że jest za statyczna, i przebudowałem sekcje. Ruch wziąłem z tego, co naprawdę dzieje się na evencie:

• komunikat od organizatora przychodzi na telefon;

• punkt agendy przenosi się do innej sali;

• skaner potwierdza wejście;

• zdjęcia wpadają do galerii na żywo.

Na telefonie animacje ruszają dopiero, gdy makieta jest widoczna. Długie teksty dostały krótki lead, a reszta trafiła do rozwijanych bloków i zakładek, ale cała treść zostaje w HTML dla wyszukiwarek. Do makiet dobrałem zdjęcia z Unsplash i Pexels, bez rozpoznawalnych twarzy, z jedną korektą kolorów dla całego zestawu.

Formularz wyceny ma cztery kroki i działa też bez JavaScriptu. Każde zapytanie trafia do bazy i do mojej skrzynki, a nadawca dostaje potwierdzenie.

Panel ma logowanie z obowiązkową weryfikacją dwuetapową i moduł realizacji z edytorem i wgrywaniem zdjęć. Główną część stanowi CRM:

• agencje: historia kontaktu, follow-upy w dni robocze z polskimi świętami, import CSV;

• projekty: termin oddania liczony od kompletu materiałów, płatności, koszty;

• biblioteka: elementy wyceny i zestawy;

• kreator ofert: wyliczenia w groszach, wersje, numeracja, dokument PDF;

• finanse: wskaźniki i wykresy.

Technologia

Strona i panel działają na Astro 7 jako Workery Cloudflare. Baza to D1 z Drizzle ORM, pliki są w R2, obie w jurysdykcji UE. Formularz chroni Cloudflare Turnstile, honeypot, podpisany znacznik czasu i limity zapytań. Maile wychodzą przez Resend z osobnej subdomeny. Szablony sprawdziłem w jasnym motywie, w ciemnym i przy wymuszonym odwracaniu kolorów w Gmailu.

Hasła są haszowane algorytmem Argon2id. Weryfikację dwuetapową zrobiłem według RFC 6238, z szyfrowanym sekretem i kodami zapasowymi. Każda trasa panelu bez sesji przekierowuje na logowanie i pilnuje tego test. Strona ma politykę CSP opartą na hashach skryptów i stylów, polską typografię (twarde spacje), dane strukturalne, mapę strony i plik llms.txt.

PDF ofert generuje Cloudflare Browser Run z tego samego szablonu HTML co podgląd. Zadania cykliczne obsługują retencję danych, poranny mail z zadaniami i cotygodniową kopię zapasową w prywatnym magazynie. Po drodze trafiłem na błąd Safari na iOS: tekst w makietach skalowanych właściwością zoom się nie zmniejszał. Przeszedłem na skalowanie transformacją, a test w CI pilnuje, żeby zoom nie wrócił. Jakość pilnują testy Vitest i Playwright w Chromium i WebKit, axe oraz Lighthouse. Wdrożenie jest skryptem z kontrolą konfiguracji produkcyjnej, uruchamianym z GitHub Actions.

Efekt

Mam stronę, która pokazuje produkt w działaniu, i jeden panel do całej sprzedaży: od pierwszego maila do agencji, przez ofertę w PDF, po zapłacony projekt i raport finansowy. Strona dopiero wystartowała, więc wyników sprzedażowych i ruchu jeszcze nie ma.