Building GymBuddy Exposed the Checklist I Was Missing

On 24 August 2026, I created GymBuddy. It became the fourth tool uploaded to the Edge Life website. The app was intended to address a problem I understood, but the process of building it revealed a different problem: I did not yet have a repeatable system for turning an idea into a finished, integrated app.

I have decided to build 100 online tools. Each one should be simple, do one thing effectively, remain open for anyone to use, and avoid demanding a user’s attention after it has done its job. I also want to use AI to make tools that add practical convenience and give people more control.

That plan makes the process important. If every tool is built through a different sequence of improvised decisions, I may finish individual apps without getting better at building them.

GymBuddy made that gap difficult to ignore.

Why did I build GymBuddy?#

I built GymBuddy because learning how to use gym machines had been harder than it needed to be. I tend to learn by reading rather than listening—a distinction Peter Drucker wrote about—and I wanted a guide I could return to instead of needing to ask someone each time.

The initial need was straightforward: help someone choose what they want to train, understand the relevant equipment, and see how an exercise is performed.

That sounds like a small product. It still contained enough decisions to expose weaknesses in my process.

How did the idea become an app?#

The idea moved through several forms before I started development. I began with pen and paper, then used a Claude skill called idea-grill, derived from Matt Pocock’s grill-me skill, to question the idea.

The back-and-forth changed it. Instead of treating the first concept as the specification, I used the questions to make the idea more focused on the actual problem.

I then wrote a product brief in Markdown. I used the MECE framework—organising the requirements so they were mutually exclusive and collectively exhaustive—along with the workflow I wanted a user to follow. Finally, I gave that brief and Edge-UX-Philosophy.md to Claude Code to create the web app.

The sequence was useful:

Start with the rough idea.
Challenge the idea.
Define the problem and workflow.
Turn both into a written brief.
Build against the brief and the product’s UX principles.

But a good input sequence did not make the first output finished.

What changed after the first version?#

The first version showed where the written brief, the generated implementation, and the experience I wanted did not yet match.

I changed the muscle-selection flow so it could show muscle groups commonly trained together, such as back with biceps for pulling movements and chest with triceps for pushing movements. Choosing one body part in isolation did not reflect the way I wanted the guide to support a workout.

I also made several changes to the interface and content:

Replaced the initial weight and machine icons with a more suitable set.
Kept the video inside the website instead of sending the user to another app.
Removed the “by Edge Life” label from the top of the app.
Revisited parts of the interface that felt wrong even before I could describe the precise cause.
Changed the video-sourcing rules from videos up to 90 seconds to videos up to 45 seconds.
Added sourcing criteria of more than one million views, more than 100,000 channel subscribers, and English as the video language.
Removed the illustrations generated in the first version because they were structurally incorrect.

Some of these were presentation decisions. Others affected the usefulness or accuracy of the product. The illustrations were a clear reminder that generated assets cannot be accepted simply because they look complete.

The video change exposed another design principle. Sending someone elsewhere may be easy to implement, but it introduces a handoff. If the task can be completed inside the tool, the user should not have to leave it without a good reason.

What did the fourth tool expose?#

The fourth tool exposed how much of app building happens outside the act of generating code. The idea needs to be tested, the workflow needs to be written, the first version needs to be reviewed, the app needs to be uploaded, and the result needs to fit into the rest of the website.

Until GymBuddy, those activities were steps I performed. They were not yet a system I could inspect and improve.

That distinction matters if I intend to build 100 tools. Documentation gives me a record of what I tried, what changed, and why. A checklist gives the next build a starting point.

Neither guarantees a good product. They make it easier to see whether I am repeating an avoidable mistake.

What should the app-building checklist include?#

The checklist should cover the complete path from an untested idea to an app that is live, connected to the website, and ready for another round of review. This is the first version of that checklist.

1. Idea generation#

Write the problem in one sentence before describing the solution.
Identify the single job the tool should do effectively.
Define who encounters the problem and in what situation.
Test whether the tool fits the Edge Life principles: simple, open, useful, and complete without demanding ongoing attention.
Challenge the idea with structured questions instead of protecting the first version of it.
Record the assumptions that still lack evidence.
Decide what the tool will deliberately not do.

2. Development#

Map the user’s desired workflow from arrival to completed task.
Write a product brief with requirements, exclusions, content rules, and important interface states.
Organise overlapping requirements before development begins.
Include the relevant Edge UX principles with the brief.
Define external content or data-sourcing rules explicitly.
Build the smallest version that can complete the intended task.
Review generated text, visuals, icons, and interactions for accuracy instead of treating them as finished by default.
Check that the implementation still solves the problem stated at the beginning.

3. App upload#

Confirm the app name, URL, page title, and description.
Test the production build rather than relying only on the development version.
Check the main workflow on both narrow and wide screens.
Verify that navigation, links, embedded media, and error states work after upload.
Confirm that the app is publicly accessible and does not ask for unnecessary information.
Record the upload date and the state of the first published version.

4. App integration#

Add the app to the correct place on the main website.
Make sure the route into the app and the route back are clear.
Remove generated labels, attribution, or interface elements that do not belong in the final experience.
Check that typography, icons, spacing, and language feel consistent with Edge Life.
Keep the user inside the tool when an external handoff adds friction without adding value.
Verify that the app works as part of the website, not only as a standalone page.

5. Iteration#

Use the published app from the beginning without skipping familiar steps.
Write down friction even when the first observation is only that something feels wrong.
Separate accuracy and task-completion problems from visual preferences.
Fix misleading or structurally incorrect content before polishing the interface.
Record each material change and the reason for making it.
Recheck earlier steps when an iteration changes the workflow or product scope.
Keep unresolved questions visible instead of rewriting the build as a finished success.

What did I learn?#

I learned that my method needs to be treated as part of the product work. AI can help question an idea, structure a brief, and create an implementation, but it does not remove the need to inspect the result or make product decisions.

GymBuddy also showed that iteration begins before there is clean evidence or a perfectly worded diagnosis. “Something about the UI is wrong” is not a useful final specification, but it is a valid prompt to look more closely. The next step is to identify the friction, change one thing for a reason, and document what happened.

This checklist is not proven yet. It is a version-one system created from the gaps that became visible while building the fourth tool.

The next tools will test whether it helps—and where the checklist itself needs to change.