A cross platform fitness app that combines AI powered nutrition logging, real time exercise form checking, personalised training plans, social accountability, and gamification — built from a single Expo codebase.
The results
From feature collection to product loop
Ironclad started from a simple product observation: fitness is not a single action. Training, nutrition, progress tracking, motivation, and accountability influence one another. Instead of building another isolated workout tracker, I designed a product where these behaviors reinforce the same journey. The result is a cross-platform fitness app built from a single Expo/React Native + TypeScript codebase for iOS, Android, and Web. Firebase provides the application backend, while AI and computer vision are used selectively for high-friction interactions such as food analysis, training-plan generation, achievement recognition, and exercise-form feedback.
The product is intentionally presented as a shipped build rather than a concept: the repository contains the cross-platform application, Firebase configuration, AI workflows, form-checking logic, training plans, social features, achievements, and deployment setup.
The problem: fitness has too many disconnected actions
A user trying to get fitter has to make repeated decisions: What should I eat? What should I train? Am I doing the movement correctly? Am I progressing? Is today's effort actually moving me toward the goal? Many products answer one of these questions well, but the experience can still feel fragmented. My product hypothesis was that a stronger experience would connect the answers into one feedback loop rather than treating each feature as a separate destination
Product hypothesis
f the app can make the next useful action obvious, reduce the friction of logging it, and make progress visible, then the product has a stronger foundation for repeat usage
Designing the core loop
The product is organized around a simple loop: set a goal → train and log → receive feedback → see progress → return. The home experience acts as a decision layer, bringing together calorie progress, training, XP, consistency, and social activity instead of making the user hunt through separate modules
Activation starts with personalization
Onboarding establishes a baseline using BMI, TDEE, and a calorie budget. That information is not treated as a static profile field; it becomes the foundation for the actions surfaced throughout the product
Retention is built into the experience
XP, ranks, achievements, consistency analytics, gym-bro interactions, weekly soundtrack pins, and visible progress give the user multiple forms of feedback. The intention was not to add gamification for decoration, but to make effort legible and create reasons to return.
The product decision I kept returning to: every feature should strengthen the loop or reduce friction inside it
AI where it actually helps
I did not treat AI as a universal solution. I used it where the user has a high-friction input or where generating a useful starting point is valuable, while keeping deterministic logic for areas where predictability matters.
Real-time form checking uses a different approach
For exercise form feedback, the web experience uses MediaPipe pose landmarks plus exercise-specific rules rather than sending every movement to a generative model. This makes the feedback path faster and keeps the underlying evaluation logic inspectable. That separation was an important architecture choice: *generative AI for ambiguous/high-friction inputs; deterministic logic for repeatable fitness rules.*
One product, three platforms
A major constraint was deliberate: one Expo codebase only. I avoided separate native and web applications so product changes could be implemented once and carried across iOS, Android, and Web
Shipping constraints
The repository includes local development, typechecking, Firebase rules/index deployment, web export and Vercel hosting configuration, plus EAS build profiles for Android/iOS. For a larger public launch, the project documentation also calls out moving Groq/Gemini credentials behind a server-side proxy rather than exposing them to the client.
What I owned
I owned the product concept, feature prioritization, UX flows, technical architecture, AI integration, and implementation. The most valuable part of the project was not any single screen; it was deciding how the product should behave as a system. I had to make trade offs continuously: where AI added leverage, where rules were safer, which features contributed to retention, how to preserve a coherent experience across three platforms, and how to keep V2 from becoming an uncontrolled feature expansion.
What I learned
• A feature is only useful when it strengthens a user journey. • AI is most valuable when it removes friction, not when it replaces product logic. • Cross-platform architecture is a product decision as much as an engineering decision. • Retention should be designed as a feedback system and then measured, not assumed. • Shipping a coherent V2 is more valuable than continuously adding disconnected features.
What I would build next
the next iteration would focus on proving the loop rather than expanding the feature set. I would instrument onboarding completion, first-workout completion, nutrition logging, weekly retention, and engagement with social features to identify where users lose momentum. The product would then be simplified around the weakest point in that journey. On the engineering side, I would harden the production AI boundary and continue improving the native computer-vision pipeline.
“The goal wasn't to build another collection of fitness features. It was to build a loop that makes the next action obvious.”