Marcus Allen's Space

Marcus Allen

•

Summary

CoachGPT is my personal fitness coaching system that connects Apple Health data to ChatGPT, allowing me to ask natural-language questions about their training, performance, and progress.

I designed CoachGPT to live entirely inside the ChatGPT UI, using a private backend only for secure data storage and retrieval. The goal was to explore whether a large language model could act as a holistic coach, combining:

personal health data (workouts, heart rate, energy, elevation)
training theory and physiology knowledge
contextual reasoning across time (baselines, trends, fatigue)

Stack

HTML & CSS

GitHub

Figma

GPT Actions

Supabase

Mobile API

Problem

Apple Health stores an abundance of health data. As someone who stays active, I frequently run, cycle, climb, play tennis, and track all of my workouts with an Apple watch. However, despite all this data, I still find myself asking questions.

Am I running fast enough?
Should I take a rest day?
Why did I feel so fatigued in my last run?

The metrics could tell me what happened, but not why.

At the same time, chatGPT and generic coaching apps relied on fixed rules and shallow personalisation, without any context of my recent training and health data.

What was missing was a system that could:

reason across my data, not population averages
adapt as new workouts arrived
explain changes in plain language
combine personal metrics with general training knowledge

Solution

I built a personal training coach that lives inside ChatGPT and answers questions about my training in natural language.

Workout data is collected automatically in the background, while ChatGPT acts as the reasoning layer — deciding which time windows to compare, how to interpret trends, and how to combine recent workouts with context.

Rather than surfacing raw metrics or static charts, the system focuses on translating training data into explanations I can actually reason about, such as whether today’s session fits with recent load, recovery, and patterns across different activities.

Goals

I set the following goals for an MVP:

ChatGPT must have access to all my workout data that is stored in HealthKit.

Automatic data syncs and updates.

A simple security layer to keep my health data safe.

ChatGPT should retrieve the relevant data, interpret it, and make suggestions from a broad set of prompts.

Architecture

I started my laying out an architecture of the GPT in Figma.

Starting the my apple watch as the data collection hardware, it automatically syncs workout data to my iPhone through Apple health.

Apple heath is infamously difficult with APIs and data exporting. The only way for continuous access to data stored in Apple health is through a mobile app which integrates with HealthKit — Apple's central repository for health data. To prevent scope creep, I found an export app, Health auto export application, which enables data exports automatically to a external sources, including HTTPS requests.

The backend is a free Supabase database with tables storing different types of workout data. I would create HTTPS endpoints in Supabase to read data exports from HealthKit, and upsert data into the tables.

For the front-end to access the data. I had to choose between a flexible MCP tool layer and a simpler GPT Actions setup. I opted for GPT Actions, which allow ChatGPT to make standard HTTPS requests directly to a read-only API built with Supabase Edge Functions. This kept the architecture lightweight and avoided additional infrastructure, but meant I had to carefully design each endpoint to return the right context for different types of questions.

Features

One calendar view with open slots across multiple providers and over 25+ court websites.
Quick and easy regional court filtering
Direct booking links → fewer clicks, faster reservations
Mobile-friendly layout for booking on the go

Process

Data access
The first priority was reliable access to Apple Health data. Apple Health has no public server-side API, so continuous access requires integration with a mobile app. Rather than building my own iOS app, I used a third-party export app that could automatically send HealthKit data via HTTPS. This avoided significant iOS complexity, at the cost of giving up fine-grained control over how and when data is exported.
I set up API calls from Health Auto Export to Supabase to trigger daily, and after every workout.

Apple health

Health auto export

if (path.endsWith("/summary/today")) {
    // Interpret “today” in UTC to match your ingest timestamps (+0000 in payload).
    const now = new Date();
    const start = new Date(Date.UTC(now.getUTCFullYear(), now.getUTCMonth(), now.getUTCDate(), 0, 0, 0));
    const end = new Date(Date.UTC(now.getUTCFullYear(), now.getUTCMonth(), now.getUTCDate() + 1, 0, 0, 0));

    const baselineDays = parseIntSafe(url.searchParams.get("baseline_days"), 28);
    const baselineStart = new Date(end.getTime() - baselineDays * 24 * 3600 * 1000);

    const { data: todayWorkouts, error: wErr } = await supabase
      .from("workouts")
      .select(

Separate ingestion from interpretation APIs
I split the backend into two responsibilities: one endpoint to ingest and normalise raw workout data, and another to expose read-only summaries for analysis. Although this separation required more logic in the Supabase edge function, it made it easier to reason about data correctness and allowed ChatGPT to consume only the relevant data.
Security layers were built into both APIs, using a simple shared-secret header authorization.

Designing an interpretation API
Instead of mirroring the database structure, I designed endpoints based on the kinds of questions I wanted to ask:
- “How’s my training today?”
- “What’s my recent baseline?”
- “Show me how my heart rate trended during this workout.”
I identified three types of data I would likely need and created endpoints for each of them:
- Summary of today's workout
- All workouts in a given time range
- Detailed time-series information (HR, Distance, etc.) of a particular workout
Together, these three endpoints can answer any contextual workout query, without having to retrieve all stored data every time.

ChatGPT as the interface and reasoning layer
GPT Actions were used to fetch structured data over HTTPS, while interpretation happened entirely in the conversation. This dramatically reduced build time and surface area, but required careful schema design so ChatGPT could infer which endpoint to call based on the user’s question.

Outcome

The primary goal of this project was to create a coaching experience that could put my training into context. I tested coachGPT on questions I would typically ask it.

When asked "How has my training been?”, the system pulls up a summary of recent workouts, compared against a rolling 28-day baseline. It then adds a layer of LLM interpretation or 'Coach's perspective', highlighting meaningful shifts in volume and intensity. Then it suggests next steps.

For a more complex question, I asked, “How was my long run, and why did I feel so good?” The system correctly identified the workout, recognised that details are required to answer the query, and retrieved the workout's time-series data.

It then examined pace, HR, recent training load and combined that data with general training principles to explain the likely reason for 'why I felt good'.

It also provided an in-depth analysis of my HR and speed to provide feedback on my pace.

This example demonstrates that coachGPT can identify the sentiment of my prompt, retrieve the appropriate health/workout data, and perform analysis on that data, before adding conversational reasoning and interpretation. This validates the decision to use ChatGPT as the primary interface rather than building a custom analytics dashboard.

Next steps

This MVP is in a functional state. However, if I had more time, I would expand and refine the product:There are several clear directions to evolve this system further.

The most immediate next step would be expanding the data model beyond workouts. Incorporating passive health metrics such as resting heart rate and sleep, will enable more accurate reasoning about readiness and fatigue.
I’d also add lightweight server-side metrics for concepts like training load or week-over-week volume to give the model stronger signals without over-constraining its reasoning.
If the system were to support more data sources or users, I would revisit the data access layer, introducing an MCP-style tool server to handle more complex query orchestration and integrations (e.g. wearables beyond Apple Watch).
Finally, I’d refine the interaction layer by teaching the assistant to ask better clarifying questions when intent is ambiguous (e.g. multiple workouts in a day).

You've reached the end

Find me

Instagram