Grubora | Flutter AI Calorie Tracker App Template

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.

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

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

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

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

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

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

• 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

1. Unzip, then flutter pub get
2. flutter run — Demo mode is already on, so the app is fully populated
3. 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.