Demo guide · AI coding & owned software
Turn a Workout App Prototype into a Testable First Build
Use the workout-app demo to scope one complete flow: choose a workout, log a set, run a timer, save, and verify what survives reopening.
The September 11 Hyperflow Live demo walks through a workout prototype: open Train, choose an exercise, log a set, use a local timer, and finish and save. It also shows an unfinished layout. You can use that small flow to plan a first app and test it without assuming that an attractive demo proves the rest of the product works.
1. Write the smallest complete workout flow
Start with the path shown in the recording: choose a workout, open an exercise, begin, log a set, use the timer, then finish and save. Give each action an observable result. For example, logging a set should produce a visible entry the user can check.
For a practice build, leave program recommendations, subscriptions, social features, and other large additions outside the first pass. Those are possible later decisions; the demonstration does not establish them as working features.
2. Give your coding tool a concrete brief
Here is a suggested brief based on the demo. It is an exercise you can adapt, not the original prompt used to create the app:
Build a workout-tracking prototype with a Train screen, a workout detail screen, set logging, a rest timer, and a finish-and-save action. Use fictional example workouts. Show which sets have been logged, make the timer state visible, and provide a way to reopen a saved workout. Explain where saved data lives. Keep exercise advice and external integrations outside this first version.
Add your target device and any existing project constraints to the brief. Decide what should happen when someone leaves the workout halfway through, rather than letting the first implementation make that product decision silently.
3. Treat the timer and saved history as separate questions
The presenter describes the timer as running locally on the device, without syncing its ticks to an online database. That statement concerns the timer. It does not establish cross-device sync, offline support for the whole app, or durable storage for workout history.
For your version, decide whether a timer should continue, pause, or reset when the user leaves the screen. Separately decide where completed workouts are stored and when they should be available again. Tell the coding tool the expected behavior, then check it on the target device.
4. Test the flow beyond the happy path
The following checks extend the recording into a suggested test plan. They are not claims that the prototype has already passed them:
| Action | What to verify |
|---|---|
| Log a set | The correct exercise shows one new entry. |
| Tap the log action twice quickly | The resulting entries match the behavior you intended. |
| Leave and return to the timer | The timer follows your specified continue, pause, or reset rule. |
| Finish and save | The completed workout is identifiable in the app. |
| Reopen the saved workout | The recorded sets and completion state remain correct. |
| Close and reopen the app | Saved history survives if persistence is part of your brief. |
| Try a narrow screen and larger text | Controls and progress information remain readable. |
5. Use visible defects to choose the next edit
At the end of the demo, the presenter points out content cut off at the side. Turn that observation into a precise bug report: identify the screen, the clipped element, the device size, and what should remain visible. Fix it, then repeat the workout path to check that the layout change did not hide a control.
The presenter also identifies the exercise imagery as AI-generated. Treat it as prototype artwork. The demo does not validate exercise technique or establish that the images are suitable as instructional illustrations.
6. Decide what the prototype has proved
The recording shows a short interaction path and acknowledges unfinished UI. It is useful evidence that a concrete flow can be explored; it does not establish production readiness or a repeatable build-time promise.
After your rehearsal, keep a short list of what works, what fails, and what remains untested. Use that list to choose the next change. A first build becomes more useful when someone can repeat its main task and explain exactly what the app saved.