Designing a Race Course Athletes Can Argue With

The flagship course is 41.9 km with 1,216 m of climbing. Somewhere deep in its second half a tired runner will weigh a cutoff against their legs and decide whether the day ends at an aid station or a finish line. Building the website for that race, the Tahoe Skyrace at Heavenly's California Lodge in South Lake Tahoe, turned out to be a data-engineering assignment wearing a race-entry costume.

We think a race site should be two things: a route in data form, and a plan the athlete can argue with. An auto-playing hero video and a carousel of unforgettable scenery earn nothing from someone who has already decided to suffer and now needs facts. The facts on this site are engineering all the way down, from real recorded GPS traces as the source of truth to geometry that runs in the browser. The pace calculator is the part willing to tell a runner, plainly, that they miss the cutoff.

The source of truth is a Garmin Connect trace

Draw a course line by hand on a basemap and it inherits your optimism. Switchbacks straighten. A trail that traverses a hillside gets drawn as if it climbs it. An aid station lands where the spreadsheet wants it, not where the trail junction sits. Every athlete who knows the mountain finds the lie within one glance, and unearned trust lost there never comes back.

So the course lines on this site start as recorded activity traces downloaded from Garmin Connect in GPX form. They become GeoJSON with aid-station markups attached, and the app consumes that file directly at runtime. The marathon course weighs about 197 KB in that form, measured during the build. Traces carry the noise a real GPS recording always has, and we publish them as recorded rather than smoothing them. Smoothing trades a few honest meters of wobble for geometry that no longer matches the mountain. The course pages also offer the GPX and GeoJSON as downloads, which lets any athlete check our work against their own watch: the site stays verifiable, and verifiability is worth more than polish.

Geometry that runs on the athlete's phone

The site is static, so there is no backend to do the math. That constraint decided everything downstream, and it turned out fine, because the numbers a runner needs are cheap to compute in the browser.

Distance along the course comes from haversine sums over the trace. For the elevation profile, the line gets resampled to about 200 points, roughly one sample every 200 m on the marathon. Gain, loss, minimum, and maximum elevation are computed from those samples on every fetch rather than baked and forgotten, so the stats and the chart can never disagree with each other. Aid stations are placed by nearest-index projection: an aid station's coordinates get matched to the nearest profile index, close enough to be honest at this trace density and cheap enough to run on load. Looking up what the profile says at some intermediate position is a binary search over the resampled samples, so a cursor sweeping the chart costs effectively nothing. A unit toggle covers imperial and metric, and SportsEvent structured data sits in the page for calendars and search.

None of this required a map server, a database, or a budget. It required deciding that the geometry is part of the page, not a service behind it.

The replay: a runner tracing the line, keyboard first

Under each course sits an animated SVG replay: the route line draws itself start to finish while a small runner traces it. The view cycles through all three races, from the 3.94 km Vertical Kilometer through the 21.2 km half marathon to the flagship 41.9 km course. It is keyboard navigable, because part of the studio's own accessibility bar is that nothing on a website should require a mouse.

The first attempt used an off-the-shelf path animation from a charting library, and it died for a boring reason. We could not keep the runner's marker glued to the route path while keeping the animation scrubbable, because the library animated opacity and length but owned the timing. The replacement is a custom SVG renderer we control end to end. Why build it at all? An elevation profile tells an athlete the shape of a course. The replay tells them its story: the Cold Creek climb arrives early, and the Star Lake and Tahoe Rim Trail sections carry you into the high country. Athletes replay courses in their heads for days before deciding whether a race suits them. The replay puts that process on the screen.

The cutoff calculator earns the trust

Every course page carries cutoff tables, and the marathon additionally carries a pace calculator. Enter a target finish time and the page projects your arrival at every cutoff and issues a makesCutoff verdict: you make it, or you miss it. The projection runs on an even-split model, and the page says so.

This is the feature that turned the site from a brochure into a tool, in our opinion, for one reason: it will tell the athlete an answer they do not want. Race marketing tells everyone they can do it. A calculator that projects your target finish against a fixed set of cutoffs and concludes, from arithmetic you can inspect, that you arrive after the limit, is a different kind of conversation. It converts a feeling, the vague plan to figure it out on the climb, into numbers a coach or a crew member can argue with that evening. Argument is the point. A plan nobody can challenge is a hope with a timesheet.

The even split is wrong in useful ways

The model's limits deserve their own section rather than a footnote. On a course with 1,216 m of climbing, real pacing is front-loaded: strong runners bank time early and pay it back late, while everyone's second half runs slower than the first. An even-split projection is smooth, and mountain races are not, so the calculator's projected arrivals drift from reality in both directions. We keep the model anyway, because it is consistent and stated plainly, and because its bias is adjustable in your head: if you know you run negative splits, you already know how to shade the numbers. A biased model you can explain beats a precise one you cannot argue with.

The traces have limits of their own. GPS noise means small vertical artifacts, and a trace records one specific day's line, not the plat ideal of the course. We chose honest wobble over fake smoothness earlier in this piece, and that same choice is why an athlete with their own watch can find the discrepancies and trust the rest.

Verify it yourself

The whole stack is checkable by anyone. The traces are downloadable, and the geometry runs on your device where you can watch it. The calculator's model is stated next to its answer. That is the standard a race page should meet, because athletes are the most self-quantifying audience on the internet and they own watches that disagree with you. Marketing makes them curious. The trace lets them decide.