CircuitSync.
A browser-based live timing app for a local autocross program — reading run times straight off the track timer in the browser, now growing into a hosted SaaS.
The problem.
A local autocross program was recording every run time by hand on a notepad — and the software they'd bought to fix it was somehow worse.
They'd already purchased a dedicated timing package and brought me in to set it up. It turned out to be an archaic Windows app that hadn't been meaningfully updated since the early 2000s: dense, brittle, and far too complex to actually deploy. Getting it working wasn't realistic, and even if I had, nobody on the team would have been able to run it on their own.
What the program actually needed was simple: drivers who could register themselves, run times that landed on a live leaderboard instead of a notepad, and season standings that added themselves up. None of that required six-figure software — it required something built for this one event.
Approach.
Instead of fighting the purchased software, I found a free browser-based autocross timer that read the track timer directly through the Web Serial API. That was the unlock: a modern web browser could talk to the timing hardware itself. Leaning on my web-development background, I built a purpose-made browser app for the program around that idea.
- Front of house: SvelteKit for the public-facing site: registration, live leaderboards, schedules. Fast, server-rendered, cheap to host.
- Data layer: PocketBase for the single-client build: single-binary, embeddable, with real-time subscriptions out of the box, exactly what live scoring needs.
- Hardware input: the browser reads the track timer directly over the Web Serial API, normalizes each run, and writes it straight to the backend — no extra middleware to install on event day.
- Displays: a dedicated venue-display route with type that scales to whatever screen it runs on, big enough to read from across the paddock, auto-rotating between the leaderboard, fastest run, and session info.
The one thing a browser tab can't fully guarantee is offline reliability, and venue wifi never is — so the SaaS build is moving timing into an offline-capable desktop app. It keeps capturing runs with no connection, then syncs to the CircuitSync servers the moment it's back online, pushing any changes automatically and prompting the user to resolve conflicts when they come up. The data layer is migrating to Supabase to back it.
What I built.
- QR-code registration: drivers scan a code at the gate, fill out the form once, and their car number plus class are linked to their profile for the rest of the season.
- Live timing & scoring with WebSocket-driven leaderboards. Each run lands in the backend and every connected client updates in under a second.
- Venue display: a full-bleed, auto-rotating screen for the timing tent and spectator areas, readable from across the paddock.
- Email results delivery: results emailed to every entrant automatically when the session is finalized.
- Season championships: per-class point tables that aggregate across the whole season, no spreadsheet required.
- Event management: the organizer runs the day from one dashboard: sessions, entry lists, classes, late entries.
Because it was built around one program's real event days, every feature came from watching how the day actually ran — the conversations on site surfaced what was genuinely missing, not what looked good on a feature list.
Results.
CircuitSync replaced the notepad for the program it was built for. Drivers register themselves, run times hit a live leaderboard the moment a car crosses, and championship standings tally themselves across the season. What started as a one-off custom build is now being turned into a multi-tenant SaaS — the data layer is migrating from PocketBase to Supabase, and timing is moving into an offline-capable desktop app that captures runs without a connection and syncs back to the servers once it's online.
What I learned.
Reading the timer directly in the browser meant the whole flow — a car crossing the line, the leaderboard updating, the results email going out — lived in one app with nothing extra to install on event day. Owning that path end to end let me ship things a thin UI over someone else's backend never could.
It also meant learning the operational side: what an autocross day actually looks like, where the workflow breaks down at 2pm in the heat, and what whoever's running registration needs the screen to do. The most valuable hours weren't in the code; they were on site at the event.