Shindo app icon Shindo

Blog

Engineering notes

Last updated:
Posts
3, on the engineering behind the app
Written by
Aleksandr Kolesnikov, who writes the code being described
Not a guide
These are dated accounts of decisions. The evergreen answers are in the guides
Feed
RSS

How the app is built, written by the person building it. Most of what is here concerns one problem: a training app is only worth using if its numbers can be trusted, and a language model is very good at producing text that sounds like a number and is not one. Everything below is some version of the boundary between the two.

These are dated and specific. Where you want the evergreen answer to a question — what readiness is, how to read fitness and fatigue, why a score is low on a morning you feel fine — the guides are written for that, and the methodology page documents every formula the app uses.

We let a language model write training plans — then built a validator to tell it no

Nineteen named rules, fifteen of them fatal, one retry, and a mandatory fallback the athlete never sees. Why a model can propose your week but never publish it.

One ride, two rows: the duplicate-workout problem in Apple Health

If two apps both saved your Saturday ride, Apple Health holds it twice — and anything summing training load doubles that day. The matching rule, the tolerances, and why refusing an import and deleting a row need different thresholds.

Why the AI in your training app should never do the maths

The model never sees a number it is allowed to change. A runtime guardrail overwrites any figure that drifted from the engine's — and the interesting part is what happened when we made that rule too strict.