HealthMate AI: A Personal Health Companion Built for a Friend

Hacktoberfest Weekend Challenge: Build for a Friend Submission
This is a submission for the Hacktoberfest Weekend Challenge: Build for a Friend.
The Problem Was Not Another Fitness App
My friend did not need another application showing a giant calorie counter.
They needed something much simpler:
"What should I actually do today?"
Like many people trying to improve their health, they were dealing with food tracking, exercise, weight goals, calorie targets, and trying to understand whether the choices they made today were actually moving them toward their goal.
The frustrating part was that the information was scattered.
A meal might be written as:
"I had 2 eggs, two slices of toast and a banana."
Exercise might be logged separately.
Weight might be tracked somewhere else.
And at the end of the day, the person still had to manually connect everything together.
That was the motivation behind HealthMate AI.
Instead of building another static calorie tracker, I wanted to build a personal health companion that could understand natural language, calculate health metrics deterministically, learn patterns from structured historical data, and provide useful explanations.
Most importantly, I wanted to build it for one person first.
Not for everyone.
For a friend.
Meet HealthMate AI
HealthMate AI is a predictive personal health and nutrition companion.
The idea is simple:
Your Health Data
↓
HealthMate
↓
Understand
↓
Calculate
↓
Predict
↓
Explain
↓
Take Action
The system combines three technologies, each with a specific responsibility.
Gemma
Natural-language health assistant.
Gemma 3:1B understands things such as:
"I had 2 eggs, 2 slices of toast and 1 banana for breakfast."
It converts that natural-language input into structured food information.
TabPFN
Predictive tabular intelligence.
TabPFN is used for structured health-data prediction where enough historical data is available.
Rather than asking an LLM to perform numerical prediction, HealthMate separates the prediction problem from the language problem.
DigitalOcean
Production infrastructure.
DigitalOcean provides the infrastructure required to take HealthMate from a local AI prototype toward a production-ready deployment.
This separation is important.
Each technology does what it is good at.
The First Interaction: "I Ate This..."
One of the first things I wanted to fix was the traditional food logging experience.
Instead of forcing my friend to search through a massive database:
Search food
→ Select food
→ Select quantity
→ Select unit
→ Repeat
→ Save
HealthMate allows natural language.
For example:
"I had 2 eggs, 2 slices of toast and 1 banana."
The request travels through:
Frontend
↓
FastAPI
↓
Ollama
↓
Gemma 3:1B
↓
Structured JSON
Gemma identifies the food items and quantities.
For example:
{
"meal_type": "breakfast",
"items": [
{
"name": "eggs",
"quantity": 2,
"unit": "piece"
},
{
"name": "toast",
"quantity": 2,
"unit": "slice"
},
{
"name": "banana",
"quantity": 1,
"unit": "piece"
}
]
}
But there is an important engineering decision here.
I Don't Let the LLM Do the Math
An LLM should understand:
"2 eggs."
It should not be trusted as the authoritative calculator for exact nutritional values.
Therefore HealthMate separates language understanding from health calculations.
The architecture is:
Gemma
↓
Food + Quantity
↓
Deterministic Backend
↓
Calories + Macros
↓
User Review
↓
Confirm & Save
This makes the system much more predictable.
Gemma Runs Locally
One of the most important design decisions was running Gemma locally.
My development machine is a MacBook Air with an M4 chip and 16 GB RAM.
I installed:
Ollama
Gemma 3:1B
The local architecture is:
MacBook
↓
Ollama
↓
Gemma 3:1B
↓
HealthMate FastAPI
The local Ollama endpoint is:
http://localhost:11434
And the application uses:
gemma3:1b
There is no Gemma API key required for this local setup.
The model runs locally instead of sending every meal log to a remote LLM service.
That matters because health and nutrition information is personal.
The "Don't Save It Yet" Rule
Another important design decision was adding a confirmation layer.
AI should not silently write information into someone's health history.
When Gemma interprets a meal, HealthMate shows the interpretation first:
Gemma understood your meal as:
2 eggs
2 slices toast
1 banana
[ Edit ] [ Confirm & Save ]
The user can correct:
food
quantity
unit
meal type
Only after confirmation is the information persisted.
This creates a much safer interaction:
AI interpretation
↓
Human verification
↓
Database
rather than:
AI
↓
Database
HealthMate Is More Than a Calorie Counter
Once food and activity data are structured, HealthMate can calculate useful metrics.
The application keeps deterministic health calculations in backend logic.
Examples include:
calorie intake
macronutrients
BMR
TDEE
calorie balance
activity information
weight trends
The important distinction is:
Gemma = understands language
Backend = performs calculations
TabPFN = performs prediction
Frontend = makes the result understandable
From Tracking to Prediction
Logging information is useful.
But eventually I wanted HealthMate to answer a more interesting question:
"What does my history suggest?"
This is where TabPFN enters the architecture.
HealthMate stores structured historical information such as:
Date
Weight
Calories
Protein
Carbohydrates
Fat
Exercise
Activity
Other available health metrics
Instead of treating every day independently, HealthMate can use the accumulated history as structured data.
The intended prediction pipeline is:
PostgreSQL
↓
Historical Health Data
↓
Feature Preparation
↓
TabPFN
↓
Prediction
↓
HealthMate Dashboard
For time-dependent information, the architecture can also use appropriate TabPFN time-series functionality when supported by the installed environment.
Why TabPFN?
Personal health datasets are often small.
A person does not necessarily have millions of rows of personal health information.
They might have:
30 days
60 days
90 days
180 days
of structured personal history.
Traditional machine-learning workflows often require substantial preprocessing, model selection, and hyperparameter tuning.
TabPFN is interesting for this type of problem because it is specifically designed around tabular foundation-model inference.
HealthMate therefore uses a different division of responsibility:
Gemma
"I understand what the user said."
TabPFN
"I analyze the structured historical data."
Backend
"I calculate deterministic health metrics."
Frontend
"I make the result understandable."
Gemma + TabPFN
This creates an interesting AI pipeline.
Imagine TabPFN produces a structured result:
{
"prediction": 72.1,
"horizon_days": 7,
"model": "TabPFN"
}
HealthMate can then pass the structured result to Gemma.
Gemma's job is not to invent another prediction.
Its job is to explain the existing one.
The architecture becomes:
Health Data
↓
TabPFN
↓
Structured Prediction
↓
Gemma
↓
Human-Friendly Explanation
For example:
"Based on your recent logged trend, your current trajectory is relatively stable over the next week."
The numerical prediction remains owned by the predictive model.
The HealthMate Dashboard
The goal of the dashboard is not to overwhelm the user with AI terminology.
It should answer a few simple questions.
How am I doing today?
Calories
1,840 / 2,100 kcal
What did I eat?
Protein: 92g
Carbs: 218g
Fat: 61g
What did I do?
Exercise: 42 min
Activity: 8,240 steps
What is my recent trend?
Weight Trend
What does the AI think?
Gemma
"Your protein intake was strong today..."
What does the predictive model say?
TabPFN
Prediction available
The interface separates these pieces so the user knows what they are looking at.
A Transparent AI System
HealthMate explicitly communicates where information comes from.
For example:
Powered by Gemma 3:1B • Local AI
For predictions:
Powered by TabPFN
For deterministic metrics:
Calculated from your logged data
If there is insufficient historical data:
Not enough historical data yet.
Keep logging your health data to unlock predictive insights.
If a model is unavailable, the application should say so.
No fake predictions.
No hidden fallback.
No pretending that a heuristic is machine learning.
Privacy Was a Feature, Not an Afterthought
Health information is different from ordinary application data.
Weight.
Food.
Exercise.
Goals.
Personal habits.
These are things people may not want uploaded to an arbitrary AI service.
That is why the local development architecture is:
User
↓
HealthMate
↓
FastAPI
↓
Ollama
↓
Gemma 3:1B

rather than:

User
↓
HealthMate
↓
External LLM API
The local Gemma setup allows the core natural-language interaction to happen on the user's machine.
For production, DigitalOcean provides the infrastructure layer needed to deploy the application and its AI/ML components in a controlled environment.
Built on a Real Full-Stack Architecture
HealthMate is not just a frontend prototype.

healthmate/
├── backend/
│ ├── app/
│ │ ├── ai/
│ │ │ ├── factory.py
│ │ │ ├── ollama.py
│ │ │ └── ...
│ │ │
│ │ ├── health/
│ │ │ └── nutrition.py
│ │ │
│ │ ├── api/
│ │ │ └── assistant.py
│ │ │
│ │ └── ...
│ │
│ └── tests/
│
├── frontend/
│ ├── components/
│ │ └── MealAssistant.tsx
│ └── ...
│
├── scripts/
│ └── test_ollama_gemma.py
│
├── .env
├── .env.example
└── ...
The exact repository structure may evolve as TabPFN and production infrastructure are completed.
The Technology Stack
Frontend: React / TypeScript
Responsibility: Health dashboard
Backend: FastAPI
Responsibility: API and application logic
Database: PostgreSQL
Responsibility: Structured health history
Local LLM: Gemma 3:1B
Responsibility: Natural-language understanding
Local inference: Ollama
Responsibility: Runs Gemma locally
Predictive ML: TabPFN
Responsibility: Structured prediction
Time-series ML: TabPFN-TS where supported
Responsibility: Historical forecasting
Infrastructure: DigitalOcean
Responsibility: Production deployment
Validation: Pydantic
Responsibility: Structured AI outputs
Current Implementation Status
The first major milestone is already working.
Gemma + Ollama
Verified.
The actual local pipeline has been tested:
"2 eggs, 2 slices of toast and 1 banana"
Gemma successfully identified three food items.
The verification produced structured items including:
eggs
toast
banana
The application then validated the result through its Pydantic schemas.
The current test suite also reports:
40 passed
Frontend typechecking and production build have also been successfully verified.
What Is Still Being Built
The project is intentionally being developed in stages.
Completed:
Full-stack HealthMate foundation
FastAPI backend
Frontend dashboard
PostgreSQL integration
Natural-language meal input
Local Ollama integration
Gemma 3:1B
Structured meal parsing
Pydantic validation
Deterministic nutrition calculations
BMR/TDEE-related health calculations
User review/edit flow
Confirm-before-save workflow
AI assistant
AI summaries
Mock provider for testing
Gemma/Ollama verification tests
In Progress:
Real TabPFN predictive pipeline
Historical feature preparation
TabPFN prediction APIs
Time-series forecasting where compatible
Predictive dashboard
DigitalOcean production infrastructure
I am deliberately not presenting the unfinished predictive components as completed features.
Building It for a Friend
The most important part of this project isn't the model.
It's the person sitting behind the screen.
[INSERT YOUR FRIEND'S REAL STORY HERE]
For example:
What problem were they actually having?
How were they tracking food before?
What frustrated them?
What made you decide to build this?
What did they say after trying it?
Once you have real feedback, this section should contain an actual quote from your friend.
For example:
"[INSERT YOUR FRIEND'S REAL QUOTE HERE]"
The story should be real.
That's what makes a "Build for a Friend" project different from building another generic AI demo.
Why Open AI Infrastructure Matters
HealthMate is an experiment in combining open and controllable AI infrastructure.
Gemma provides the language intelligence.
TabPFN provides the predictive intelligence.
DigitalOcean provides the production infrastructure.
Together:
Open/controllable AI
+
Structured health data
+
Deterministic calculations
+
Predictive ML
+
Human verification
Personal Health Companion
The goal isn't to replace doctors.
It isn't to diagnose diseases.
It isn't to pretend an AI knows someone's body better than they do.
The goal is much more practical:
Take the messy information people already generate about their health and turn it into something understandable and useful.
What I Learned Building HealthMate
The biggest lesson was that AI doesn't mean putting an LLM everywhere.
Sometimes the correct answer is an LLM.
Sometimes it is deterministic Python.
Sometimes it is a tabular foundation model.
Sometimes it is simply a database query.
The engineering challenge is deciding which one belongs where.
HealthMate ended up with this philosophy:
Natural language?
→ Gemma
Exact calculation?
→ Backend logic
Structured prediction?
→ TabPFN
Historical forecasting?
→ TabPFN-TS where appropriate
Production infrastructure?
→ DigitalOcean
Human decision?
→ The user
What's Next?
The next milestone is turning HealthMate from an intelligent health tracker into a genuinely predictive companion.
The roadmap is:
Natural-language health logging
↓
Local Gemma 3:1B
↓
Deterministic health calculations
↓
TabPFN prediction
↓
Time-series forecasting
↓
DigitalOcean production deployment
↓
HealthMate AI
The ultimate goal is simple:
"Your health data should help you understand tomorrow, not just record yesterday."
Prize Categories
This project is being submitted to the following partner tracks:
Best Use of Gemma — Gemma 3:1B runs locally through Ollama and powers natural-language meal understanding and health explanations.
Best Use of TabPFN — TabPFN is being integrated as the structured predictive ML layer for HealthMate's historical health data.
Best Use of DigitalOcean — DigitalOcean is being used as the production infrastructure target for deploying HealthMate's backend and AI/ML services.
Try HealthMate
GitHub: [INSERT REPOSITORY URL]
Live Demo:
Screenshots: [INSERT SCREENSHOTS]
Local Setup
Install Ollama and the Gemma model:
ollama pull gemma3:1b
Verify:
ollama list
Run Gemma:
ollama run gemma3:1b
Configure:
AI_PROVIDER=ollama
OLLAMA_BASE_URL=http://localhost:11434
GEMMA_MODEL=gemma3:1b
Then start the HealthMate backend and frontend using the project's existing development commands.
Built for a Friend, Designed for Real Life
I started HealthMate because one person I care about shouldn't have to become a nutrition expert, data analyst, and machine-learning engineer just to understand their own health information.
The technology is complicated.
The experience shouldn't be.
Gemma understands what they say.
The backend calculates what can be calculated reliably.
TabPFN looks for patterns in structured history.
DigitalOcean gives the project a path toward production.
And the final decision?
That still belongs to the person using it.
That's HealthMate AI.