UNSTOPPABLE: the coaching platform I built to run my own way

A production fitness coaching app that carries the repetitive parts of coaching for me. It schedules around real life instead of a calendar, adjusts each client's weights and reps automatically from what they actually did, and gives clients an AI coach when I'm not reachable. Five clients train on it live today.

What was actually going on. I was delivering coaching through an off-the-shelf platform, and the tool made me do work the software should have done. Every new program was built by hand. Everything was locked to a calendar, and general population clients are not consistent by nature. They miss days, they push a week out, life happens. When it did, either I moved their days around or they did, and either way I lost a clean picture of what actually got done and when. On top of that, weekly progression was fully manual. After each week I opened every client, read what they lifted, and bumped weight or reps or adjusted strength percentages one line at a time. I wasn't short on coaching knowledge. I was short on a system that could carry it.

What I decided, and what I ruled out. The first fork was build versus configure harder. I built, because the two things I needed most were the two things the platform fought me on.

I cut the calendar. On the client side, days are not tied to dates. If a client pushes the program out three weeks, the days ride with them and my picture stays clean. The calendar still exists on the backend where the data needs it, but the client never trains against a date. The alternative, keeping the calendar and managing the drift by hand, was the exact problem I was trying to leave.

I automated the weekly adjustment. The system reads each client's logged performance and moves their loads and reps for the next week on its own, across several progression styles. The rejected path was to keep doing it by hand, or to hardcode one progression rule. Neither survives contact with real clients who each need a different model.

Underneath both, one architecture call holds everything together. When I assign a program to a client, it becomes an independent copy, not a live link back to my master template. I designed it that way on purpose. Templates are never one-shot perfect, and every client's program drifts from the template almost immediately as I fit it to what they like. If a client's program pointed back at the master, one edit would silently rewrite everyone else on that template, and a delete could take client history with it. For a coaching product that is unacceptable, so I ruled out the normalized approach early and built the snapshot model.

The build method was its own decision. I am not a developer. I am a problem solver who can make the calls a developer makes and hand implementation to Claude Code. I designed the data model and the behavior, wrote the specs, and let the AI build against them, with a test suite growing underneath the whole thing (1,600+ tests). The AI inside the app is routed on purpose too. A lighter, faster model handles everyday client chat, a deeper model handles the heavier work like check-in synthesis and nutrition, and the client only ever hears one voice. One model for everything would have been too expensive or not sharp enough where it counts.

One decision was about trust, not code. Client check-ins run through me, not straight from the AI to the client. The AI can prepare and observe, but a human approves before anything reaches the person paying for coaching. If a client is paying me while the AI quietly runs their check-ins and I never look, that is the moment the relationship breaks. So I kept myself in the loop to catch what the AI glosses over.

The honest soft spot is progression. The rules look correct and then one case slips, a weight or a rep that should bump and doesn't. To a client trying to progress, that reads as a regression or stale data, and it is frustrating. I ran a health audit, found the cases that were silently corrupting data, closed them, and built tests around them. I won't claim it is fully sealed, because that class of bug can still surface, and I would rather say that than pretend otherwise. The AI coach can also drift or stall mid-response, which I manage by tuning the prompts, and there is still work there. Right now clients mostly use the app to log rather than to talk to the AI, which tells me the AI experience still has to earn its place in how they actually train.

The work that used to eat my week mostly runs itself now. Scheduling bends around the client instead of forcing the client to bend around a calendar. Weekly adjustments come from real data instead of by hand. And the coaching system holds its shape whether I am watching it that day or not.

If I started today I would plan it tighter up front. This began as one-shot prompts while I felt out the whole app, and I would trade that for scoping each piece carefully from the start and designing to the end outcome instead of iterating my way toward it.