DEV Community: Priyanshu Patel

⏳Little Time Machine:- Your Past Is Waiting Outside Your Screen

Priyanshu Patel — Mon, 12 Oct 2026 06:50:57 +0000

The Places That Remember Us: Building Little Time Machine with Open-Weight AI 🌿⏳

Imagine what if AI could help us reconnect not just with the places we miss, but with the people, objects, and moments that made those places feel like home?

There are places we visit every day without realizing how much they mean to us.

An old oak tree beside a quiet road.The school gate where a best friend always waited.A small house that no longer belongs to us.A familiar street that still looks the same, even though the people who once walked along it have changed.

And sometimes, there are objects.
A faded photograph. A childhood toy. A book with someone's handwriting in the margins. An old gift that has lost its practical purpose but somehow remains impossible to throw away.

To someone else, these things might look ordinary.
To us, they can feel like pieces of a life we once lived.

Imagine returning to the street/ground where you and your childhood friends once played until sunset, or discovering an old belonging tucked away in a drawer—a faded photograph, a handwritten note, or a toy you carried everywhere. The place may have changed, and the object might seem ordinary to everyone else, but to you, they hold pieces of a life you once lived: shared laughter, familiar faces, forgotten conversations, and a version of yourself that still feels close when those memories come alive again.

And that is where Little Time Machine begins.

1.The Problem: We Save Everything Except the Feeling

We live in a world where saving a moment takes less than a second. We capture birthdays, trips, and everyday experiences, storing thousands of memories on our phones.

Yet, years later, we may remember what a place looked like without remembering how it felt to be there. A familiar playground, a street where we once played with friends, or a childhood belonging can bring back emotions we never expected to feel again.

These memories are more than what we see. They hold the people, experiences, and feelings that made those moments special.

Little Time Machine was born from this idea: helping people reconnect with the stories behind their memories and rediscover what those moments still mean to them today.

2.The Idea: Return to the Moment, Not Just the Location

Little Time Machine is built around a simple idea: using AI to help people turn real-world experiences into personal, narrated memories.

The journey begins away from the screen. You might revisit a familiar place, sit beneath an old tree, or find a childhood belonging that still holds special meaning. You take a photograph and write a few words about the memory it brings back.

For example:
“I came back to the playground where my friends and I used to race to the swings, take turns pushing each other higher, and laugh until the sun went down. We have all grown up, but for a moment, sitting here made me feel like that carefree child again.”

Those few words give the photograph something an image alone cannot capture: your personal story and the emotions behind it.

Little Time Machine uses your experience text to generate an AI-written reflection, narrate it as audio, and save it alongside your photograph so you can revisit the memory later.

The goal is not to recreate the past perfectly, but to help you reconnect with what it meant to you.

A familiar place becomes more than a location. An ordinary moment becomes a personal story. And a photograph becomes the beginning of a journey back in time.

3.Why the Past Feels Personal

The most meaningful memories are not always about big events. Sometimes, they live in ordinary places, familiar objects, and moments we wish we could experience one more time.

The places where childhood lives
Remember the playground where you raced your friends to the swings, played until sunset, and laughed over the smallest things? Years later, the playground may look different, and your friends may be far away. But standing there can bring back a little piece of the childhood you thought you had left behind.

The places that belonged to two people
A park bench, a school corridor, or a familiar meeting spot can hold the story of a friendship or a relationship. Returning there may bring a smile, along with the ache of missing someone who once made that place feel special.

The belongings that hold our memories
An old toy, a childhood watch, or a familiar object can carry a meaning no one else understands. Its value is not in what it costs, but in the people, feelings, and moments it brings back.

Meeting the person we used to be
Sometimes, revisiting the past reminds us how much we have grown. An old school or childhood home can bring back forgotten dreams, old friendships, and the simpler version of ourselves we still carry inside.

Little Time Machine is inspired by these connections. It helps us pause, reflect on the moments that shaped us, and remember not just where we came from, but what those memories still mean to us today.

4.Why “Touch Grass” Fits This Idea

Hacktoberfest 2026 Week 1’s “Touch Grass” theme encouraged building technology that connects people with the real world.

Little Time Machine brings this idea to life by encouraging people to step away from their screens, revisit familiar places, and reconnect with meaningful memories.

Take a walk through your old neighbourhood, sit beneath a familiar tree, or revisit a place from your childhood. Capture the moment and write a few words about what it means to you.

AI then helps turn your experience into a personal reflection, complete with audio narration.

The goal is simple: let real-world experiences inspire the memory, and let technology help preserve its meaning.

Step outside to reconnect with your past. Use technology to keep its meaning alive.

5.From a Personal Moment to a Narrated Memory

The current implementation turns a photograph and a written account of an experience into a saved memory card.

The flow is straightforward:

- A person visits a place or encounters an object that means something to them.
- They take a photograph.
- They provide the related quest text and a short written description of their experience.
- A locally run Gemma model generates a reflection through Ollama.
- ElevenLabs turns that reflection into audio narration.
- The application stores the memory information in MongoDB Atlas and makes the media available through the backend.

The emotional context comes from the person's own description. The AI generates a reflection based on that input; it does not independently know the history of a tree, identify the people involved, or retrieve forgotten events.

This distinction matters. A personal memory should begin with the person who lived it, not with an AI inventing a story on their behalf.

6. The Technology Behind Little Time Machine

Little Time Machine brings together local AI inference, audio narration, and persistent memory storage to transform everyday experiences into meaningful, revisitable stories. Each technology serves a specific role in the journey, from processing a user’s experience to generating a reflection and preserving it for the future.

Technology Stack & Their Role in the Project

TypeScript & Node.js

Power the backend application with type-safe development and server-side processing.

Express.js

Handles API endpoints, incoming requests, input validation, and communication between services.

Gemma 2 2B via Ollama

Runs a locally hosted, open-weight language model that generates personalized reflections from the user’s experience.

ElevenLabs

Converts generated reflections into natural-sounding audio narration.

MongoDB Atlas

Stores persistent memory records and their associated metadata.

Local File System

Stores uploaded photographs and generated audio files, which are served through the application’s media endpoints.

Sentry

Provides error monitoring and tracing integration to help identify and investigate application issues.

The project combines local model inference with external services. Gemma runs locally through Ollama, while narration and cloud database storage depend on their respective services.
That makes the application a practical exploration of open-weight AI, not a claim that the entire experience works offline.

7.Little Time Machine in Action: Screenshots & Demo🎬🌿

Step-by-step screenshots in our little time machine

Step 1 - This is the user interface where the user would select or get an random task

Step 2 - Here, the user sees the task and also can hear through the audio speak by ElevenLabs

Step 3 - Then the user will see the option of uploading the image

Step 4 - Then the user will click the upload image, it will redirect to the capturing page where your she can capture the moment

Step 5 - After capturing it, the user will get option of changing it and then express its feeling and emotion to that moment

Step 6 - The moment will be saved as a stamp of memory in the memory library. This is the personal memory library for the user, where he would recreate his childhood memories.

Step 7 - Now, by clicking at home button or clicking at any empty stamp box, would redirect the user back to the homepage to make more memory stamps.And also gets the option(button) to directly jump to the saved memory stamps.

DEMO Link:- coming soon

8.Architecture & Open Source Code:-From Experience to Memory

Little Time Machine is built as a modular AI-powered memory backend that connects outdoor quests, personal experiences, local language-model inference, narrated reflections, and persistent memory storage.

The architecture combines a TypeScript and Express backend with Gemma 2 2B running locally through Ollama, ElevenLabs text-to-speech, MongoDB Atlas, and local media storage.

Project Structure

little-time-machine/
├── src/
│   ├── routes/                  # API endpoints
│   ├── services/                # AI reflection and audio generation
│   ├── database/                # MongoDB Atlas integration
│   └── server.ts                # Express server entry point
├── media/                       # Generated photos and audio (if stored here)
├── package.json                 # Dependencies and npm scripts
├── tsconfig.json                # TypeScript configuration
├── .env                         # Local environment variables (not committed)
├── .gitignore                   # Files excluded from Git
└── README.md                    # Project documentation

Note: This is a high-level structure. Replace the illustrative src/ entries with the actual directory and filenames from your repository before publishing.

Core Technology Stack

Backend: TypeScript, Node.js, and Express
Open-weight AI: Gemma 2 2B through Ollama
Text-to-speech: ElevenLabs
Database: MongoDB Atlas
Media storage: Local filesystem for photographs and generated audio
Monitoring: Sentry integration

Key API Endpoints

Endpoint	Purpose
`GET /health`	Check backend availability
`POST /api/memory/process`	Process a photograph and written experience, generate a reflection and narration, and save the memory
`/media/...`	Retrieve uploaded photographs and generated audio

The memory-processing endpoint accepts a photograph, quest text, and experience description. It returns the generated reflection, media URLs, and timestamp after the main processing workflow succeeds.

GitHub Repository: https://github.com/priyanshuspatel/LittleTimeMachine.git
License: MIT License

Running Locally

You can run Little Time Machine on your local machine by installing the Node.js dependencies, configuring the required services, and starting the backend.

1. Clone the repository

git clone https://github.com/priyanshuspatel/LittleTimeMachine.git
cd LittleTimeMachine

Replace the placeholders with your actual GitHub URL and repository directory.

2. Install dependencies

npm install

3. Set up the local AI model

Install Ollama, then download Gemma 2 2B:

ollama pull gemma2:2b
ollama list

Ensure Ollama is running and the model is available to the backend.

4. Configure environment variables

Create a .env file using the variable names specified in your project configuration. Add the required MongoDB Atlas connection string and ElevenLabs credentials, along with any configured Sentry or model settings.

Keep your credentials private and never commit .env to GitHub.

5. Start the backend

npm run dev

The development server is expected to be available at http://localhost:3000, provided the project uses the default port and starts successfully.

6. Verify the backend

curl -i http://localhost:3000/health

A successful health check returns HTTP 200 OK in the tested development setup.

7. Create a test memory

Replace the example image path with a valid local JPEG or PNG image.

IMAGE="$HOME/Pictures/spot.jpg"

curl -sS -w '\nHTTP Status: %{http_code}\n' \
  -X POST http://localhost:3000/api/memory/process \
  -F "photo=@${IMAGE}" \
  -F "questText=Find a quiet place outdoors." \
  -F "experienceText=Sat under the tree where I played as a child."

When the required services are configured and the request succeeds, the API returns HTTP 201 Created with the saved memory information and media URLs.

8. Run development checks

npx tsc --noEmit
npm run build

Both checks passed in the tested development environment.

Cloud Deployment

Little Time Machine can be adapted for cloud deployment, but the deployment configuration must account for its local AI model and media storage.

Before deploying, ensure that:

The hosting environment supports the Node.js application and its required dependencies.
Ollama and Gemma are available to the backend, either on the same host or through an appropriately secured model service.
MongoDB Atlas and ElevenLabs credentials are configured through secure environment variables.
Uploaded photographs and generated audio use persistent storage if the hosting platform has an ephemeral filesystem.
Authentication, access controls, and appropriate privacy protections are implemented before accepting sensitive personal memories from public users.

A platform such as Render can host the Node.js backend, subject to its resource and deployment constraints. However, a working one-click deployment blueprint should only be advertised after a corresponding deployment configuration has been added and tested.

Deployment status: Local backend execution and the core memory-processing workflow have been tested. Cloud deployment instructions and a production-ready deployment blueprint remain to be confirmed against the actual repository.

Challenge Submission Categories

This project is submitted to the following partner categories for the Hacktoberfest Open-Source AI Challenge: Week 1 — Touch Grass.

🌿 Primary Category: Best Use of Gemma — Little Time Machine uses Google's open-weight Gemma 2 2B model locally through Ollama to transform a user's written real-world experience into a reflective memory. Whether someone returns to an old oak tree, revisits a familiar place shared with a loved one, or discovers a childhood belonging, Gemma helps turn the context they provide into a reflection they can revisit. Running inference locally gives the project control over its model workflow and demonstrates a practical use of open-weight AI beyond a conventional hosted-LLM integration.
🎙️ Partner Category: Best Use of ElevenLabs — ElevenLabs converts AI-generated memory reflections into MP3 narration, allowing users to listen to the stories connected to their experiences instead of only reading them on a screen. This adds an audio dimension to Little Time Machine's central idea: helping people reconnect with meaningful places, cherished objects, and personal moments.
🗄️ Partner Category: Best Use of MongoDB Atlas — MongoDB Atlas provides persistent storage for Little Time Machine's memory records. The application saves the experience text, generated reflection, photograph URL, narration URL, and timestamp together, creating a foundation for revisiting personal memories rather than treating each AI generation as a disposable response.
🔎 Partner Category: Best Use of Sentry Agent Tracing — Little Time Machine integrates Sentry into its backend for error monitoring and tracing-related observability. This supports the reliability of a multi-step workflow involving image uploads, local AI inference, audio generation, and database persistence. The goal is to make failures easier to investigate as the application evolves.

💚 A Little Thank You to the Hacktoberfest Team and DEV

A heartfelt thank you to the Hacktoberfest team for creating this wonderful opportunity! I'm genuinely happy to be part of this journey—from brainstorming a creative idea to building Little Time Machine with open-weight AI and open-source technology. 🌿

What makes this experience special is the chance to build something meaningful: a project that encourages people to step away from their screens, revisit familiar places, reconnect with cherished memories, and spend a little more time in the real world. I'm grateful for the opportunity to learn, create, experiment, and turn an idea into something that could genuinely make a difference. ❤️⏳

HealthMate AI: A Personal Health Companion Built for a Friend

Priyanshu Patel — Mon, 05 Oct 2026 06:44:53 +0000

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.