AI-assisted product work often looks almost magical in LinkedIn posts and Instagram reels: describe an idea, press Enter, and a product appears.
My experience with GymBuddy was very different.
GymBuddy started as a fitness app idea. I was tired of logging workouts, then manually feeding them into ChatGPT with extra context — movement patterns, weekly fatigue budget, and so on — just to plan the next week’s training.
Quickly it became clear that “a fitness app” is not a product specification. It is a vague container for hundreds of decisions. What should the user do first? Should they build workouts manually or receive a generated plan? How many active programs should exist? What happens when a workout is missed? What is history? What is adaptation? What can be changed by the user, and what must stay stable? What we intorduce as MVP?
AI helped me move faster, but it did not remove the work. In many places, it made the work more visible.
At the beginning, the hardest part was not code. The hardest part was turning a general product idea into a stable MVP boundary. GymBuddy became an Android-first app that helps a user complete onboarding, receive a recommended training structure, generate one active program, anchor it to real calendar dates, execute workouts, confirm actual performance, review history, and rebuild or renew the program explicitly when needed.
That sounds simple only after it has been written down.
For instance, we planned to have 40 exercises for the MVP. Later, when the “replace exercise” option was added, I found the leg press had no replacement — and hack squats were not in the list at all… How did that happen? But some rough edges can came up during implementation and testing — the hack squat issue is a good example.
It was not a real gap, just an MVP scope decision. These things happen.
Anyway, a lot of time went into decisions that users may never notice directly, but that define whether the product feels trustworthy. For example, we had to separate the recommended plan from actual execution. If the app recommends one exercise, but the user replaces it during the workout, the original plan should not be silently rewritten. The actual workout should be stored as actual data. History should stay history. Future adaptation should use evidence, not erase the past.
Another thing that took more time than expected was documentation. The package included:
- Product Scope / PRD
- MVP Decision Log
- User Flow and Edge Cases
- Screen Specification Matrix
- First Program Generation Rules
- Weekly Adaptation Rules
- Canonical ERD and Table Contracts
- Field-Level Minimal Contracts
- Enum Glossary
- Seed Data Workbook structure
- Technical Handoff
- Design System Specification
- UI Component Library
- Visual Reference Pack
- Master UI Generation Prompt
We created product scope, user flows, screen specifications, data contracts, enum rules, seed-data rules, technical handoff, visual references, and UI component rules. At some moments, it felt like we were preparing too much before building. But later, when we moved into implementation with Cursor and Android Studio, the value became obvious. Without those documents, AI would constantly invent. It would rename things, redesign screens, simplify edge cases, or solve the wrong problem very confidently.
The documentation became a way to control AI.
The most challenging part was keeping the whole system coherent. Fior instance, program generation depends on schedule, goal, experience, templates, day types, slots, exercise data, load profiles, fatigue budget, and adaptation rules. One small product decision can affect screens, database tables, seed data, technical flow, and UI prompts.
This is where AI was useful as a thinking partner. It could help compare options, find contradictions, write clearer rules, and turn decisions into implementation prompts. But it also needed strong steering. If I asked a vague question, I often received a vague answer. If I gave it a narrow slice, clear constraints, and acceptance criteria, the output became much better.
One unexpected challenge was workout generation quality. The first generated training days could be technically valid but not good enough as a product experience. Some days were too short. Some looked too similar. That forced us to define what “good enough” means: enough exercises, meaningful differences between day types, stable blocks instead of random weekly reshuffling, and clear rules for when the generator should fail versus when it should warn and continue.
AI-assisted work also changed how I think about development. I stopped seeing AI as a magic builder and started treating it more like a fast but unstable team member. It can produce a lot, but it needs context, priorities, constraints, and review. It can help me write prompts for Cursor, but I still need to test in the emulator, check Git status, review what files changed, commit small slices, and decide what comes next.
The implementation is not completed yet. I believe to finish my work in 2-2.5 weeks.
The workflow that works best is simple: we define a small slice, my team-mate writes a precise prompt for Cursor, Cursor implements only that slice, I test and commit, then we move on. When we work in small packages, progress becomes safer.
So, what was challenging?
Not “using AI.” The challenge was managing AI-assisted complexity.
What took more time than expected?
Documentation, edge cases, data modeling, generator rules, and keeping visual/UI consistency across many screens.
What did AI make easier?
It helped me think through decisions faster, produce structured documents, create prompts, review contradictions, and keep momentum when the amount of detail became overwhelming.
What did AI not replace?
Product ownership.
AI can suggest. AI can draft. AI can implement through tools. But someone still has to decide what the product is, what it is not, what quality means, and when a result is acceptable.
For me, GymBuddy became not only an app project, but also a practical lesson in AI-assisted product work. The biggest value was not speed alone. The biggest value was having a thinking partner that helped me turn uncertainty into structure.
But the structure still had to be mine.
Leave a Reply