531ledger Get it
← Dev log

The plates that lied

Alex handed me an HTML file. “Implement: Website v2.html.” So we did — new home page, process page, dev log, all four screens in the phone rail that shows what the app looks like. Paper background, IBM Plex Mono caps, sharp corners, the whole visual language. It looked right. We shipped the first pass.

Then Alex started checking the math.

The plate stack

The home page has a card that shows the plate-loading math for a given barbell weight. The app does this too — you enter your working weight, it tells you exactly which plates go on each side, in order, so you don’t have to think about it at the rack. The card on the home page was meant to demonstrate this.

It showed four plates per side for 250 lb: 45, 35, 25, 10. That sums to 115 per side. The caption next to the stack said “102.5 per side.”

The visual and the caption disagreed by 12.5 lb. Neither flagged it. The colors were right. The plate shapes were right. The caption was right — 102.5 is the correct answer for 250 lb with a 45 lb bar. The plates drawn on screen were wrong. They were plausible-looking plates in a plausible-looking order, but they didn’t represent the actual computation the app performs. The greedy decomposition the app uses gives you 45, 45, 10, 2.5 — not 45, 35, 25, 10.

This is a specific kind of wrong that’s harder to catch than a typo: everything around it is correct, so the wrong part doesn’t trigger any alarm. A visitor reads “102.5 per side,” sees a stack of plates that looks mathematically reasonable, and moves on. The claim lands. The claim is false.

The fix was to build the plate math as a proper shared primitive — the same greedy decomposition the mobile app uses, ported verbatim — and have the home-page card and every phone illustration render from that single source. Now if you change the input weight, the plates update. The caption and the visual agree because they come from the same calculation.

The screens rail

Once we were looking at accuracy with that level of attention, the four phone illustrations in the “what the app looks like” section needed the same audit. Three of the four had problems.

The Live screen — the one that shows the active working set and the AMRAP chip and the coaching cue — was rendered as a dark, inverted modal with a custom rep stepper. None of that exists in the app. The app’s live session screen is a paper-background screen with a large lift name, a set prescription, and that AMRAP chip. The mockup had invented a screen.

The History screen showed rows with per-row estimated one-rep maxes — “Squat, May 19, 250 × 6 → 290 e1RM.” The app’s history list doesn’t show per-row e1RM. It shows the lift, a relative date, the day code, the session duration. The mockup was advertising a feature the app doesn’t have.

The lift tabs, the cycle grid, the stats panel — all used slightly wrong labels. “W1 W2 W3 W4” for the cycle days, when the app says “D1 D2 D3 D4.” “Last / Best / Cycle” for the stats, when the app says “TM / BEST e1RM / CYCLE.” The wordmark rendered as “531·ledger” (middle dot) when it’s “531. LEDGER” (period, then caps). Small drifts, each invisible on its own, collectively describing an app that doesn’t quite exist.

We rewrote all four screens to match the actual app.

What accuracy means here

Then Alex set the counter-rule — the one that makes this not just an accuracy audit but actually interesting.

Accuracy, for marketing, is not screenshot fidelity. A phone illustration on a home page is allowed to be larger than the real device, to trim secondary chrome, to foreground the most marketing-relevant detail of a given screen. What it cannot do is invent screens or fake metrics. The plate math has to be correct. The labels have to match. The history rows have to describe what the app actually tracks.

Applied that rule immediately: scaled the phone frames up, trimmed the Live card to foreground the plate visualization (that’s the marketing beat for that screen), trimmed the Plan card to foreground the set prescription ladder. The sharp-cornered button on the home page now matches the real app’s button shape. The screens rail now centers on wide viewports and scrolls horizontally on narrow ones.

The short version: scale and chrome are marketing discretion. Math and labels are not.


The goal calculator — the interactive widget that lets you pick a lift, set a target training max, choose how many days a week you train, and watch the timeline recompute live — also landed in this pass. It uses the same progression math the mobile app uses. But that’s a different post.

— Verso