Case study / Swim4Dreams

Building the digital infrastructure behind a real endurance event.

A bilingual registration, payment and operations platform built for Swim4Dreams / 72ore Swim for Dreams.

Role: Product / Engineering
System: Event platform
Stack: Next.js · Supabase · Stripe · Vercel
Status: Production

One event. Many connected decisions.

A physical endurance event needed more than a public website. Race selection, registrations, payments and participant information had to connect to the people operating the event. Multiple race formats, capacity limits and administrative validation made the operational rules part of the product.

Built within real operational constraints.

A fixed event date

The physical event set the readiness deadline for registration and operational workflows.

Real payments

Checkout had to connect payment status to registration state, not simply redirect to a payment page.

Different race rules

Multiple formats and capacity limits required distinct registration behavior, including pending validation for the 15 km race.

Manual and automated operations

Administrative review and bank-transfer approval complemented online payment workflows.

Two public languages

Participants needed access to the public experience in Romanian and English.

Changes with operational impact

Updates around the event had to account for existing registrations and the team running the platform.

A registration becomes an operational record.

Race selection
Cart
Checkout / Stripe
Registration
Participant data
Admin operations

Validation · Payments · Results · Standings

Technology organized around the workflow.

Public product: Next.js 16, TypeScript and Tailwind support the bilingual interface.
Application logic: Race selection, cart and registration logic connect participant choices to event rules.
Data: Supabase stores the platform’s operational records.
Payments: Stripe Checkout and webhook flows connect online payments to application state.
Operations: Administrative tools support participant and race management, result import and standings.
Delivery: Vercel provides the production deployment environment.

The product evolved with the event.

This was an operational system that had to adapt before, during and after the event. Registration rules, manual review and result management all shaped the implementation.

Before the event
Configure race formats and capacities, connect checkout to registrations and support administrative validation and manual payment handling.
Event operations
Give administrators control over participant and race workflows, with tools for result management and imports.
Beyond registration
Extend the platform into results, standings and post-event functionality as the event’s needs evolve.

A production platform used around a physical event.

The system supported real registrations and online payment flows, bilingual participant access and administrative control over participant and race workflows. Results and standings extended its role beyond checkout.

What this project demonstrates.

Product engineering: Translate operational requirements into software people can use.
Payment workflows: Connect transactions to meaningful registration state.
Administrative systems: Build tools for the team responsible for operating the product.
Production iteration: Adapt the system as real event requirements change.
Security-aware engineering: Treat payment, participant data and administrative workflows as production responsibilities.