base.

Strength and endurance want opposite things from you. Lifting asks for a surplus and enough recovery to adapt; distance work burns through that surplus and takes the recovery with it. Train for both and the deciding variable stops being either programme and becomes the arithmetic between them.

Every app I tried owned one third of that. Lifting apps track volume and know nothing about a four hour ride. Running apps track pace and treat a heavy squat day as a rest day. Nutrition apps hold a calorie target still, which is the one thing it cannot be when your burn swings by 1,500 calories depending on what you did that morning.

So the product is not a lifting tracker with a run tab bolted on. The unit is the day, and the day has to reconcile three things that disagree.

The most load-bearing screen in the app is a single line under the macro rings: the target, written as the sum that produced it. On the day in the App Store screenshots it reads as 4,157 calories, made of 3,507 burned so far plus a 250 surplus plus 400 carried over from the day before.

Showing the identity rather than the result is a deliberate product decision and it came out of an engineering one. A target that moves during the day looks broken if you cannot see why it moved. It goes up because you trained, and unless the app says so, the user assumes a bug and stops trusting the number that the whole plan rests on.

The carry-over term is the part that took the longest to get right. Days do not settle at midnight for someone who trains in the evening, and a strict daily reset punishes an athlete for the schedule rather than the behaviour. Letting a deficit or surplus roll forward is closer to how the body actually accounts for it, and it turns a hard boundary into a moving window.

The health monitor reads six signals: respiratory rate, resting heart rate, heart rate variability, blood oxygen, body temperature and sleep. Each is labelled against the user's own history rather than a population norm, so a resting heart rate of 61 reads as Higher because it is higher for that person, not because 61 is high.

That personal banding is the reason the integration is harder than calling HealthKit and drawing the result. HealthKit is a shared store that several devices write into, so the same workout can appear twice from a watch and a phone, values arrive out of order and backfill days later, and a gap in the record is indistinguishable from a genuine zero. Anything that computes a baseline has to be built on the assumption that yesterday's data can change after you have already shown a conclusion drawn from it.

Sleep gets the same treatment one level deeper. The stage chart is banded per stage against what the current training week asks for, so 136 minutes of REM reads as optimal inside a 114 to 143 minute range that itself moves with the load. That range is derived, which means it is only as good as the history behind it, and early on there is not much history. Being explicit about which numbers are measured and which are derived from a short record is the honest version of this feature.

The app is Expo and React Native in TypeScript, with Expo Router for navigation. Supabase and Postgres sit behind it, with Drizzle for typed schema and migrations, and expo-sqlite holds a local copy so the day's plan opens without waiting on a network call.

HealthKit is reached through a native module rather than a polling loop, because the useful events are the ones that arrive while the app is closed. The Apple Watch app is its own build target with its own Swift module, which is the part of this project I would point at first: an Expo app and a watchOS target sharing one plan without either becoming a wrapper around the other.

The watch deliberately does very little. It shows the session you are in and the numbers that change while you are moving. Everything that requires typing, reviewing or deciding stays on the phone, because a watch is a glance and treating it as a small phone is how watch apps end up unused.

This shipped on 18 September 2026 at version 1.0, and the honest status is that the adaptive planning is the least proven part of it. Adapting a target is a control problem, and a control loop with a short history and a noisy input will oscillate if you let it react too fast. The current version damps hard and is deliberately slower to respond than it could be, which is the right default and not the right answer.

Android is partly in the codebase and not shipped. The Health Connect integration exists, the App Store build is iOS only, and there is no Play Store listing, so this page says iPhone and Apple Watch.