I Built a Tool Because "It Looks Hard" Isn't a Race Strategy.

If you've been running for a while, you know how this goes. You start with a 5k. Then a 10k. Then someone talks you into a half marathon, and before you know it you're signing up for a 50k in the woods at 5am wondering how your life got here.

That's trail running. And once you're in, you're in.

Here's the thing about trail ultramarathons that nobody really warns you about upfront: the distance almost doesn't matter. Road runners have clean reference points. You ran a marathon in 4 hours, you have a pretty good idea what your next marathon looks like. But tell me you ran a 50k ultramarathon and I still don't know anything useful. Which 50k? Where? What was the terrain like?

Because a 50k is not a 50k.

Take two real examples. Seneca Creek Greenway 50k in Maryland — rolling single track, about 2,200 feet of elevation gain, the kind of race where strong runners finish around six-seven hours. Now look at Speedgoat 50k in Utah. Same distance on paper. But Speedgoat has over 11,500 feet of elevation gain. Nearly five times more climbing. The same number of kilometers, a completely different universe of effort.

That gap is what trail running is actually about. Not the distance. The terrain.

The Problem With "Just Looking at the GPX"

The best way to know a course is to run it. Or at least drive out and walk parts of it. If the race is close to home, that's doable. But what if it isn't? What if you're traveling for a race, or signing up months in advance based on whatever information the race website gives you?

You can pull up the GPX file. Sure. Most races publish them. You open it in Strava or Garmin Connect and stare at an elevation profile. And then what?

Can you look at a profile and tell me whether 2,500 feet of gain is going to hit differently than 12,500 feet? Can you compare two courses you've never run and figure out how your time on one translates to a reasonable expectation on the other? Maybe. But it requires the kind of mental math most of us aren't doing accurately at midnight before a race.

And even if you're decent with numbers... are you asking the right questions? Elevation gain is one thing. But how that gain is distributed matters just as much. A course with three massive climbs hits differently than one with the same total gain spread across thirty rolling hills. The steepness of individual segments matters. The back half versus the front half matters.

This is the problem I kept running into. And I'm someone who thinks about this stuff a lot.

Who Built This and Why

My name is Recep Zerk. I'm a digital literacy advocate, an ultramarathon runner, and what the internet has started calling a vibe coder — someone who builds small tools when a problem bothers them enough. I've been thinking about the intersection of artificial intelligence, human agency, and technology for years. But I'm also someone who laces up at 5am and runs through the woods for fun.

Those two things don't always overlap. But sometimes they do.

This tool came out of a specific moment. I am preparing for Catoctin 50k in Maryland (as of the time of writing, June 2026) — a rocky, technical course where the race director cheerfully describes it as "always uphill no matter which direction you're going." I'd already run two 50ks, including Seneca Creek. But Catoctin felt different when I previewed part of the course. The terrain was harder. Some sections didn't feel runnable in any meaningful sense.

I wanted to know: compared to what I've already done, how much harder is this actually going to be? Not a vibe. A number.

So I built Trail Route Comparator.

The Science Behind It

The tool runs on a model developed by Alberto Minetti, an Italian biomechanist who published two landmark papers in 1994 and 2002 on the energy cost of running at different gradients.

What Minetti found is that the relationship between slope and effort isn't linear. On flat ground, running costs a certain amount of energy per kilometer. As the gradient increases, that cost rises — but not evenly. At around 15 to 20 percent gradient, something interesting happens: walking becomes more metabolically efficient than running. The curve breaks. You're not being lazy when you hike a steep climb. You're being smart.

The descent side is just as important. Steep downhills force your quads into eccentric contractions — they're lengthening while under load, essentially acting as brakes. That's the kind of muscle work that causes damage. The soreness two days after a race with big descents isn't from the climbing. It's from the braking.

Minetti's model lets you calculate a "flat-equivalent distance" for any course. A hilly 50k might have the same metabolic demand as running 65 kilometers on flat ground. That number — the effort ratio — is what the comparator uses to put two courses side by side.

What the Tool Actually Does

You upload two GPX files. One is a reference route you've already run — a course where you have a real finish time. The other is your target race. You enter your reference time of reference course , and the tool does the rest.

What comes back isn't just a number. You get the effort ratio for both courses, a finish time estimate for the target based on your reference performance, and a terrain breakdown showing how each course distributes its runnable sections, moderate climbs, walk zones, and steep descents.

There's also an effort distribution section that compares the first half and second half of each course. This one matters more than people realize. A back-loaded course — one where the hard climbing comes late — requires a completely different race strategy than one that front-loads the difficulty. The tool flags this and gives you a plain-language read on what it means.

If the target course has significantly more steep descents than your reference, you get a separate warning about eccentric muscle load. Because showing up to a technical descent race without knowing that's coming is how you end up unable to walk on Monday.

The tech is simple by design. Vanilla HTML, CSS, and JavaScript. No backend, no accounts, no data leaving your browser. Your GPX files stay on your device. I built it this way because I've used enough running tools that bury the insight under layers of dashboards. The night before a race, you don't need a dashboard. You need an answer.

What It Can't Tell You

I want to be straight about the limitations, because precision matters here.

The tool works from GPS elevation data, which can be off by five to ten percent depending on the device and conditions. Surface conditions aren't accounted for — mud and loose rock can add thirty percent to actual effort regardless of what the gradient says. And the time estimate assumes your fitness is consistent across both efforts, which of course it isn't always.

Most importantly: the tool doesn't know you. Your training history, how your body handles heat, whether you've been sleeping, how well you fuel — those are still yours to manage. What the comparator gives you is a better starting point than staring at an elevation profile and guessing.

A Note on Why I Build These Things

I spend a lot of my professional time thinking about how technology shapes human agency — how the tools we use either expand or constrain our ability to understand the world and make decisions in it. That's the thread running through most of my writing and research.

Building running tools is the same instinct applied to a different problem. Trail runners have access to a lot of data. What they often don't have is the right question, or a simple way to get to an answer. This tool is an attempt to close that gap — not by adding complexity, but by removing it.

If you're preparing for a trail race and you want to know what's actually waiting for you out there, give it a try. The code is open source on GitHub.

You can find all the running tools I've built so far at here.

*

And whatever course you're running — good luck out there.