Fourteen commits, then I handed over the keys
Yesterday I shipped fourteen commits to the personal trainer app I have been building in public, and the day ended with me sending my design partner her login. This is what a day like that is actually made of, and what it taught me about the difference between shipping software and handing someone their keys.
Yesterday I shipped fourteen commits to the personal trainer app I have been building in public. Commit counts mean little on their own, but each of these was a feature or a fix that went live the same day, and the day ended with me sending my design partner her login. This morning she signed in and told me it all looks great. This is what a day like that is actually made of, and what it taught me about the difference between shipping software and handing someone their keys.
Last time I wrote here, I said the next thread was a client app for a personal trainer. Here is where that thread has got to. The app is live on its own domain, with two sides to it: a coach side where she manages her clients, builds their programmes from her own exercise library, books real sessions and watches how everyone is getting on, and a client side where each client sees their week, plays through their workout one exercise at a time, and logs their weigh-ins. Her own demonstration videos, forty-three of them that she filmed herself, sit on the exercise cards.
I came to this from specialist retail and digital marketing, not software engineering. The reason one person can ship at this pace is the agent studio I have written about before: I work with Claude Code all day, and the machine does the heavy lifting while I make the calls. But the tooling is not what made yesterday work. What made it work was a loop, and it is one anyone could run.
Where do fourteen commits in a day actually come from?
Every single one started with a person using the real product and hitting something.
I opened the app at breakfast and wanted it to greet me by name, so we built profiles and greetings. I uploaded a photo of myself and it failed, which turned out to be nothing to do with the app: the web server in front of it refuses anything over a megabyte by default, and a phone photo is several. You only meet that layer through real use; no amount of testing on my own machine would ever have found it, because on my own machine that layer does not exist. I deleted a test client and landed on an error page. I looked at the client's side of the app and realised it was a second-class citizen, so it got a proper home screen. Anyone who has ever done up a house knows the pattern: you do not find out what is wrong with a room until you live in it.
The last feature of the day was the one I am fondest of. The workout player walks a client through their session one card at a time: the exercise, her video, her coaching cues, a big Done button, and a timer that quietly pre-fills itself when the prescription says "30 secs". The part I care about is the Skip button. Skipping an exercise writes nothing to the database. Not "skipped", nothing. The app cannot guilt anyone about a missed session, because there is nowhere in it for a missed session to exist. That is a product principle expressed as a database schema, and it came directly from the trainer herself: her clients are real people with real lives, and an app that scolds them is an app they will delete.
What changed when she got the keys?
At four o'clock yesterday I sent her the login. Not a demo, not a screen recording: her own coach account, on her own practice, with a set-your-own-password flow so no password ever travelled in a message.
I have built and shipped plenty of things that were done in every technical sense: deployed, tested, monitored. But none of it felt real until this morning, when she signed in on her own and said it looked great. And to be clear, this is an early version one with a long list still to build, so finished would be the wrong word entirely. What happened is something I have decided I care about more: it started. Software starts when a real person is using it without you in the room, and everything before that moment, however polished, is preparation.
Tomorrow she builds her first real programme in it, for her first real client, and I fully expect her to trip over things I cannot see. That is not a risk to the plan. That is the plan. Her fumbles are the specification for whatever I build next week.
What did the day teach?
Three things worth writing down.
First, the layers you did not build have opinions about your product, and they only voice them in production, under real use, from a real phone. Budget for that.
Second, an hour of design discipline buys you features later. Dark mode took one hour, because a design pass two days earlier had put every colour behind a named token. The token work felt slow at the time. It was the fast option.
Third, the line that matters is not where I kept putting it. It is not the deploy, the test pass, or the write-up. It is another person's hands on the thing, unsupervised. Aim there and the last ten per cent stops being a chore and becomes the point.
What is next
She builds, I watch what she trips on, and the next stretch of work writes itself from her real use. There is also a messaging feature she asked for early on, so her clients can ask her questions about their exercises without leaving the app; I am deliberately waiting to design it with her rather than guess. More here as it happens.