Grubora — Flutter AI calorie tracker app template: the model names the food, the phone does the math

Grubora is a complete AI calorie tracker app template built with Flutter, GetX and Material 3. Photograph a meal and a vision model names what is on the plate; every calorie and every macro after that is computed on the device from a USDA food table bundled with the app. 14 screens, light and dark, and every one of them runs with no API key, no account and no network.

Demo Instructions — the sign-in screen is a mock and contacts no server, so any credentials are accepted. Use demo@grubora.app / demo1234, or simply tap Sign in with both fields left empty. There is nothing to register, no API key to enter and no network required: Demo mode ships switched on, so the photograph pipeline, the diary, the insights and the fasting window all answer on the device against the bundled food table.

What’s in the package

Full Flutter source — 14 screens, light and dark, GetX architecture (View → Controller → Service → Model)
A local nutrition engine in plain Dart: 1,200 USDA foods, the Mifflin-St Jeor target derivation, and the fasting window, all offline
Three AI providers as plain REST clients — Google Gemini (default), OpenAI, Anthropic Claude — bring-your-own-key, no vendor SDKs
Demo mode, on out of the box: every screen populated, every signature interaction working, with no key at all
Offline HTML documentation — every screen, a feature walkthrough with two animated GIFs, provider setup, connecting your own storage, renaming, re-theming, project structure, a terminal glossary and troubleshooting
Five runtime dependencies in total, and zero image assets — every illustration in the UI is painted at run time

Who is this for

Developers shipping a calorie or nutrition app who want the hard parts already decided: where the numbers come from, what the model is and is not asked for, and what happens when a food is not in the table. If you have shipped in this category before, you know the reviews are never about the UI — they are about whether the thing ran. This one runs on flutter run.

No backend. No Firebase. Runs out of the box.

No backend, no Firebase: nothing to deploy, five dependencies, and Demo mode on out of the box

Nothing is proxied through a server of ours, because there is no server. Every provider is bring-your-own-key, and the only network calls this app can make are the ones your user’s own key pays for. The diary lives behind a service layer whose methods already return Futures, so pointing it at Hive, Isar, SQLite or your own API is a change in one file and no screen changes.

Photograph the plate

Camera, gallery or a barcode goes in; one structured answer comes back with names and grams only

The model is never asked for a number. It is asked for one thing only: the name of each food and how many grams of it are there. The reply schema has no field for a calorie count, so a figure cannot reach the diary even if a future model volunteers one. A language model guessing at arithmetic is the failure mode of every app in this category — published error ranges are wide in both directions, have no source, and cannot be added up over a week and mean anything.

Every figure is computed on the device

1,200 offline USDA foods, four confidence grades, and totals that follow when a portion is corrected

Names are matched against 1,200 foods from USDA FoodData Central (SR Legacy, release 2018-04), packed into the app and read with no connection at all — energy, protein, carbohydrate, fat, fiber, sugar and sodium per 100 g, plus the household measures the source gives (“1 medium”, “1 cup, sliced”). Every row carries a confidence mark and an editable portion in grams; the running total moves as you change one, because a photograph cannot tell anyone how much oil was in the pan. Public domain data, credited in Settings with the release named.

When a food is not in the table, the app says so. It does not quietly substitute the nearest thing it does have — that hands the user a believable number for a different food with no way to ever find out. An unmatched row shows no figures, is not saved, and offers the search instead.

A day, as a ledger

The home screen: what is left rather than what is spent, a beaker against the target, and meals as sections

What is left, not what is spent. The budget is a measuring beaker with the target marked below the rim, so going over is legible as liquid above a line rather than as a progress ring you have somehow “completed”. Below it, the day in meal sections that each carry their own subtotal, with the eating window and the day’s water on the same page as the food. Nothing on this screen leaves the device.

One point, not three bars

The macro triangle: a day is one point, the week is a scatter, and the target split is a shaded region

Three shares that always sum to one have two degrees of freedom, so they fit on a plane exactly. A day is a point inside a triangle, where the distance from each corner is that macro’s share; the week is a scatter you can see the spread of; your target is a region you are either inside or not. Seven stacked bar charts cannot show consistency — this can, and a week drifting toward one corner is visible before any single day is.

An eating window, not a stopwatch

Intermittent fasting as a sash window: 16:8, 18:6, 20:4 and OMAD, with nothing to start or stop

Intermittent fasting drawn as a sash window: two panes in proportion, the boundary marked, the clock times beside it. There is nothing to start and nothing to forget to stop — the window is a property of the clock, so close the app, restart the phone or come back in three days and it is still whatever the time says it is. 16:8, 18:6, 20:4 and OMAD are all one setting.

Three AI providers, or none at all

Google Gemini — the shipped default. A key is free and needs no credit card, so your users are never sent to a billing form, and it does both jobs: it reads photographs and it writes text
OpenAI and Anthropic Claude
Demo mode — the pipeline runs end to end on the device against the bundled food table, so every screen is populated with no key and no network. Not a folder of canned screenshots

Every provider is a plain REST client behind a one-method interface that knows nothing about food, which is why the same three adapters serve both of this app’s very different requests. Adding a fourth is one class and one catalog entry, with no screen changes. Model names expire, and this template is built for that: the model id is an editable setting, a retired name produces a plain-language error with a button straight to the field that fixes it, and the documentation has a section on updating it.

14 screens, light and dark

Food search, the target derivation, and Today and the meal log in the dark theme

Beyond the four signature screens: a searchable 1,200-food table with household portions; a food’s own page with its full USDA description and live per-portion figures; barcode lookup against Open Food Facts (free, no key); a targets page that shows the whole derivation rather than just its result; onboarding; sign-in; provider settings; and a mock paywall. Every one of them themed twice. Macro targets are derived from the energy share rather than a weight share — the single most common arithmetic error in this category.

What you get

What you get: 14 screens, 3 providers, 1,200 offline foods, 5 dependencies, and nothing to deploy

Full Flutter source, GetX, analyzer clean — 109 tests pass, including the Mifflin-St Jeor arithmetic against hand-worked cases, the food matcher against the real bundled table, the fasting window across midnight, and the per-vendor schema transforms
API keys stored in the Keychain on iOS and EncryptedSharedPreferences on Android — never in plain preferences
All demo data in one file: a 14-day diary with realistic gaps in it, built by running the real engine over the real food table
Zero image assets — the beaker, the macro triangle, the sash window, the onboarding plates and the app mark are all painted at run time, so there is no artwork to license and nothing to keep in sync. Meals your users photograph are shown as photographs
Typefaces are bundled, not downloaded — the UI renders identically offline and on a cold first launch
A distinctive kitchen-ledger design system: deep cocoa on an oat ground with a single cranberry accent, Red Hat Display + Golos Text, and a plate-card shape with a second hairline just inside the border. Every quantity is set in Spline Sans Mono so a column of figures lines up. Every token is centralized, so the whole app re-skins from one color file

Get it running in five minutes

Unzip, then flutter pub get
flutter run — Demo mode is already on, so the app is fully populated
Optional: paste a provider key in Settings to run the photograph pipeline against a live model

Requirements

To run and build the source code you need the Flutter SDK (version 3.29 or newer) and Dart 3.7 or newer, together with a Flutter-ready IDE — Android Studio or Visual Studio Code with the Flutter & Dart plugins. Runs on both Android and iOS from a single Flutter codebase (Material 3, null-safe).

Third-party costs and honest limits

Grubora runs entirely on the device, but the two AI features — naming the foods in a photograph, and writing up a week — are produced by a third-party AI provider that you or your users supply a key for. Connecting it to a live provider such as Google Gemini, OpenAI or Anthropic will involve those third-party services, which will incur their own separate costs and are not included in this item. Barcode lookups query Open Food Facts, a free public database that needs no key or account. Nutrition figures are estimates drawn from reference data, not measurements of the food in front of you.

What is not included

No backend and no account system. Sign-in is a mock that contacts no server — the seam is drawn where your API call goes, and the documentation walks through it
The diary is held in memory. It is seeded with sample data and resets when the app restarts; wiring a persistent store is a documented one-file change and is left to you. The only thing written to disk is the user’s API key
Barcodes are typed or pasted, not scanned. Camera barcode scanning is not included; the documentation shows how to add a scanner package on top
No Apple Health or Google Fit integration, and no image generation of any kind
The subscription screen is a mock — no payment code, receipt validation or store product is included
No push or local notifications / reminders — nothing in the package schedules anything
No AI provider key or credit is included, and no web or desktop build is shipped or supported

Health disclaimer

Grubora is a logging tool. It is not a substitute for professional medical advice, diagnosis, or treatment, and it does not provide clinical guidance. The app applies a floor to the daily calorie target it will set.

Support and updates

Questions about the item go through the comments tab on this page, which is where I read them. Support covers the code as it ships: getting the project to build, the documented setup steps, provider configuration, and defects in what is included. It does not cover your own modifications, third-party provider outages or pricing changes, or building new features to order.

Changelog

v1.0 — initial release.

Grubora | Flutter AI Calorie Tracker App Template