The Line You're Actually Running

A runner sets a goal: 10 kilometers in 45 minutes. That's 4:30/km, the whole way. At kilometer 7 her watch shows 4:32/km. What she needs to know in that moment is whether 4:32 at km 7 means she's on her way to the finish, or already past it. Her watch shows the number. It does not answer the question.

This is the specific gap I've been staring at for the last two weeks. It's the thing that separates the during beat of an experience from the after, and it's the thing the July-forward version of Sledge has to close before any of the rest of the loop matters.

What Every Watch Already Does

Let me name this honestly, because it's important to the argument. Strava shows real-time pace. Nike Run Club shows real-time pace. Garmin, Coros, Suunto — every serious watch on the market shows real-time pace, and most of them show it well. If the argument were that pace is invisible during a run, the argument would be wrong. Pace is a solved problem.

Here's the specific way the current tools fall short, though. Look at what a running dashboard actually shows you today: a pace number, a split, a projected finish, a percentage complete, maybe a small chart. It's the same visual language as a stock trader's terminal. The runner has become a day-trader, interpreting live numbers, mid-run, in real time. That's the tell. When your run looks like a stock chart, something is asking you to do a job the software should be doing.

What is not a solved problem is what that pace means, live, for the specific runner running the specific run. That's a different layer. And once you see it as a different layer, the gap gets obvious.

The Question Runners Actually Ask

Ask a runner what she wants to know at km 7 of a goal 10K, and she will not answer "my current pace." She already has that. What she wants to know is a small set of things her watch is not currently telling her:

Am I ahead or behind? Not against yesterday's casual jog. Against today's goal, at this exact point. Am I on target for 45:00, or is the finish quietly slipping to 45:45?

Will I make it? If I hold this pace, does the projected finish still land inside the goal? Or has it drifted, and if so, by how much? A number I can act on, not one I discover in the recap.

What should I do at the next km? If I'm 8 seconds off my usual pace at km 7 — the point on this route where I always drop 8 seconds — that's not a warning. That's a pattern. But if I'm 8 seconds off at km 3, where I normally cruise, that's a signal to reset the plan.

None of those questions are answered by the number on the watch. All of them require the same thing the watch doesn't have: a comparison against the runner's own history, at this point, on this kind of run.

You Know Your Numbers. Sledge Knows Your Patterns.

This is the sentence that's been sitting on the whiteboard for two weeks, and it's the sentence that explains the whole shape of the next quarter of work. Pace on the wrist is a solved problem. Pace matched against your own shape at this point on this route is not. That comparison is the wedge.

Think about the specificity. A runner who has done this exact 10K route six times has a shape: a curve of where she cruises, where she pushes, where she drops. km 3 fast. km 7 quiet. km 9 push. That shape is real, and it's hers, and it's the only honest reference for whether the pace on her watch right now means anything. "4:32/km" is a number. "4:32/km — 8 sec off your usual pace at km 7" is guidance. Same number. Different layer.

That second layer — the one that lives on top of the raw pace — is what Sledge is being built to hold.

Three Problems We Won't Ship Until We Solve

I want to be careful here, because building "a personalized live guidance layer" sounds easy in a blog post and is not easy in the code. There are three problems I've promised the team we won't ship past without honest answers, and I'm going to name them here so the promise is public.

GPS honest enough to trust. A confident-looking projection during degraded GPS is a lie. If Sledge tells a runner "you're 8 seconds off your usual" and the reason it looks that way is that GPS bounced through an urban canyon, we've broken trust in the very layer we're selling. So the rule is boring and non-negotiable: GPS-confident → solid number. Degraded → softened. Unavailable → a dash. Better to admit we don't know than to invent something that looks like we do.

Enough of your runs to know your shape. Personal-shape matching requires personal history. Not on run #1. Not on run #3. Somewhere past the point where the shape is statistically real. We'll say when it's ready — we won't guess before we know. In practice this means the layer turns on quietly, when the confidence is there, not as a shipping headline.

Numbers first. Labels second. The temptation, once you have the comparison, is to skip to the label: "you're behind." That word does more harm than help. A runner who's "behind" at km 7 on a route she always slows at km 7 isn't behind — she's on pattern. We'd rather show the receipts ("4:32/km — 8 sec off your usual at km 7") and let the runner draw her own conclusion. No judgment without evidence. Labels come later, if they come at all.

Running First. Everything Else, Later.

The last discipline is the one I keep having to remind myself of. This is not a running feature. Or rather — this is a running feature first, and only becomes something more if it works there. Every other activity has a version of this same layer. Gym has sets, reps, and rest countdowns. Hiking has elevation remaining and ETA. Cycling has power and speed targets. Learning has module progress. There is a general pattern here, and it's exactly the kind of pattern that gets built wrong when you build it in the abstract.

So we're not. We're building it for running, because running is the format where the pattern is cleanest, the data is best-behaved, and the runner's question is sharpest. If it works there, we generalize. If it doesn't, we've learned something specific about live guidance in running — not something abstract and wrong about every activity Sledge might one day touch. That's the "island by island" discipline from the June pitch deck, applied inside the during beat.

Why This Belongs In The During Beat

The previous post laid out the four beats of any real-world experience — before, during, after, and next — and named that the software people actually use tends to win one beat and lose the other three. This post is the sharpened version of what the during beat has to become.

Recording keeps what happened. That's the after. It's the beat we've been shipping into for the last month, and it's the reason a Sledge session already produces a real record. But recording doesn't help a runner hit a goal while she's running. That's a different job, done by a different layer, answering a different question. The during beat has to answer "am I on track?" the same way the after beat answers "what did we do?". Two beats. Two layers. One loop.

What's Next

Concretely: we're hardening the Execution layer for Interval Run first — the recording loop that captures the run cleanly, single-user, GPS-confident. That has to be solid before anything sits on top of it. Once it is, the guidance layer — the one that turns raw pace into "pace against your shape" — is the next investment.

The pitch deck names the loop as before → during → after → & next. The during is where the next quarter of work sits. And when it lands, it lands the way we've been saying it should: your line lives in the during, while you're running it — not forty minutes after.

If you run a group where this gap keeps costing you — a training crew, a race prep, a weekly interval club that keeps starting over because the last session never came forward — I'd like to hear about it. Reach me at contact@sledgeapp.com, or follow along at @buildingsledge where the paired carousel on this same idea drops today and its answer drops Sunday.