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 workou...
For further actions, you may consider blocking this person and/or reporting abuse
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.
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.