DEV Community: Priyanshu Patel

I got tired of checking my Mac, so I built a little 👻Halloween light to do it for me (Arduino UNO Q + Gemma)

Priyanshu Patel — Sat, 31 Oct 2026 16:58:54 +0000

This is the project which was made for week three, but what happened I submitted before time, but still when I edited few things in it after the deadline, it gets submitted for the week four, so now change it the whole idea with the theme of week four. You might also find the same two post as I am getting some errors that it is not submitted, so I had submitted it twice.

I got my Arduino UNO Q at a Hacktoberfest meetup, and now I'm finally putting it to use! I'm building Still Loading... as my project for Dev Challenge, giving the board a little Halloween Theme.

My terminal has ghosts, so I built a little Halloween device to catch them (Arduino UNO Q + Gemma)

I kept staring at a terminal for jobs that had already died.

A job can look alive and still be gone. A download can crawl while I keep refreshing its percentage. A traceback can sit unnoticed in another terminal. Sometimes, it feels like my computer has a few ghosts of its own.

So I built Still Loading...: an Arduino UNO Q whose 8×13 LED matrix shows what my Mac is doing, so I can glance at my desk instead of constantly checking the screen. When a job fails, a local Gemma model explains why, and my code checks that the log line it quotes really exists.

For Week Four, I gave the project a Halloween transformation. The underlying idea is the same, but its visual identity is now inspired by ghosts, skulls and other spooky illustrations. What started as a small status light now looks like a little haunted companion for my desk.

Why I built this

I got my Arduino UNO Q at a Hacktoberfest meetup. It was my first Arduino, and I had never built anything on one before. When this challenge came up, I wanted to use it for a real project instead of leaving it in a drawer.

My first idea list was the obvious one: a plant-watering device, an email or message summarizer, and similar ideas. I looked around and saw that people had already built these, and built them well. I didn't want to make a copy of something that already existed just to have an Arduino in the photo.

So I asked a different question: what do I keep doing by hand that a small light could do for me? The answer was already on my screen. I kept checking terminals and download bars to see whether something was still alive.

That is where the idea of ghost jobs came from: processes that look alive but have already stopped making progress or have failed without me noticing.

I wanted a light that stays quiet while things are fine and gets my attention when something needs me. That is the problem Still Loading... tries to solve.

From status light to haunted desk companion

The Halloween theme gave me a reason to rethink the illustrations throughout the project.

Instead of relying on ordinary status symbols, I refreshed the visuals with spooky, horror-inspired artwork. The idea was to make the matrix feel like a small Halloween device rather than a conventional system monitor.

The ghostly visual direction fits the project naturally:

Ghosts represent jobs that have disappeared or become unresponsive.
Skulls and darker illustrations give failures a more recognisable visual identity.
Pumpkins, bats and other Halloween-inspired artwork bring personality to the ordinary status displays.
The overall look makes the device feel like a little haunted companion sitting beside my computer.

This is a visual transformation of the existing project. The underlying monitoring, communication and diagnosis flow remains the same.

TL;DR

A little ghost watcher for my desk. The matrix shows idle, running, completed, failed, suspected stall, battery, charging and download.
Halloween makeover. The illustrations have been refreshed with a spooky visual identity.
Real data, not animations. It showed a live Chrome download climbing from 0% to 15%, and real macOS battery readings.
Gemma explains, code verifies. gemma2:2b runs locally on my Mac and quotes a log line. Plain code checks the quote is in the redacted log and marks the answer VERIFIED or UNVERIFIED. One live call took about 4.6 seconds.
Tested. 20 captured failure logs as a baseline. The latest full run passed 202 Mac-agent tests, 2 relay tests, the web tests, the demo suite and the production build.
Honest boundary. Gemma runs on the Mac. The UNO Q receives state and displays it. VERIFIED means the quote exists, not that the diagnosis is right.

Updated visuals for the Halloween

How it works

The computer does the work. The board makes the state visible.

Browser Control Deck → Mac backend (battery, Chrome downloads, jobs, Gemma)
      → UNO Q HTTP receiver → App Lab bridge → 8×13 LED matrix

Layer	What it does
Mac	Battery reader (`pmset`), Chrome download monitor, job runner, log redaction, Gemma, evidence check, Control Deck backend
UNO Q Linux	HTTP receiver and App Lab bridge
LED matrix	Draws each state as a pattern

The Control Deck is a browser page with six buttons: Battery, Download, Run Job, Failed, Reset and Stop. Each calls a fixed backend operation. The browser never runs arbitrary shell commands. The same state drives a matrix preview on the page and the physical matrix.

The Halloween illustrations change how the information looks, not what the underlying states mean.

Gemma explains, code verifies

A small model can invent a log line that sounds right, so it has to prove its answer.

Failure log → redaction → local Gemma → diagnosis + quoted line → exact-match check → VERIFIED / UNVERIFIED

I ran python3 run_job.py --gemma -- python3 -c "import non_existent_pkg_xyz". The log ended in ModuleNotFoundError: No module named 'non_existent_pkg_xyz'. Gemma called it a missing dependency, severity error, and quoted that line. The checker found it in the log and returned verified.

If Gemma times out or returns malformed output, a rules-based explainer takes over. The failure state never waits for the AI.

Evidence

I tested Still Loading... against captured failure logs and real system activity, rather than relying only on simulated progress or an AI answer that sounds convincing.

Measure	Result
Failure logs captured	20 examples covering Python, Node.js, Git, a non-executable script and refused connections. Two empty excerpts were excluded from text-based analysis.
Gemma diagnosis	In a live test, a deliberately triggered `ModuleNotFoundError` was classified as `missing_dependency`, with severity `error` and confidence around `0.9`.
Evidence verification	In that example, Gemma quoted the missing-module error and the checker found the quoted text in the redacted log, returning `VERIFIED`. Tests also cover genuine and fabricated quotes.
Gemma response time	One observed live call took approximately 4.6 seconds. The configured timeout is 8 seconds, with a rules-based fallback for timeouts or invalid responses.
Chrome download progress	Real progress updates were observed from 0% to 15%, including intermediate percentage changes.
Download test coverage	Automated tests cover progress values including 0%, 1%, 50%, 86%, 99% and 100%, unknown totals, zero-byte cases, completion, failure, cancellation and duplicate-update handling.
macOS battery	Real readings of 100% and 99% were observed.
Automated software tests	The latest reported run passed 202 Mac-agent tests and 2 relay tests, along with the web tests, demo suite and production build.

What these results prove

The live failure example demonstrates that Gemma can explain a deliberately triggered failure and that the evidence checker can verify its quoted text against the redacted log. The captured logs and automated tests provide a starting point for evaluating more cases.

These results are not an overall accuracy benchmark. I have not established aggregate figures for diagnosis agreement, quote-verification rate or Gemma timeout frequency across the 20-log fixture. I also have not established measured watchdog catch rates for genuine stalls or false alarms on slow-but-healthy jobs, so I am not claiming those numbers.

One hardware distinction matters: the receiver returned 200 OK to an authenticated request, confirming network reachability. The full Control Deck-to-physical-matrix path was subsequently recorded on the board on 26 October.

These are early engineering results, not a benchmark. They document what I have tested and leave the unmeasured results clearly identified as work still to do.

What went wrong on the hardware

Wrong address. SSH to 192.168.1.5 was refused. The board was at 192.168.1.10.
Wrong Python. Running the App Lab script with system Python gave No module named 'arduino'. It needs the App Lab runtime.
Missing token. The receiver refused to start until its bearer token was set. After that it listened on port 8090 and answered 200 OK on /v1/lights.

The lesson: when the web preview changes but the board does not, trace the state link by link instead of rewriting the renderer.

Why open matters

Failure logs hold tokens, private paths and URLs. I redact known secret patterns, cap what Gemma sees at about 6,000 characters, and keep inference on my Mac, so the raw log never goes to someone else's server. Open parts also let me inspect why the matrix changed and exactly what the model was shown. A hosted model might diagnose hard failures better and faster. For a one-sentence explanation checked by code, local was enough.

Limits

Gemma runs on the Mac, not on the UNO Q.
VERIFIED proves the quote exists, not that the diagnosis is correct.
Redaction is pattern-based and can miss unusual secrets.
Battery readings are whole-number percentages. If the Mac sleeps, monitoring pauses and the board keeps its last state.
20 logs is a small baseline, not an accuracy study.

The lazy payoff

I wanted a device that would let me stop checking whether every process was still alive.

Now, instead of constantly watching terminals and download bars, I can glance at a little Halloween-themed display on my desk. When everything is fine, it quietly shows the status. When a job fails or becomes unresponsive, the ghostly visuals make the change harder to miss.

A ghost is the job I used to keep checking. Now the light does it.

Prize categories

Best Use of Arduino. The UNO Q is the physical end of the system: it receives state and shows progress, completion, failure, battery, charging, download and suspected stall on its 8×13 LED matrix. The Halloween illustrations give that physical feedback a distinctive visual identity. The model currently runs on my Mac, not on the UNO Q, so my entry focuses on the physical-agent side of the category: using the board to turn real system activity into a visible, glanceable signal.

Best Use of Gemma. Gemma explains redacted failure logs with severity and a recommended action, and its quoted evidence is checked in code.

AI use

I used AI assistance to build this. Gemma is also a runtime part of the project, running locally. It never controls the hardware, and the light does not depend on it.

Want to try Still Loading...?

You can check out the live version here: Live Demo.

Want to run it on your own Mac? Head over to the GitHub repository, where the README includes the setup instructions and steps to get the project running on your computer. Give it a try! 👻

Repo: https://github.com/priyanshuspatel/Still_Loading...

· License: MIT Licence ·

Demo video: https://youtu.be/WynEIrjoguQ ·

Updated with Halloween version: https://youtu.be/ZAkOoChQL1U

Author: Priyanshu Patel

I got tired of checking my Mac, so I built a little 👻Halloween light to do it for me (Arduino UNO Q + Gemma)

Priyanshu Patel — Mon, 26 Oct 2026 03:02:46 +0000

I got my Arduino UNO Q at a Hacktoberfest meetup, and now I'm finally putting it to use! I'm building Still Loading... as my project for Dev Challenge, giving the board a little Halloween Theme.

My terminal has ghosts, so I built a little Halloween device to catch them (Arduino UNO Q + Gemma)

I kept staring at a terminal for jobs that had already died.

Why I built this

That is where the idea of ghost jobs came from: processes that look alive but have already stopped making progress or have failed without me noticing.

I wanted a light that stays quiet while things are fine and gets my attention when something needs me. That is the problem Still Loading... tries to solve.

From status light to haunted desk companion

The Halloween theme gave me a reason to rethink the illustrations throughout the project.

The ghostly visual direction fits the project naturally:

Ghosts represent jobs that have disappeared or become unresponsive.
Skulls and darker illustrations give failures a more recognisable visual identity.
Pumpkins, bats and other Halloween-inspired artwork bring personality to the ordinary status displays.
The overall look makes the device feel like a little haunted companion sitting beside my computer.

This is a visual transformation of the existing project. The underlying monitoring, communication and diagnosis flow remains the same.

TL;DR

A little ghost watcher for my desk. The matrix shows idle, running, completed, failed, suspected stall, battery, charging and download.
Halloween makeover. The illustrations have been refreshed with a spooky visual identity.
Real data, not animations. It showed a live Chrome download climbing from 0% to 15%, and real macOS battery readings.
Gemma explains, code verifies. gemma2:2b runs locally on my Mac and quotes a log line. Plain code checks the quote is in the redacted log and marks the answer VERIFIED or UNVERIFIED. One live call took about 4.6 seconds.
Tested. 20 captured failure logs as a baseline. The latest full run passed 202 Mac-agent tests, 2 relay tests, the web tests, the demo suite and the production build.
Honest boundary. Gemma runs on the Mac. The UNO Q receives state and displays it. VERIFIED means the quote exists, not that the diagnosis is right.

Updated visuals for the Halloween

How it works

The computer does the work. The board makes the state visible.

Browser Control Deck → Mac backend (battery, Chrome downloads, jobs, Gemma)
      → UNO Q HTTP receiver → App Lab bridge → 8×13 LED matrix

Layer	What it does
Mac	Battery reader (`pmset`), Chrome download monitor, job runner, log redaction, Gemma, evidence check, Control Deck backend
UNO Q Linux	HTTP receiver and App Lab bridge
LED matrix	Draws each state as a pattern

The Halloween illustrations change how the information looks, not what the underlying states mean.

Gemma explains, code verifies

A small model can invent a log line that sounds right, so it has to prove its answer.

Failure log → redaction → local Gemma → diagnosis + quoted line → exact-match check → VERIFIED / UNVERIFIED

If Gemma times out or returns malformed output, a rules-based explainer takes over. The failure state never waits for the AI.

Evidence

I tested Still Loading... against captured failure logs and real system activity, rather than relying only on simulated progress or an AI answer that sounds convincing.

Measure	Result
Failure logs captured	20 examples covering Python, Node.js, Git, a non-executable script and refused connections. Two empty excerpts were excluded from text-based analysis.
Gemma diagnosis	In a live test, a deliberately triggered `ModuleNotFoundError` was classified as `missing_dependency`, with severity `error` and confidence around `0.9`.
Evidence verification	In that example, Gemma quoted the missing-module error and the checker found the quoted text in the redacted log, returning `VERIFIED`. Tests also cover genuine and fabricated quotes.
Gemma response time	One observed live call took approximately 4.6 seconds. The configured timeout is 8 seconds, with a rules-based fallback for timeouts or invalid responses.
Chrome download progress	Real progress updates were observed from 0% to 15%, including intermediate percentage changes.
Download test coverage	Automated tests cover progress values including 0%, 1%, 50%, 86%, 99% and 100%, unknown totals, zero-byte cases, completion, failure, cancellation and duplicate-update handling.
macOS battery	Real readings of 100% and 99% were observed.
Automated software tests	The latest reported run passed 202 Mac-agent tests and 2 relay tests, along with the web tests, demo suite and production build.

What these results prove

These are early engineering results, not a benchmark. They document what I have tested and leave the unmeasured results clearly identified as work still to do.

What went wrong on the hardware

Wrong address. SSH to 192.168.1.5 was refused. The board was at 192.168.1.10.
Wrong Python. Running the App Lab script with system Python gave No module named 'arduino'. It needs the App Lab runtime.
Missing token. The receiver refused to start until its bearer token was set. After that it listened on port 8090 and answered 200 OK on /v1/lights.

The lesson: when the web preview changes but the board does not, trace the state link by link instead of rewriting the renderer.

Why open matters

Limits

Gemma runs on the Mac, not on the UNO Q.
VERIFIED proves the quote exists, not that the diagnosis is correct.
Redaction is pattern-based and can miss unusual secrets.
Battery readings are whole-number percentages. If the Mac sleeps, monitoring pauses and the board keeps its last state.
20 logs is a small baseline, not an accuracy study.

The lazy payoff

I wanted a device that would let me stop checking whether every process was still alive.

A ghost is the job I used to keep checking. Now the light does it.

Prize categories

Best Use of Gemma. Gemma explains redacted failure logs with severity and a recommended action, and its quoted evidence is checked in code.

AI use

I used AI assistance to build this. Gemma is also a runtime part of the project, running locally. It never controls the hardware, and the light does not depend on it.

Want to try Still Loading...?

You can check out the live version here: Live Demo.

Want to run it on your own Mac? Head over to the GitHub repository, where the README includes the setup instructions and steps to get the project running on your computer. Give it a try! 👻

Proveniq: An AI License Review Is Only Useful When It Can Show Its Evidence

Priyanshu Patel — Mon, 19 Oct 2026 05:47:26 +0000

What happens when you download an asset, use AI to review its license, and discover later that you cannot prove where the information came from?

Imagine finding the perfect illustration, icon, font, or code snippet for a project. You save it, start building, and move on. A few weeks later, you need to answer some basic questions:

Where did this asset come from?
Who created it?
What license applies to it?
Does that license permit my intended use?
Can I prove why I believe it is safe to use?

Sometimes, the information is scattered across webpages, README files, license notices, and personal notes. Sometimes the creator is unknown. Sometimes the license is ambiguous.

And sometimes, an AI confidently gives you an answer that sounds correct but has no reliable evidence behind it.

That last problem is what I wanted to address.

I built Proveniq, an open-source, AI-assisted asset provenance and license-screening tool designed to help developers organize asset information, inspect license terms, and identify issues that need human review.

The idea is simple: AI can help interpret license information, but it should not be allowed to invent evidence or make the final decision.

What I Built

Proveniq lets you record an asset's name, source URL, creator information, license details, and intended use in one place.

It then helps turn the available license text into structured information, connects extracted details to supporting quotations, and checks supported license conditions against the intended use.

The goal is not to replace legal review. It is to make missing information, potential conflicts, and uncertainty easier to see before they become problems.

A typical workflow looks like this:

Record the asset. Add its source, known creator, license information, and intended use.
Extract candidate information. Gemma analyzes the supplied license text and returns structured fields.
Check the evidence. Extracted conditions need supporting quotations from the provided text.
Evaluate the rules. Deterministic application code checks supported license conditions against the declared use.
Flag uncertainty. Unsupported licenses, ambiguous terms, and insufficient evidence go to manual review instead of receiving a confident-looking approval.
Generate a report. Produce a Markdown report or print/save a PDF containing the recorded information, evidence, missing fields, and unresolved warnings.

The important part is what happens when the system cannot establish an answer.

It should expose the uncertainty—not hide it behind a polished AI response.

The Design Decision That Shaped Proveniq

My first priority was deciding what the language model should not control.

Gemma is useful for extracting candidate information from unstructured text. But extracting a license identifier is not the same as proving that an asset can legally be used in a particular situation.

Those are different responsibilities.

In Proveniq:

Gemma extracts candidate information.
Evidence quotations show what supports that information.
Deterministic code evaluates supported rules.
Missing or unsupported information triggers manual review.
The model does not decide the final review status.

This separation matters because a model can produce valid-looking structured output while still getting the underlying facts wrong.

A JSON response is not proof. A plausible license name is not proof. Even a correct license identifier does not automatically establish that a specific use complies with every applicable condition.

I wanted the system to make those distinctions visible.

⚙️ How I Built It

The stack is intentionally straightforward:

Frontend: Next.js and TypeScript
Backend: FastAPI and Python
Persistence: SQLite
AI inference: Gemma 2 2B through Ollama
Validation: Pydantic schemas and deterministic application rules
Deployment preparation: Docker and Render configuration

The model works with the license text supplied to the application. The system validates the structure of its response and checks supporting quotations rather than blindly trusting the generated fields.

I also worked on failure handling and evidence integrity.

For example, when the source license text or source URL changes, stale extraction results are cleared. When relevant evidence or the intended use changes, an earlier assessment can become outdated. Quotations are checked against the supplied text, and unsupported cases are not treated as successful reviews.

The application also handles inference failures without pretending an extraction succeeded.

These details are less exciting than a flashy AI demo, but they are central to a tool whose output people may rely on when managing software and creative assets.

Testing the Idea Instead of Trusting the Demo

I wanted to evaluate more than whether the application could return JSON.

I created a versioned fixture set containing 28 license notices. Of these, 27 were sent to Gemma; the blank notice was rejected with an HTTP 422 response.

Here are the results from that evaluation:

Measurement	Result
Nonblank notices evaluated by Gemma	27
License identifiers extracted	27/27
Attribution requirements extracted	21/27
Creator information extracted	12/27
Invented creator or attribution details	0
Documented rule-engine outcomes matched	15/15

The results highlight an important distinction.

The model extracted a license identifier from every nonblank fixture, but attribution and creator information were not always available. Those missing fields are not something an application should silently fill in.

The fixture suite also covers unsupported or ambiguous cases—including MIT/WTFPL cases, prompt-injection attempts, draft studio terms, and ambiguous license tokens—that should lead to an unknown result or manual review rather than an invented clearance.

The rule-engine result measures agreement with the documented outcomes in that test set. It does not establish universal legal correctness.

The automated suite currently passes 118 backend tests and 19 frontend tests. Type checking, linting, and the production build also passed in the recorded checks.

There are still limits to what these results establish: the final automated suite uses mocked inference rather than a live Ollama evaluation, and a successful build is not the same as a verified production deployment.

I would rather state those limitations clearly than make the project look more complete than it is.

What I Learned While Building It

The most important lesson was that reliability cannot come from prompting alone.

A better prompt can improve extraction, but it cannot guarantee that every answer is correct. The application needs checks outside the model: schema validation, evidence verification, explicit handling of unsupported cases, and rules that can be tested independently.

I also learned that missing data deserves first-class treatment.

If Proveniq cannot establish the creator, it should say the creator is unknown. If it cannot support a license interpretation, it should request review. If the source changes, the old assessment should not quietly remain authoritative.

In other words:

The absence of evidence is a result the application must preserve, not a gap for AI to fill.

That principle influenced the product more than any individual prompt.

Why Open Innovation Matters Here

License and provenance information can be part of a developer's workflow every day. I wanted to explore whether a small open-weight model could make that workflow more organized without turning the model into an unquestioned authority.

Using Gemma through Ollama gives the project an inspectable, replaceable inference layer rather than making the core workflow dependent on a closed, metered model API.

The deterministic checks remain ordinary application code. The data model, validation logic, and evaluation fixtures can be inspected and improved independently of the model.

That separation also makes the project easier to challenge. Developers can question a rule, add a fixture, reproduce a failure, or improve extraction without needing to accept a black-box verdict.

Open source does not automatically make an AI system reliable. But it makes the system's assumptions and limitations easier to examine—and gives other developers a way to improve them.

Who Is Proveniq For?

I am building it for developers, indie makers, and small teams who reuse code or creative assets and want a more disciplined way to track provenance and review license information.

A team could use it as an early screening step before incorporating an asset into a project. It could also help create a record of what was known, which evidence supported a decision, and which questions remained unanswered.

It is not a substitute for legal advice, and a generated report is not a guarantee that an asset is legally cleared. The value is in organizing the evidence and surfacing uncertainty earlier.

What's Next?

My next priorities are to:

Run and document a repeatable evaluation against live local Gemma inference.
Expand the fixture set with more license formats, missing fields, and difficult edge cases.
Improve the report so that evidence and unresolved questions are easy to audit.
Verify the deployed application and document a reproducible setup for contributors.
Get feedback from developers who regularly manage third-party code and creative assets.

I would especially like feedback on the cases where a license-screening tool should stop automatically and ask a human to decide.

Demo and Source Code

Live demo: [Add your verified public demo URL]
GitHub repository: https://github.com/priyanshuspatel/proveniq
Evaluation fixtures and test results: [Add a direct link to the evaluation documentation]
Short demo video: [Add a recording of the actual workflow]

The live demo and repository links should be filled in before publishing. I don't want to present a deployment as live until it has been verified.

Prize Categories

These are the challenge categories I would consider for Proveniq, subject to the official rules and verification that the final submission qualifies.

Best Use of Gemma : Gemma 2 2B is the open-weight model used for license-information extraction, with structured validation and evidence checks around its output.
Best Use of Render : Include this if the deployed project actually meets the challenge's Render criteria. Configuration files alone are not proof of a qualifying deployment.
Best Use of a .tech Domain : Include this only after claiming an eligible domain through the Hacktoberfest promotion, putting the project live on that domain, and linking to it here.

These are potential category entries, not a claim that the project has already qualified for every track. I will list only the categories supported by the final, verified submission.

Final Thoughts

AI is very good at making incomplete information look complete.

For a license-screening tool, that is exactly the behavior I want to guard against.

Proveniq is my attempt to build a more careful alternative: use AI to help extract information, preserve the evidence behind it, let deterministic code handle supported rules, and make uncertainty visible when the system cannot justify a conclusion.

It is still a work in progress, and the evaluation is deliberately limited. But I think that is a worthwhile place to start.

If you build software with third-party assets, what would you need to see before trusting an AI-assisted license review?

I'd love feedback on the evidence model, the edge cases, and where the tool should draw the line between automation and human review.

⏳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.