Every workout tracker I've tried has the same limitation: it records what you did, but it doesn't tell you what's going wrong.
You finish a workout, log your sets, reps, and weight, then the app stores the data and that's about it. If you've stopped progressing, consistently training too close to failure, or need a deload, you're left to figure that out yourself.
That's what led me to build WhyRep.
It's a workout tracker with a built-in coach that analyzes your training and explains what's holding you back. The key difference is that every coaching decision has to trace back to a methodology I wrote and approved beforehand, never something an LLM made up on the spot.
For context, I've spent the last three years studying exercise science with a focus on muscle hypertrophy. Rather than asking an AI to invent programming, I write and validate the coaching methodology first, then use AI to explain those decisions in a conversational way.
How the "AI coach" actually works (probably not what you'd guess)
I'm not fine-tuning a model on hypertrophy data and hoping it generalizes. The pipeline is closer to this:
I write the methodology myself first, leaning on my physiology background. Progression rules, deload and autoregulation logic, plateau diagnosis, and everything else starts as a document that I draft and sign off on, complete with concrete test vectors (specific input → specific expected output), before a single line of coaching code gets written.
Deterministic engines implement those docs.
ProgressionEngine,AutoregulationEngine,PlateauEngine, and others implement the methodology and are tested against the test vectors, not against "does this feel right?"The LLM (Claude) only operates inside that fence. It handles the conversational layer by answering your questions, explaining decisions in plain language, and helping you modify your program. It's constrained to the approved methodology, not free to invent new training science mid-conversation.
I've spent a huge amount of time refining this interaction. The goal isn't just to answer basic questions. It's to have the kinds of nuanced coaching conversations you'd expect from a knowledgeable human coach, while keeping every recommendation grounded in the documented methodology.
For example, if you tell the coach, "I want to bring up my arms," it can recommend concrete changes such as prioritizing arms earlier in your workouts, adjusting weekly volume and frequency, and then update your program if you approve the changes.
It also goes beyond the advice most people already know. Many lifters don't realize that if the brachialis is a weak point, it can be trained more effectively by using curl variations that place the shoulder into flexion to emphasize it separately from the biceps. The coach can recognize situations like that, explain the reasoning, and incorporate those changes into your program. Again, none of that is invented on the spot. Every recommendation has to trace back to the underlying methodology that I wrote and approved.
This is also why I'm comfortable letting people challenge the coach. If it recommends something, I should be able to point to the methodology that produced that recommendation and explain the physiology behind it. If I can't justify it scientifically, it doesn't belong in the product. I'd rather spend another week improving the methodology than ship a feature that sounds convincing but isn't something I'd stand behind as a coach.
What's actually shipped so far
This isn't a mockup. Here's what's built and running on a physical device right now:
- Full workout tracker: sets, reps, RIR logging
- Progression detection engine — methodology doc + engine + test vectors, all committed
- Autoregulation/deload engine and plateau diagnosis engine, same doc-first process
- Pro-gated analyzer: plain red/yellow flags for free users, full solution panels (limited to fixes that trace back to a doc) for paid
- Session history with month-sections, severity badges, and an "Analyze" vs "Perform Again" split
- Exercise library (~110 exercises with a lot more to come) with real photos and generated mannequin art + detail pages
- Dark mode (now the default) across the app and the landing site
- One shared Kotlin Multiplatform core — the same engine code compiles for both Android (Compose) and iOS (SwiftUI). No forked logic between platforms.
- Backend coach chat running through Claude (Haiku 4.5), with the methodology docs cached into context
- Auth + payments wired to native store billing, not a third-party processor, so both app stores are happy
Though I'd argue that the methodology is the product. I've probably spent more time writing, validating, and refining the methodology documents than writing the AI itself. Every progression rule, plateau diagnosis, autoregulation decision, and program modification starts life as a piece of methodology that I draft, challenge, revise, and test before it ever reaches the coach.
The methodology goes far deeper than "add two sets to chest." Every exercise in the library has documented fractional set contributions for every relevant muscle group. For example, a lat pulldown doesn't just count as one lat set. It also contributes fractional volume to muscles like the biceps. When the coach decides whether to increase, decrease, or maintain your weekly volume, those indirect contributions are already accounted for in the calculations instead of pretending every muscle only receives stimulus from isolation exercises.
That's the biggest difference between WhyRep and most AI fitness apps. I'm not asking an LLM to become a coach. I'm trying to encode an evidence-based coaching methodology into software, then using the LLM as the interface that makes it feel natural to interact with. The AI isn't the source of truth. The methodology is.
Where I'm at on marketing
Top-of-funnel right now: educational, no-fluff gym content on TikTok and Instagram, slowly building an audience. If any of you are into training/hypertrophy content, I'd genuinely appreciate a follow — and if you have thoughts on what's working or not for build-in-public creators in this niche, I want to hear it:
- TikTok: https://www.tiktok.com/@whyrep.ai
- Instagram: https://www.instagram.com/whyrepai/
- Landing page: https://whyrep.com/
What I could use advice on
This is as much a "help me think" post as a "look what I built" post. Specifically I'd love input on:
- Anyone else building an audience alongside a technical product — what actually moved the needle for you early on?
- If you've built something where correctness/trust is the whole pitch (not just features), how did you communicate that without sounding preachy or over-explaining?
Will keep posting weekly as this moves forward. Thanks for reading this far, I'll probably show the demo next week!
Top comments (16)
I like the methodology-first approach. Using AI to explain decisions instead of making them feels like a much more reliable way to build something people can actually trust.
Also, if you're building with AI, there are some other useful tools in this collection that might be worth checking out: 630+ Best AI Websites.
Thank you so much.
lovely
i see da vision
Using a deterministic engine for the actual science and the LLM just for translation is brilliant. Fractional volume tracking is exactly what generic apps miss.
The real challenge in fitness apps isn't data collection, but structuring the relational data between exercises, sets, and progressive overload metrics so an AI model can actually query it effectively. I have seen too many apps fail here because they just dump JSON blobs into a database without thinking about the temporal relationships. I ran into a similar data-modeling hurdle when structuring the Supabase schemas for PubliFlow, where we had to map out complex relational dependencies for user analytics. How are you planning to structure your database to handle those longitudinal progression queries for your AI layer?
The AI never reads the database directly. A deterministic progression engine analyzes normalized workout logs, recomputes verdicts (plateau/progression) from raw data on every read, and passes only those traceable verdicts to the LLM. This keeps coaching explainable, consistent across Android/iOS, and prevents the model from making progression decisions itself.
Drawing a hard line between the deterministic progression engine and the LLM is a smart way to mitigate hallucination risks in coaching. Forcing the model to only reason over pre-computed, traceable verdicts keeps the actual fitness logic strictly controlled while letting the AI handle the conversational delivery. I am curious how this architecture handles edge cases when users introduce entirely new exercise variations that the deterministic engine has not yet been explicitly programmed to evaluate.
Yeah goal is to have a huge exercise library that would cover all needs but if theres smth which isnt covered, then the user will have to choose what muscle group it primarily targets because thats the main metric were using for our calculations. There'll be an advanced option in which they can set fractional volume aswell.
Relying on the primary muscle group as a fallback metric is a smart way to keep the progression engine deterministic when the system encounters an unknown exercise. The fractional volume setting in advanced mode will definitely appeal to users who need precise periodization. How are you handling compound movements that heavily tax multiple muscle groups equally when forcing a single primary target?
Every exercise even if its compound has a prime mover. For example in RDLs the primary movers are glutes, even though hamstrings and lowerback are also heavily involved. There is really no other way to go about it than letting the user just pick the primary mover for example glutes here, and if they're knowledgeable enough they would add fractional volume themselves using the advanced option for hamstrings and lowerback aswell. If its about me handling compound movements myself, then yeah i set the fractional volume myself based on general data. Im aware that the involvement of a specific muscle in compound varies from person to person based on their personal anatomy and biomechanics, but generally the prime movers and the involvement of OTHER muscle groups are there for everyone. So ill be manually checking each exercise, go through the data and set the fractional volume myself. For example for a lat pulldown i would set 1 for lats and 0.5 for biceps. Generally this is fine in the bigger picture.
That RDL example perfectly illustrates why defaulting to the prime mover keeps the core logging experience frictionless. Pushing fractional volume tracking for secondary muscles into an advanced option is a solid compromise, catering to data-driven lifters without cluttering the main UI. How are you planning to design that advanced fractional input so it feels intuitive rather than like a spreadsheet?
Moving from simple CRUD logging to predictive or AI-driven coaching requires a massive shift in how you structure your database schema. Instead of just storing sets and reps, you need to think about time-series data and vector embeddings for contextual workout history. Have you considered how you will handle the latency of real-time AI inference during an active workout session, especially when users might be in areas with poor connectivity? Implementing an offline-first architecture with local SQLite or WatermelonDB could be critical before syncing to your backend for heavy processing.
Some comments may only be visible to logged-in visitors. Sign in to view all comments.