The idea
Training, food logs, wearable measurements, and weekly plans often live in different applications. Form & Fuel is my personal project for seeing those parts of a routine together, with a local workspace rather than a mandatory cloud account.
The existing application is a health dashboard and planning tool. Cloud AI coaching is a possible future enhancement, not an implemented capability. Keeping that distinction visible matters when presenting the project as part of an AI-building portfolio.
The workflow
The dashboard separates Overview, Workouts, Nutrition, Health, Goals & Plan, Connections, Settings, and Build Status. Date and range controls support browsing history. Workout views expose training volume and muscle exposure; nutrition views compare recorded food with dated targets; planning supports structured sessions and revision history.
The screenshots were taken from a dedicated, in-memory synthetic demo. They show real components and interactions without using personal health records, connected accounts, or device credentials.
Behind the build
The frontend uses React and TypeScript with Vite. A local Express service coordinates requests and data operations. Personal mode uses encrypted SQLite storage outside the source checkout, with keys managed through macOS Keychain. Demo mode uses separate, synthetic in-memory records.
The integration code includes a read-only Hevy adapter and a Cronometer CSV preview/import workflow. An Android companion starter uses Health Connect for selected measurements. These integrations have different acceptance states and should not be described as uniformly complete.
Engineering decisions
Demo and personal modes are separate. This makes the interface shareable without publishing private measurements or asking viewers for an account. Screenshots in this case study come exclusively from demo mode.
Unknown values stay unknown. Import and measurement logic distinguishes absent fields from explicit values. This helps prevent incomplete data from looking like a real zero or a complete history.
Planning preserves history. Dated targets, structured sessions, and plan revisions make it possible to compare intended work with recorded work without rewriting past records. Matching ambiguity and missing source data remain visible rather than being treated as proof that a workout was skipped.
Local storage still needs recovery. Encrypted backup and restore code is part of the build; broader key-loss, migration, retention, and recovery acceptance remains a release requirement.
Current state and next steps
The source contains the working synthetic dashboard, editable goals/planning, import and sync code, encrypted storage, backup behavior, and an Android companion. The project documentation records a Hevy account sync and an Android debug build, while actual-source reconciliation and physical-device acceptance remain separate unfinished gates.
Next steps include deeper source-data reconciliation, phone permissions and transport verification, more reliable offline/backfill behavior, and broader accessibility and release checks. A future hosted version with login and per-user records would require its own architecture and security review.
The dashboard is presented as software for organizing recorded information. The synthetic numbers are interface examples, not personalized health recommendations.
