Frontend / UX
Responsive bilingual festival experience, artists, schedule, passes, registration UX, pricing and promotion presentation.
CASE STUDY / 02 · 2026 · WROCŁAW
Designed and delivered a custom full-stack commerce and admission platform for an international dance festival — connecting discovery, registration, payment, ticket fulfillment, signed QR verification and staff operations.
01 / THE CHALLENGE
The organizers needed one coherent path from festival discovery to physical entrance. The public website had to present artists, schedule, venue and passes, while the operational layer had to handle pricing rules, payments, ticket creation, transactional email, verification, refunds, disputes and staff check-in.
02 / MY ROLE
I owned technical delivery from requirements through production operations: translating organizer requests into product stories and release gates, designing the architecture, building the frontend and backend, integrating payments and ticketing, validating releases, managing deployment and supporting rollback and recovery.
03 / WHAT I BUILT
Responsive bilingual festival experience, artists, schedule, passes, registration UX, pricing and promotion presentation.
Stripe Checkout, server-controlled pricing, promotions, eligibility, card/BLIK flow, refunds and disputes.
Vercel Functions, authoritative validation, signed webhooks, idempotent lifecycle handling and recovery paths.
Supabase/PostgreSQL schema, constraints, RLS, RPCs, locks, migrations and explicit lifecycle state models.
Deterministic solo/couple ticket issuance, HMAC-signed QR credentials, public verification and durable Resend delivery.
Automated regression and database validation, GitHub Actions, feature gates, rollback, fallback and production recovery.
04 / ARCHITECTURE
05 / ENGINEERING CHALLENGES
Atomic fulfillment, deterministic identities and a durable email outbox let retries converge without creating duplicate orders or tickets.
Persisted event state, idempotency, database locking and authoritative Stripe reads make duplicate and reordered lifecycle events repeatable and auditable.
One purchase can produce two independent participant tickets, while Master Couple eligibility is enforced server-side before Checkout.
Signed QR credentials, authenticated check-in, atomic mutation and duplicate-entry rejection centralize entrance state in the backend.
Feature gates, a checkout kill switch, Google Form fallback, controlled rollback and targeted recovery tooling kept registration recoverable during launch issues.
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.