Nutrition Guard: A Zero-Monthly-Cost Multi-Condition Dietary Risk Engine

Ever tried to plan a meal for someone who has both gout and high cholesterol? It sounds simple until you actually try it. You pull up a nutrition table, and it tells you about purines, or it tells you about saturated fat — but almost never both at once, in a way you can act on in the two seconds you have before ordering. That's the exact gap that a project called Nutrition Guard set out to fill. And here's the headline that makes it interesting for us as engineers: the entire backend runs on free tiers, and the monthly cost is zero dollars. Not "cheap." Zero.

So let's talk about what it actually is. Nutrition Guard is a dietary risk system built for four groups of chronic patients: people managing gout, high cholesterol, diabetes, and hypertension. Now, the temptation with a project like this is to reach for a fancy machine learning model. The team deliberately did the opposite. At the heart of it sits something they call a tag scoring engine — and the whole point of it is that it's explainable and auditable. Every food carries a set of risk tags for each condition, every tag has a point value, you add them up, and the total lands in one of three buckets: red, yellow, or green. That's it. No neural network deciding your dinner.

Why go multi-condition? Because that's the real pain point. It's not that a person with gout can't find a list of foods to avoid — those lists are everywhere. It's that a single meal has to satisfy several conditions simultaneously, and no static table does that math for you. So Nutrition Guard restructures the whole thing into a "food times condition times tag" data shape. You pick your conditions, and instantly you get real-time risk scores across a hundred and forty foods, tuned to your specific combination.

Let me walk you through what you can actually do with it, because the design here is thoughtful. The team split features by whether they need your data or not. Anything that's just looking something up — you can use without logging in. Searching those hundred and forty foods and seeing per-condition risk? No login. Dietary recommendations, the "avoid this, this is safe" lists? No login. Reading the knowledge center articles, browsing the twelve most common FAQs filtered by your condition? All open. That lowers the barrier to walking in the door.

Then there's the stuff that needs to remember who you are. Keeping a diet diary — logging your meals and seeing them as a seven-day bar chart — that needs login. The AI diet analysis, where the system reads your last seven days and writes you personalized advice, needs login. Exporting a PDF report with your charts and that advice baked in, one click, needs login. And saving your favorite foods so they track your current condition's risk — login again. The line is clean: look things up freely, but the moment it's *your* data, you sign in.

Now the tech stack, because this is where the "zero cost" magic lives. On the front end it's Vite, React 18, and TypeScript, styled with Tailwind, routed with React Router, and state handled by Zustand with everything persisted to local storage. The risk engine itself is pure TypeScript — a single function that takes a food's tags and a condition and hands back a risk rating. No AI anywhere in that path. It's just arithmetic you can read and trust.

The backend is a single Cloudflare Worker serving the food API, with the data — those hundred and forty foods — living in Cloudflare D1, which is essentially SQLite at the edge. The *only* place they call an actual language model is the personalized recommendation, where they hand off to Cloudflare Workers AI running Llama 3.1. PDFs get generated right in the browser, lazy-loaded, embedding a Noto Sans font so Chinese characters render correctly. Login runs through Firebase Auth with Google sign-in, and your personal data — diary, favorites, custom articles — sits in Firestore. The whole site is hosted on Cloudflare Pages.

One nice practical footnote for anyone building on this: the Workers AI binding only runs in Cloudflare's actual edge environment. So if you're developing that analyze endpoint locally, a plain local dev server won't cut it — you have to run wrangler in remote mode to get it talking to the real AI.

Let me describe the overall flow, since there's no picture to look at. The user hits the React app on Cloudflare Pages. From there, three things branch out. Google sign-in goes to Firebase Auth. Anything personal — diary, favorites, articles — reads and writes to Firestore. And food lookups plus AI analysis go to the Cloudflare Worker. The Worker, in turn, reads from D1 for the food data, and when a request comes in for analysis, it reaches over to Workers AI. Clean separation: Firebase holds *you*, Cloudflare holds the *knowledge*.

Now, the core of the whole thing — the scoring — deserves a closer look, because the design philosophy is the real lesson here. The top priority was explainability. No black box. Every risk factor is spelled out as a tag with a score. In the database it's two simple tables. One table is just the foods: an id, the name, and a category — meat, seafood, vegetable, fruit, drink, grain, dairy, other. The second table maps each food to its risk tags, and crucially, each tag is stamped with which condition it applies to.

The scoring is severity-weighted, and once you hear a few examples it clicks. For gout, the heavy hitters — high purine, organ meat, alcohol — are three points each. High-risk seafood is two. Moderate purine is just one. For high cholesterol, trans fat and high saturated fat are three points apiece. For diabetes, high sugar, refined carbs, and sweetened drinks — three each. For hypertension, high sodium is three, while processed, canned, and pickled foods are two each. When you query a food for your condition, the engine grabs the matching tags, sums the points, and grades it: four or more is red, high risk; two or three is yellow, medium; below two is green, low. And if you're logged in, that result feeds forward — into your diary, into the seven-day chart, into the AI advice, and finally into the exportable PDF.

Here's why that structure is genuinely better than a slick model. When the app tells you a food is high risk, it can show you *exactly which tags* triggered it — "this scored red because it's high purine and it's an organ meat" — instead of shrugging at you with a confidence percentage. And maintenance is trivial. Want to add a food or retune a score? You edit a seed file and the tag values. No retraining, no pipeline, no GPU bill.

Quick word on permissions, because they got this right too. Firestore's security rules draw two lines. First: public read, but login to write — anyone can read a knowledge article, but only signed-in users can create one, and only the author can edit or delete it. Second: your private data is locked to you. The diary and favorites under your user id can only be read and written when the requester's authenticated id matches. Nobody's browsing your meals.

And the cost story ties it all together. Deployment is the classic full-Cloudflare bundle: spin up D1, load the schema and the hundred and forty foods, deploy the Worker, and point Cloudflare Pages at your GitHub repo for automatic builds. On the Firebase side, just switch on Google login and Firestore and apply those rules. Because D1, Workers, Workers AI, Pages, and Firebase all live comfortably inside their free tiers, the total operating cost stays at zero — and honestly, that constraint was the compass for every technical choice in the project.

So what do I want you to take away from this one?

First and biggest: whatever you can solve with rules, don't hand to a model. The risk scoring — the part that has to be trusted and explained — is a plain tag-summing function. The model only shows up for the one job that genuinely needs natural language: writing a paragraph of advice from your week of records. That's the discipline. Reach for AI where AI earns its keep, and nowhere else.

Second: explainability isn't a nice-to-have here, it's the feature. Because scoring is transparent tags and points, users see *why* something is risky, and the team can extend the system by editing a file instead of retraining anything. Trust and maintainability, from the same design decision.

And third: this whole thing — lookup, logging, analysis, PDF reports — runs at zero monthly cost. That's not an accident, it's an architecture. When you treat "free tier only" as a real constraint from day one, it quietly pushes you toward simpler, more explainable, more maintainable choices. Sometimes the cheapest system is also the clearest one. That's the trick worth stealing.