Project case study

Garmin Analysis Platform

A personal health and performance analytics platform using Garmin data, Spring Boot microservices, Python analysis services, and AI-generated insight summaries.

GarminSpring BootJavaPythonMicroservicesAIHealth DataData AnalysisRabbitMQProduct Management

Overview

The Garmin Analysis Platform is an entirely personal software project designed to analyse health, fitness, sleep, recovery, and training data from Garmin Connect.

The project was triggered partly by Garmin placing more advanced AI-style insight functionality behind a paywall. Rather than treating that as a blocker, I saw it as an opportunity to build my own analysis platform, using my own data, my own rules, and my own architecture.

The aim is not simply to display raw Garmin data. Garmin already does that well.

The aim is to build a system that can:

This project also gives me a practical way to deepen my experience with Java, Spring Boot, Python microservices, data pipelines, and AI-assisted analysis.

Project Context

This is entirely a personal project.

It is not a commercial product, client project, or employer-sponsored initiative. I am building it to explore Garmin data analysis, AI-assisted insight generation, Spring Boot microservices, Python analytics, and the wider question of how personal health data can be turned into useful decision support.

The idea was partly triggered by Garmin moving more advanced AI-style insight functionality behind a paywall. Rather than simply accepting that limitation, I wanted to explore whether I could build my own analysis platform using my own data, my own rules, and my own architecture.

The aim is to build a personal experimentation platform that allows me to understand the data more deeply, test different analytical approaches, and eventually generate tailored recommendations across training, recovery, body composition, and nutrition.

The Problem

Garmin provides a significant amount of data, including details around sleep, training load , and recovery.

The issue is that this information is often fragmented and not linked to decision support

A user may be able to see individual charts, but it is harder to answer questions such as:

The product opportunity is to turn health data into decision support.

Product Goal

The goal of the platform is to move from passive tracking to active interpretation.

Instead of simply showing numbers, the platform should help answer:

“What is my data telling me, and what should I do differently?”

This is especially useful for people who train across multiple domains, such as running and strength training as Garmin concentrates mostly on running or biking and does not accurately consider the effects of other training.

The system is intended to support evidence-led training decisions rather than generic fitness advice.

Current Scope

The current version is focused on the back-end architecture and data analysis pipeline.

At this stage, the platform does not have a polished user interface. The primary front end is API-driven, with Swagger used to test and inspect endpoints.

This is a deliberate product trade-off.

The early priority is to prove that the platform can:

A richer interface can come later once the core domain model and analysis logic are stable.

Conceptual Architecture

flowchart TD
    A[Garmin Connect] --> B[Python Garmin Data Collector]
    B --> C[Spring Boot API]
    C --> D[(Application Database)]
    D --> E[Python Analysis Service]
    E --> F[AI Summary Service]
    F --> G[Swagger API Response]
    F --> H[Future Email Report]
    F --> I[Future Web Dashboard]

    J[Future Weight Training App] --> C
    K[Future Food Tracking App] --> C

The core idea is to collect structured data from Garmin first, then progressively combine it with other personal training and nutrition data sources.

Core Capabilities

1. Garmin Data Collection

The system is designed to connect to Garmin Connect and retrieve health and training data.

The intended approach is to use the unofficial Garmin Connect Python library to extract data such as:

This allows the platform to work with real personal fitness data rather than manually entered figures.

2. Spring Boot API Layer

Spring Boot is used as the main application layer.

Its responsibilities include:

Spring Boot was chosen because it provides a strong enterprise-style architecture and is highly relevant to my wider software and product management experience.

3. Python Analysis Services

Python is used for the analytical parts of the platform.

This is a deliberate architectural decision.

Java and Spring Boot are well suited to API design, persistence, structure, and service orchestration. Python is better suited to data analysis, statistics, experimentation, and machine learning.

The long-term architecture separates these concerns:

LayerTechnologyPurpose
API and orchestrationSpring BootStable back-end services
Data extractionPythonGarmin Connect integration
AnalysisPythonStatistical and trend analysis
MessagingRabbitMQService communication
SummariesLLM / AI servicePlain-English insight generation
PersistenceDatabaseStructured health and activity history

This keeps the system flexible and avoids forcing all analysis logic into the Java service layer.

Data Flow

sequenceDiagram
    participant User
    participant API as Spring Boot API
    participant Collector as Python Garmin Collector
    participant DB as Database
    participant Analysis as Python Analysis Service
    participant AI as AI Summary Service

    User->>API: Request analysis for date range
    API->>DB: Check existing Garmin data

    alt Data missing
        API->>Collector: Request Garmin data collection
        Collector->>DB: Store Garmin health and activity data
    end

    API->>Analysis: Send structured date-range data
    Analysis->>Analysis: Calculate trends and comparisons
    Analysis->>AI: Send validated metrics
    AI->>API: Return plain-English summary
    API->>User: Return analysis response

This flow keeps the AI layer downstream of the data processing. The AI is not asked to guess from raw data. It receives calculated metrics and explains them.

Date Range Comparison

A key feature is the ability to compare one date range with the previous equivalent period.

For example:

This supports more useful trend analysis than looking at single-day values.

Example comparisons include:

MetricCurrent PeriodPrevious PeriodInterpretation
Average sleep score7872Improved recovery
Resting heart rate55 bpm58 bpmPositive trend
Average stress3138Lower stress load
Training volume6 sessions4 sessionsIncreased workload
Body battery average6759Better readiness

The aim is not to overreact to isolated data points, but to identify meaningful directional movement.

Comparison Logic

flowchart LR
    A[Selected Date Range] --> B[Current Period]
    A --> C[Previous Equivalent Period]

    B --> D[Calculate Current Metrics]
    C --> E[Calculate Previous Metrics]

    D --> F[Compare Changes]
    E --> F

    F --> G[Trend Detection]
    G --> H[Risk Indicators]
    G --> I[Positive Indicators]
    G --> J[Neutral Changes]

    H --> K[AI Summary]
    I --> K
    J --> K

The comparison model is deliberately simple at first. The immediate value comes from reliable period-on-period analysis before adding more advanced machine learning.

AI Insight Generation

The platform is intended to generate AI-assisted insight summaries from processed data.

The AI layer should not replace the statistical analysis. Instead, it should explain the findings in clear language.

For example, the analysis service may identify:

The AI service can then turn this into a readable summary:

Your recovery indicators have improved over this period. Sleep score increased, resting heart rate reduced, and average stress fell compared with the previous period. Training volume also increased, but recovery has remained stable, suggesting the increase is currently manageable.

The important product decision is that AI should interpret validated metrics, not invent conclusions from raw data.

AI Boundary

flowchart TD
    A[Raw Garmin Data] --> B[Validation]
    B --> C[Structured Metrics]
    C --> D[Trend Calculations]
    D --> E[Risk and Recovery Rules]
    E --> F[AI Explanation Layer]
    F --> G[Human-Readable Insight]

    A -. Not allowed .-> F

The AI layer should explain evidence. It should not be the first place where the data is interpreted.

Product Design Principles

1. Data First, AI Second

The system should not ask an AI model to guess based on unstructured data.

The data pipeline should first calculate reliable metrics, trends, and comparisons.

Only then should AI be used to explain the results.

This creates a safer and more useful system.

2. Explain the Trend, Not Just the Number

A single number is rarely useful on its own.

For example, a resting heart rate of 55 bpm may be good, bad, or neutral depending on the user, their baseline, recent illness, fatigue, training load, and sleep quality.

The platform should focus on:

3. Avoid Generic Fitness Advice

The platform should not simply produce vague advice such as:

“Get more sleep and train consistently.”

The goal is to produce specific, data-led observations, such as:

“Your sleep score improved by 8% compared with the previous 14-day period, but training volume increased by 30%. Recovery remains stable, so the current increase appears manageable, but the next period should be monitored for HRV or resting heart rate deterioration.”

4. Keep the Architecture Extensible

The platform is designed so that new analysis services can be added later.

Possible future services include:

This microservice-based approach allows the system to evolve without becoming a single monolithic analytics script.

Service Boundaries

flowchart TB
    subgraph JavaSpringBoot["Spring Boot Layer"]
        A[REST Controllers]
        B[DTO Validation]
        C[Domain Services]
        D[JPA Repositories]
    end

    subgraph PythonServices["Python Services"]
        E[Garmin Collector]
        F[Trend Analysis]
        G[Statistical Processing]
    end

    subgraph AIServices["AI Services"]
        H[Insight Generator]
        I[Recommendation Explainer]
    end

    subgraph Storage["Storage"]
        J[(Health Data)]
        K[(Activity Data)]
        L[(Analysis Results)]
    end

    A --> B
    B --> C
    C --> D
    D --> J
    D --> K
    D --> L

    C --> E
    C --> F
    F --> G
    G --> H
    H --> I
    I --> L

The service boundaries are designed to keep each part of the system focused. Spring Boot provides structure and orchestration, while Python handles the more analytical workloads.

Why Use Microservices?

For a personal project, microservices may appear excessive.

However, this project is partly intended as a learning platform.

The microservice approach allows me to practise:

The architecture also reflects a realistic enterprise pattern, where different services are responsible for different parts of a wider product capability.

Key Trade-Offs

Trade-Off 1: Swagger Before UI

The early version uses Swagger rather than a full user interface.

This is not because the UI is unimportant. It is because the analysis model needs to be proven first.

Advantages of this approach:

Once the analysis outputs are useful, a user interface can be designed around proven data rather than assumptions.

Trade-Off 2: Java and Python Instead of One Language

Using both Java and Python adds complexity.

However, it creates a cleaner separation of responsibilities.

Java is used for:

Python is used for:

This avoids using the wrong tool for the wrong job.

Trade-Off 3: Personal Data and Privacy

Health data is sensitive.

The platform is being designed with privacy in mind.

Important principles include:

This is particularly important if the system later becomes multi-user.

Trade-Off 4: Analysis Before Coaching

The first goal is analysis, not automated coaching.

Coaching recommendations are more complex because they can influence training behaviour and injury risk.

The platform should first become good at explaining what has happened.

Only after that should it suggest what to do next.

Example Analysis Output

A future analysis response may look like this:

{
  "period": {
    "startDate": "2026-05-01",
    "endDate": "2026-05-14"
  },
  "comparisonPeriod": {
    "startDate": "2026-04-17",
    "endDate": "2026-04-30"
  },
  "summary": {
    "sleepScoreChange": "+8%",
    "restingHeartRateChange": "-3 bpm",
    "trainingVolumeChange": "+22%",
    "stressChange": "-11%",
    "recoveryAssessment": "Improving"
  },
  "aiInsight": "Recovery markers improved during the current period. Sleep score increased, resting heart rate reduced, and average stress decreased. Training volume also increased, but recovery indicators remained stable, suggesting the current workload is manageable."
}

This is the type of output the platform is intended to produce: structured enough for software, but clear enough for a human.

Future Development

The future direction is to combine Garmin data with other personal health and training data sources.

The next major step is to bring in data from:

This would allow the platform to analyse the relationship between:

The long-term goal is to create AI-generated suggestions that are grounded in multiple data sources rather than a single fitness platform.

For example, the system could eventually identify patterns such as:

The AI layer would then be able to make more useful suggestions, such as:

The key principle is that suggestions should be based on connected evidence, not generic fitness advice.

Future Data Model

erDiagram
    USER ||--o{ GARMIN_DAILY_SUMMARY : owns
    USER ||--o{ GARMIN_ACTIVITY : owns
    USER ||--o{ WEIGHT_TRAINING_SESSION : owns
    USER ||--o{ FOOD_LOG : owns
    USER ||--o{ ANALYSIS_RESULT : receives

    GARMIN_DAILY_SUMMARY {
        date summaryDate
        int sleepScore
        int bodyBattery
        int stressScore
        float restingHeartRate
        float hrv
    }

    GARMIN_ACTIVITY {
        date activityDate
        string activityType
        int durationMinutes
        int calories
        float averageHeartRate
        float trainingLoad
    }

    WEIGHT_TRAINING_SESSION {
        date sessionDate
        string programme
        int totalSets
        float totalVolume
        string intensity
    }

    FOOD_LOG {
        date logDate
        int calories
        int proteinGrams
        int carbsGrams
        int fatGrams
    }

    ANALYSIS_RESULT {
        date startDate
        date endDate
        string recoveryStatus
        string trainingLoadStatus
        string nutritionStatus
        string aiSummary
    }

This future model would allow the system to connect training, recovery, nutrition, and body composition data into one analytical view.

Future Recommendation Flow

flowchart TD
    A[Garmin Recovery Data] --> D[Combined Analysis Engine]
    B[Weight Training Data] --> D
    C[Food Tracking Data] --> D

    D --> E[Detect Patterns]
    E --> F[Apply Rules and Thresholds]
    F --> G[Generate AI Explanation]
    G --> H[Personal Suggestion]

    H --> I[Training Adjustment]
    H --> J[Nutrition Observation]
    H --> K[Recovery Warning]
    H --> L[Progress Summary]

The value of the future platform comes from combining multiple data sources. Garmin can show recovery and activity data, but it does not fully understand weight training intent, nutrition context, or personal body composition goals.

Future User Interface

The intention is not to add a specific UI rather details will be sent via an email answering the following questions:-

The email should be organised around decisions, not just data categories.

Potential Future Features

AI Fitness Coach

A later version could use the analysis data to suggest training adjustments.

For example:

This would require careful design because training advice needs to be safe, explainable, and personalised.

Email Insight Service

A separate email service could send weekly summaries.

Example email sections:

This would make the platform more useful without requiring the user to log in every day.

Machine Learning Layer

A future machine learning layer could be used to identify patterns such as:

The first version does not need complex machine learning. Good trend analysis and clear summaries are more valuable at this stage.

What This Project Demonstrates

This project demonstrates several important product and technical capabilities:

It also shows how personal projects can be used to explore real product decisions rather than simply building technology for its own sake.

Product Management Reflection

The most important product decision in this project is the decision to focus on interpretation rather than collection.

Collecting Garmin data is useful, but not enough.

The real value comes from helping the user understand what has changed, why it might matter, and what they may want to monitor next.

This is a common product pattern: the data itself is not the product outcome. The decision support created from the data is the outcome.

The project also reflects an important principle in AI product design:

AI is most useful when it is grounded in structured data, clear rules, and a specific user problem.

The platform should not simply generate motivational fitness content. It should explain real trends using real data.

The future opportunity is to combine Garmin data, weight training data, and food tracking data into a more complete personal performance model. That is where AI suggestions become more useful: not because the model is clever, but because the context is richer.

Status

The project is currently in development.

Current focus areas include:

The next stage is to make the analysis outputs more useful, more visual, and easier to consume.

Longer-term development will focus on integrating data from my weight training app and food tracking app so the platform can make better AI-assisted suggestions across recovery, training, nutrition, and body composition.

Back to Projects