Progression without a spreadsheet

The real competitor to a training app is not another training app. It is a spreadsheet.

Almost everyone who has trained seriously for more than a year has one. Rows for sessions, columns for lifts, a formula that adds two and a half kilos when last week went well, a colour that turns amber when it did not. It is ugly, it is personal, and it works well enough that people carry it for years.

Any app that wants to replace it should be honest about why it works. Three reasons, and all three are worth stealing.

It is explicit. You can see the rule. When the weight goes up you know precisely why, because you wrote the formula. Nothing is happening in a black box.

It is yours. You changed it when your own training told you to. It fits the way you actually lift rather than the way a programme author assumed you lift.

It never lies about certainty. A spreadsheet does not tell you it has optimised anything. It applies the rule you gave it, and you supply the judgment.

What the spreadsheet does badly

It has no memory of context and it cannot ask questions.

It does not know you missed two weeks. It will happily hand you the next scheduled jump after a fortnight away, because the rule says add two and a half kilos and the rule does not have a field for "was travelling". It does not know you slept five hours. It does not know you were eating six hundred calories under maintenance while it kept adding load.

And it will not deload you, because a deload is a judgment call and the sheet only has arithmetic. Everyone who lifts off a spreadsheet has at some point ground through four weeks they should have cut short, because the cell said 102.5 and arguing with a cell feels like quitting.

The engine

Our training engine is a function. Profile and history go in, a plan comes out. No network call, no model, no hidden state. Given the same inputs it returns the same plan, every time, on any machine.

That constraint is not an aesthetic preference. It is what makes the next three things possible.

It runs everywhere, as one implementation

The engine is plain TypeScript. It imports no React, no React Native, and no Node builtins. So the same file runs inside the phone app, runs on the server, and runs under the test suite. There is no second version of the progression logic that lives in a screen and drifts a fortnight later.

It can be tested as a whole plan

Every change to the engine ships with a golden case: a profile and a history in, a full plan snapshot out, committed alongside the code. When somebody adjusts a deload trigger, the diff shows exactly which plans changed and by how much. A progression rule that regresses a beginner's first month is visible in review rather than in a support message.

It works with no signal

Because the plan is computed on the device, a gym in a basement is the normal case. Every set you record writes to local storage first and renders immediately. Sync happens later, when there is a network, and no screen in the app is allowed to block on it. If a feature cannot work with no bars showing, it is not a gym feature.

What "adapts" actually means

The word is used loosely enough in this category to be meaningless, so here is what it means concretely in ours. Three inputs move the plan.

Completion. Did the prescribed reps happen at the prescribed load? Not "did you open the app" but what was actually recorded, set by set. Consistent completion with reps in reserve to spare raises load. Repeated misses hold it.

Accumulated volume. Working sets per muscle group per week, tracked over a rolling window. Volume that has climbed for several weeks without a break is the signal that schedules a lighter week, and it schedules it before the sessions start falling apart rather than after.

Attendance reality. A gap is a gap. Come back after two weeks and the plan does not resume where it stopped; it re-entries at a load the engine expects you to complete, and climbs from there. This is the single thing a spreadsheet gets most reliably wrong.

What does not move the plan is just as important. Your mood does not. A streak does not. Nothing about engagement enters the calculation, because a programme that responds to how often you open an app is optimising the wrong variable.

Keeping the parts of the spreadsheet worth keeping

Automation is only an improvement if it does not take away the three things that made the sheet work.

So the plan is explicit. Every session tells you why it looks the way it does: the load went up because the last three sessions completed, or this is a lighter week because volume has climbed for four. No screen in the app changes a number without being able to say what changed it.

And it stays yours. You can override any prescribed load, and the override is data, not a correction. The engine treats what you actually did as the truth and plans forward from there, which is the same thing you would have done by hand in the sheet, minus the evening spent re-deriving it.

The first fourteen days matter more than anything else here. The retention research is blunt about it: people who get fewer than three sessions into their first two weeks churn at several times the rate of those who do not. Every feature that adds friction to the first six workouts loses to any feature that removes it, and that includes clever ones. A programme that is ready before you are asked for an account beats a programme that is better on paper and arrives on day three.