Stride

The problem

I wanted a coach for my own running, not another panel with the same numbers Strava already shows. The requirement was simple: a recommendation has to be explainable. If it says "easy run", it should be able to show which data pointed that way.

Constraints

• Data stays in Strava

  Stride pulls activities in through the Strava API. Strava's terms forbid sharing that data with AI providers, so runs must never end up in a model's context window. That is a constraint that shapes the architecture, not a detail.

• Advice has to be repeatable

  Same data in has to give the same advice out. That is why the recommendations are computed by a rules engine, not a model. It makes them explainable, testable and comparable over time.

• One user: me

  I test on my own phone and my own training. Every change gets judged against a real training block, not demo data.

Decisions

• Rules instead of prompts

  Load, recovery and session type are rules with names and an order. When the advice is wrong I can point at the rule that is wrong, instead of guessing whether the prompt was badly worded.

• Readiness as a moving average

  Readiness is a weighted moving average rather than a picture of the day. One hard session should register without collapsing the number, and a slow shift should be visible.

• Advice as components

  Recommendations arrive as typed blocks that render real React components — cards, charts and insights — instead of a text blob. A piece of advice can contain a chart without anyone cutting and pasting text.

Stack

• Next.js 16
• TypeScript
• Drizzle ORM
• Neon Postgres
• Recharts
• Strava API

What I took away

Building against a rules engine forces the decisions into the open: every rule has to be defensible and every exception has to be written down. It is more work than calling a model, and it is why the advice can be explained.