Barqlane

Problem

Endurance-event organizers in the GCC were running registrations, race-day check-in, and results on a patchwork of spreadsheets, generic ticketing tools, and manual lists — none built for a race. Bib assignment, waivers, minor-guardian consent, waitlists, and finisher results lived in separate places, so a single event meant reconciling several systems by hand. Runners had no single home for their registration, race-week prep, or results.

Approach

We built Barqlane as one Next.js 16 application on a Drizzle + Neon Postgres backend, organized around three roles (runner, organizer, platform) over a single auth model. Registration is a guided state machine — auth or email-OTP guest entry, category selection with live capacity, the full runner form with age-at-race-date and conditional minor-guardian fields, waiver acceptance, then payment for paid events — with idempotent waitlist join and promotion behind it. Payments run through Amwalpay's SmartBox with HMAC-signed checkout and a webhook-authoritative reconciliation path (redirect-back and inquiry-poll fallbacks), with an atomic guard so audit, email, and discount redemption fire exactly once. Race day is covered end to end: QR check-in with an offline-replay idempotency guard, walk-up kiosk registration with atomic bib allocation, CSV results import, public results and age-group leaderboard pages, and auto-rendered finisher PDF certificates precomputed via Inngest. A 15-second live operations snapshot gives organizers registered / checked-in / on-course / finished counts per wave.

Outcome

Barqlane is live in the GCC as our own product, taking real paid registrations settled through Amwalpay. Organizers run an event from creation through race-day operations to published results in one platform — registration, check-in, walk-up kiosk, results, and finisher certificates — instead of stitching together spreadsheets and generic tools. Runners register, prepare, race, and collect a finisher certificate without leaving the platform.