Frontend / UX
Responsive bilingual festival experience, artyści, harmonogram, passy, registration UX, ceny i promocje.
CASE STUDY / 02 · 2026 · WROCŁAW
Zaprojektowałem i dostarczyłem customową platformę full-stack commerce i admission dla międzynarodowego festiwalu tanecznego — od discovery i rejestracji po płatność, wydanie biletów, podpisane QR i operacje staffu.
01 / THE CHALLENGE
Organizatorzy potrzebowali jednego spójnego procesu od poznania festiwalu do fizycznego wejścia. Warstwa publiczna miała prezentować artystów, harmonogram, miejsce i passy, a warstwa operacyjna obsługiwać ceny, płatności, generowanie biletów, transactional email, weryfikację, zwroty, spory i staff check-in.
02 / MY ROLE
Odpowiadałem za technical delivery od wymagań po production operations: przekładałem potrzeby organizatorów na product stories i release gates, projektowałem architekturę, budowałem frontend i backend, integrowałem payments i ticketing, weryfikowałem wydania oraz prowadziłem deployment, rollback i recovery.
03 / WHAT I BUILT
Responsive bilingual festival experience, artyści, harmonogram, passy, registration UX, ceny i promocje.
Stripe Checkout, server-controlled pricing, promocje, eligibility, card/BLIK flow, zwroty i spory.
Vercel Functions, authoritative validation, signed webhooks, idempotent lifecycle i recovery paths.
Supabase/PostgreSQL schema, constraints, RLS, RPCs, locks, migrations i jawne modele stanów lifecycle.
Deterministic solo/couple ticket issuance, QR podpisane HMAC, public verification i durable Resend delivery.
Automated regression i database validation, GitHub Actions, feature gates, rollback, fallback i production recovery.
04 / ARCHITECTURE
05 / ENGINEERING CHALLENGES
Atomic fulfillment, deterministic identities i durable email outbox pozwalają bezpiecznie ponawiać operacje bez duplikowania orders lub tickets.
Persisted event state, idempotency, database locking i authoritative Stripe reads sprawiają, że duplicate/reordered events są powtarzalne i audytowalne.
Jeden zakup może tworzyć dwa niezależne participant tickets, a Master Couple eligibility jest weryfikowane server-side przed Checkout.
Signed QR credentials, authenticated check-in, atomic mutation i duplicate-entry rejection centralizują stan wejścia w backendzie.
Feature gates, checkout kill switch, Google Form fallback, controlled rollback i targeted recovery tooling utrzymywały registration w stanie możliwym do odzyskania podczas problemów launchowych.
The result is an operational system that connects payment → ticket → QR → entrance, with the controls needed to recover when production does not follow the happy path.