John

Posted on Apr 11

From a Calorie Counter Prompt to a Local-First Nutrition Tracker

#buildinpublic #webdev #react #opensource

One of the things I’ve been trying to do lately is take project prompts seriously enough to turn them into public, polished repositories instead of leaving them as half-finished exercises.

That’s exactly what happened with NutraFlux:
https://github.com/johnnylemonny/NutraFlux

The project was inspired by the Calorie Counter idea from the App Ideas repository, but I didn’t want to stop at “search foods and show calories.”

I wanted to push it into something that felt faster, cleaner, and more product-like.

The original idea

The original Calorie Counter prompt is already a strong one.

It focuses on:

searching foods,
showing matching results,
calorie values,
and working with structured nutritional data.

It also introduces useful technical constraints:

transforming raw food data into a format that is easier to search,
limiting results,
and thinking about performance and search strategy.

That made it a really good foundation.

What interested me most

What grabbed my attention wasn’t just the calorie tracking part.

It was the opportunity to build a nutrition tool that felt:

immediate,
search-first,
and frictionless.

A lot of apps in this space feel slower or heavier than they need to.

So instead of treating this as a basic exercise, I started asking:

What would this feel like if I designed it more like a fast, privacy-friendly product?

That question eventually led to NutraFlux.

How NutraFlux evolved

In my version, the idea became a local-first daily calorie and macro tracker built around speed, privacy, and a more refined frontend experience.

NutraFlux includes:

instant search-first logging,
wildcard food lookup,
meal categories,
calorie budgeting and progress indicators,
favorites and recently used foods,
adaptive design,
and a more polished visual system.

What I liked most about building it was that the original prompt gave me a functional core — but the product identity came from the decisions I made around it.

That’s where it stopped feeling like a challenge and started feeling like my own project.

Why I made it local-first

One of the biggest choices behind NutraFlux was making it strictly local-first.

Everything lives in the browser:

nutritional data,
settings,
and food history.

No account wall.
No cloud sync.
No user data leaving the device.

I really liked that direction because it made the product feel:

faster,
more private,
and more focused.

It also changed how I thought about UX.

When everything happens instantly and locally, the interface itself has to carry more of the experience.

That made clarity, speed, and smooth interaction much more important.

What I learned from building it

A few things really stood out while working on this project:

1. A strong prompt is a good starting point — not a limitation

The base idea gave me a clear direction, but the interesting part was deciding how far to take it beyond the original brief.

2. Product feel matters as much as base functionality

The app can technically work, but it still won’t feel complete unless the UI, feedback, and flow are treated with care.

3. Privacy can be part of the product identity

Making NutraFlux local-first wasn’t just a technical detail.

It became one of the reasons the app feels different.

4. Public repos raise the bar in a good way

Once I knew this would live publicly on GitHub, I thought more carefully about polish, structure, and presentation.

Why I like building from prompts this way

I think project prompt repositories get underestimated sometimes.

But for me, they’re useful because they remove just enough uncertainty to let me focus on what really matters:

interpretation,
technical decisions,
UX,
polish,
and project identity.

NutraFlux is a good example of that.

It started as inspiration from a calorie counter prompt.
Now it’s part of the kind of public open-source work I want to keep building more of.

DEV Community