Hustl

Inspiration

I’ve been skinny for most of my life. I tried apps like Strong to track my workouts and MacroFactor to manage my nutrition. Both were useful, but each understood only one part of what I was trying to achieve.

I still relied on ChatGPT or Claude for advice. That meant repeatedly explaining my training history, diet, recovery, and goals, then manually carrying their suggestions back into each app.

I built Hustl because I wanted those pieces to work together. The same problem exists whether someone wants to gain muscle, improve performance, or lose weight without sacrificing strength: good coaching needs the full picture.

What it does

Hustl connects training, recovery, nutrition, progress, and AI coaching in one app.

It also brings in health and activity data from outside Hustl through Apple Health and Health Connect on Android, including data shared by compatible apps such as Google Fit. This gives the coach a broader view of the athlete’s workouts, sleep, heart rate, recovery, and daily activity.

An AI assistant can understand what the athlete has trained, how their exercises are progressing, whether they have recovered, what they have eaten, and what their current goals are. It can then help with practical tasks such as:

• reviewing workout and exercise history;
• interpreting readiness, sleep, HRV, and resting heart rate;
• comparing food intake with calorie and macro targets;
• logging or correcting meals;
• proposing nutrition targets;
• building and revising workout templates;
• adapting a workout when recovery is poor; and
• showing proposed changes inside the Coach inbox.

Hustl supports both MCP and WebMCP. MCP lets compatible assistants work with Hustl directly. WebMCP gives an assistant tools related to the Hustl screen currently open in the browser.

The important part is the collaboration. The assistant studies the evidence and explains its recommendation. Hustl turns that recommendation into a concrete proposal. The athlete reviews, refines, accepts, or rejects it.

How I built it

Hustl is a Flutter application backed by a TypeScript and Next.js API, Supabase and PostgreSQL, native Apple Health and Android Health Connect integrations, and an MCP server.

For WebMCP, I built a coordinator that registers tools according to the visible route. Train exposes training and progression tools. Recover exposes readiness data. Nutrition exposes the food diary and nutrition proposals. Coach exposes trends and pending changes. Templates and active workouts expose their own focused capabilities.

When the user changes screens, the old tool handles become stale. This prevents an assistant from retaining a capability simply because the user visited that page earlier.

Actions use strict schemas and explicit outcomes. Coaching changes normally become pending proposals rather than being applied silently. They appear in Hustl’s regular Coach interface, where the athlete can inspect the rationale and proposed values.

For the challenge, I also created a public evaluator using Hustl’s real Flutter interface and WebMCP coordinator. Private services were replaced with deterministic, in-memory data. It contains no production credentials, personal health records, analytics, or backend connection. Its runtime also blocks unexpected network and browser-credential access.

Challenges I ran into

The first challenge was resisting the temptation to build a small, isolated demo. Hustl is meant to support the whole coaching loop, so the WebMCP experience needed to work across the real training, recovery, nutrition, Coach, template, and workout screens.

Navigation was harder than it appeared. The visible screen, browser URL, and registered tool catalogue all needed to agree. I found cases where a detail screen opened without correctly taking ownership of its route. I also had to ensure that tools disappeared and old handles failed safely after navigation, reloads, and account transitions.

Proposal state required similar care. A successful request might be pending, applied, duplicated, dismissed, reverted, or rejected by validation. Those outcomes needed to remain distinct in both the tool response and the interface.

Finally, I needed to make the source inspectable without publishing Hustl’s private backend or user data. The public evaluator therefore uses synthetic fixtures, explicit no-op integrations, source manifests, and checks for private paths, credentials, and unexpected network origins.

Accomplishments that I’m proud of

The public evaluator exposes 20 route-scoped WebMCP tools across training, recovery, nutrition, coaching, templates, and active workouts.

Those tools support a complete coaching story. An athlete can describe a goal, let the assistant study twelve weeks of training and exercise progression, account for a poor recovery day, compare nutrition with current targets, and receive concrete changes for review.

I am especially proud that the safety model is visible in the product:

• tools follow the screen the athlete is using;
• stale handles fail closed;
• proposal status is explicit;
• duplicate requests do not create duplicate changes;
• workout and nutrition-target proposals require human review; and
• the public evaluator cannot access production systems or personal data.

This is not a separate interface made for the challenge. It is a safe, deterministic version of Hustl’s real Flutter experience and coaching architecture.

What I learned

More autonomy does not automatically make an AI coach more useful. Better context and a clear review process matter more.

I also learned that the interface can act as a meaningful permission boundary. Route-scoped tools make the assistant’s access easier to understand because its capabilities follow what the athlete can currently see and do.

Most importantly, AI collaboration works better when the result becomes part of the product’s normal workflow. A recommendation should not disappear inside a chat transcript. It should become something the athlete can inspect, refine, follow, and revisit.

What’s next for Hustl

The next step is to make the collaboration continuous rather than limited to a single planning session. I want Hustl to support richer long-term recovery analysis, clearer progression explanations, and weekly coaching check-ins that compare the plan with what actually happened.

I also want the same experience to work consistently across web, desktop, and mobile assistants through MCP and WebMCP.

The principle will remain the same: Hustl provides the evidence, AI helps interpret and propose, and the athlete controls what changes.

Built With

• apple
• connect
• context
• dart
• firebase
• flutter
• health
• healthkit
• javascript
• model
• next.js
• postgresql
• protocol
• supabase
• typescript
• vercel
• watch
• webmcp