Structuring workouts for repeat use instead of one-time browsing
Argilzar Workouts did not start as a product concept. It started as repeated use, and that usage made the shape of the app obvious.
Before there was a dedicated app, workouts were already being logged through Usable chat. That workflow was good enough to keep using and awkward enough to expose its own limits. That combination is usually where a real product starts.
The important part was not just that Usable chat could summarize a session. It created a durable record of actual workouts. Those logs showed where people skipped movements, where substitutions happened, how planned and performed exercises diverged, and what a useful session summary looked like after the work was done.
That changed the PRD process. Instead of inventing requirements from a blank page, I could build from the Workout Tracker Expert fragment and from the logged sessions themselves. Features like skip flows, substitutions, preserving planned versus performed names, and superset-aware execution were not speculative. They were repeated needs visible in the history.
The same history also made the deployment choice straightforward. Once the real workflow was visible, the honest answer was that the MVP did not need a backend runtime to be useful. IndexedDB through Dexie covered the core experience, which made it reasonable to ship the app as a static frontend with S3, CloudFront, ACM, and GitHub Actions using OIDC.
That is the part of the project I keep coming back to. Argilzar Workouts was not created by brainstorming in a vacuum. It came from observing repeated use, turning those sessions into product memory, and then building the smallest system that respected what the history was already saying.
For me, that is a better pattern than starting with a grand product story. Use the workflow first. Let the evidence pile up. Then build the tool that removes the friction without losing what made the original flow valuable.