Most running apps compete on features. More metrics, more graphs, more data points, more things to track. The assumption is that more information makes you a better runner.
It doesn’t. More information makes you a more distracted runner. And distraction is the enemy of consistency.
Pacewright deliberately ignores several things that other apps track. Each omission has a specific reason.
Wind
Pacewright adjusts for heat, humidity, and altitude. It does not adjust for wind.
Why not? Because wind is genuinely hard to do well. Unlike temperature and dew point — which are consistent across a region and measured reliably — wind speed and direction change moment to moment and vary with terrain, buildings, trees, and which direction you’re running. A headwind on the way out becomes a tailwind on the way back. A calm start can turn gusty mid-run.
A bad wind adjustment — one that tells you to run slower when the wind isn’t actually affecting you, or doesn’t adjust when it is — is worse than no adjustment at all. We’d rather tell you to use RPE on windy days than give you a number that’s probably wrong.
Cadence
Your watch tracks your steps per minute. Pacewright doesn’t use it.
The “optimal cadence is 180 steps per minute” advice has been repeated so often that it sounds like settled science. It isn’t. That number came from Jack Daniels observing Olympic-level runners at the 1984 Games. It describes what fast runners do at fast paces — it doesn’t prescribe what slower runners should do at slower paces.
Cadence varies naturally with pace, height, leg length, and running experience. Artificially increasing your cadence to hit 180 often creates an awkward, choppy stride that wastes energy. Your cadence will naturally increase as you get faster and more efficient. There’s nothing for the algorithm to do with it.
Sleep and Stress Scores
Your Garmin or Apple Watch might give you a “body battery,” stress score, or sleep score. Pacewright ignores all of them.
Not because sleep and stress don’t affect running — they absolutely do. But because the data quality varies wildly between devices, and the correlation to running performance is too noisy to be actionable at the individual level. Your watch might say you got “poor sleep” when you felt fine, or “great sleep” when you woke up exhausted. Building training decisions on unreliable inputs produces unreliable outputs.
RPE already captures the downstream effect. If you slept badly, your RPE will be higher — and the training load calculation will reflect that. The signal gets into the system through effort reporting rather than device estimation.
Machine Learning Predictions
Pacewright uses mathematical models with published formulas — Riegel, VDOT, Critical Speed. It does not use neural networks, AI models, or any form of machine learning.
This is the core design philosophy, not a technical limitation. Machine learning models are black boxes. They produce predictions that may be accurate but cannot be explained. “The model says you’ll run 51:30” doesn’t tell you anything useful. “The Riegel formula says 51:30 because your 5K time implies a fatigue factor of 1.06, which projects to this 10K time” tells you everything.
Transparency requires explainability. Explainability requires models you can show your work on. ML will be considered in the future — but only if we can maintain the transparency standard.
Pace Data From Group Runs
When you run with a group or a partner, Pacewright counts the training load (duration × RPE) and the consistency (you showed up). It does not use the pace data for fitness trend analysis.
Why? Because your pace during a group run reflects the group’s pace, not your fitness. If you ran 9:00/mile because that’s what your running partner does, that number shouldn’t influence your predicted race time or your aerobic trend analysis. It’s someone else’s signal.
The “10% Rule”
Pacewright deliberately ignores the universal “never increase more than 10% per week” advice. Not because load management doesn’t matter — it’s the foundation of the entire system — but because 10% is the wrong number for most runners.
A runner at 10 miles per week can safely increase by 20% (2 miles). A runner at 60 miles per week should increase by no more than 5% (3 miles). The absolute increase is similar, but the percentage is radically different. A universal 10% is too conservative for beginners and too aggressive for experienced runners. Pacewright uses mileage-dependent caps instead.
”What If” Scenarios
There is no “what if I ran 50 miles this week?” simulator. Running a hypothetical scenario requires calibrating how your body would respond to a training load you haven’t done — which is speculation, not prediction. We’d rather not show you a number we can’t defend.
Apple HealthKit and Google Fit
Pacewright integrates with Strava and Garmin. It does not integrate with Apple HealthKit or Google Fit.
HealthKit requires a native iOS app. Pacewright is a web app — it runs in your browser, on any device, without installation. Building a native app solely for HealthKit integration would mean maintaining a separate codebase for a single data source.
Google Fit stopped accepting new integrations. It’s a dead platform.
The Philosophy
Every feature in a training app has a cost. Not just the engineering cost — the cognitive cost to the user. One more number on the screen is one more thing to worry about, one more thing to optimize, one more thing that can make you feel like you’re doing it wrong.
Pacewright’s approach: include what the science supports, explain how it works, and leave out everything else. If a metric doesn’t change what you should do on your next run, you don’t need to see it.