Fifteen phases in eight days.

Spotter is a training operating system for strength athletes and the coaches who program for them: a plan that is always ready, a fast way to log what was lifted, and a coach loop that runs on the same screens. On 28 August it was a workout logger with a design system and a lift page. On 4 September it was live on its own domain with a planner, a queue, a coach seam, backups, a privacy statement and a landing page, and on 6 September the coach pitch joined them. This note is the record of how that happened, because the numbers surprised the person who wrote the estimates, and the reason is worth writing down.

The record

Every piece of Spotter is built as a numbered phase with a definition of done, and each phase ships as one pull request that deploys on merge. Between 28 August and 4 September, fifteen phases merged — twelve through twenty-six — in eight active days. Two more followed on the 5th and 6th.

What those phases are, in the order they run for an athlete: a program is blocks, weeks and days, each day a list of lifts with a prescription — sets, reps, and a load as a weight, an RPE, a tempo or a percent of a training max. The queue turns the next day into the next session, prescription already typed. Logging a set is one tap, and a set logged on gym signal is kept and replayed rather than lost. A finished session is a record and never changes. Every lift has its estimated one-rep-max curve and the sets behind it. A coach invites an athlete, writes a program, assigns it, edits next week and reads what was lifted — through the athlete's own screens, never a dashboard.

Every estimate was too pessimistic, in the same direction

The delivery estimate is kept in the scope document with its assumption attached, and it was revised five times. On 28 August it said early access would open around 8 November. Two days later, around 17 September. On 1 September, around the 10th — and then, the same day, around the 14th, because five phases of non-code work were added (backups, legal text, the landing page, the pitch, the notes you are reading). On 2 September, the 10th again. On 5 September, the 8th. The last three held.

Three consecutive under-calls, each written after explicitly warning against extrapolating from a good week, is a bias, not variance, and it had one cause. Each phase was priced as if it included its own discovery. It did not. Every phase arrives pre-designed: a handoff document, verified against a named commit, with the open questions listed and the conventions that will bite written down. That design work happens in a session before the build and never shows up as a day against the phase it belongs to. The project runs a design-ahead pipeline; the estimate modelled design-then-build, and counted about half of every phase twice.

The corollary is the useful part: the numbers are only reliable while a handoff exists for the next phase. The bias stopped the moment it was priced in, which is the evidence that the diagnosis was right rather than a coincidence.

Cadence, not velocity

The repository's history before 28 August showed twenty-one active days in a hundred and two, with two silences of forty-seven and sixteen days. Throughput on an active day was high — roughly one roadmap item per day — and the constraint was never how fast the days went. It was how many of them there were. The last twelve calendar days had eleven active ones. That is the whole difference between November and September.

The pace was not bought with quality. The test count went up by two hundred and fifty-five in eight days; every pull request ran green in CI; the migration count in production matches the repository; and every user-reachable bug found in the field got a regression test that was shown to fail before the fix went in.

What was done early, on purpose

Three things were pulled to the front of their blocks because they had never been done in this repository and so carried the widest error bars. Deploying came at phase sixteen, before the planner, so that every phase after it shipped to a live system and was dogfooded there. Two production incidents came out of that — a session that recorded nothing and could not leave the queue, and a database blip that would have sent one error report per request in flight — and both are the kind no amount of local testing surfaces. Backups came before the coach features: a nightly dump to object storage, point-in-time recovery, and a restore actually drilled and reconciled against live, because a backup nobody has restored is a hypothesis. And the privacy statement and terms led the marketing block, because legal text is an hour or a week depending entirely on how carefully it is treated, and an unknown resolved first leaves room.

What early access will measure

Spotter opens to a small cohort of coaches and their athletes, by invitation, and it runs for four weeks from the first assigned program. It exits on evidence, not a date. Three things are measured, weekly, from a read-only pass over the database and the request log — there is no third-party analytics in the app, and the privacy statement says so.

• The coach funnel. Invited, accepted, first program assigned, first edit to a future week. The last step is the one that means a coach is working in Spotter rather than trying it.
• Assigned sessions logged, as a raw fraction. Adherence is shown as it happened, to coaches and to us; there is no readiness score, no compliance percentage, nothing invented between the athlete and the bar.
• The spreadsheet. Whether each coach is still updating it, asked every week. That is the only number that decides whether early access passed.

Bugs from the field go into the repository's known-bugs record the same day they are reported, with the reporter's role, and are fixed with a test. The next of these notes will be written from what breaks and what coaches say.

If you coach strength athletes and program in sets, reps and load, the coach loop is described in full, and the door is the same as everyone's.