FoodPal

Why FoodPal exists

Most fitness and nutrition apps are not really software — they are data-collection pipelines wearing a friendly UI. Log a meal, train a profile. Hit a macro, feed a recommendation engine. The app is free because your habits are the product, and the bill comes due later in targeted ads, insurance segmentation, or simply the slow erosion of having no say over what is known about you.

FoodPal starts from the opposite premise: a nutrition tracker should know about food, not about you. It should run on the phone in your pocket, answer to you alone, and stop the moment you close it. No account, no cloud, no second server somewhere deciding what your data is worth this quarter.

On-device by default

Every macro you log, every meal you build, every goal you set lives in a Room database on the device you are holding. There is no sync server we operate, no analytics pipeline, no "anonymous" telemetry stream phoning home in the background. Uninstall the app and the data is gone — not because we deleted it, but because it was never anywhere else.

That choice shapes the rest of the architecture. Offline-first is not a feature we bolted on; it is the only mode the app has. Search hits a hosted mirror of Open Food Facts when the network is up, and falls back to the foods you have already saved when it is not. The dashboard reads from the same local store in either case, so the numbers you see never depend on a round trip to someone else's server.

No Google proprietary libraries

FoodPal runs on Android, but it does not depend on the parts of Android that Google uses to tie the platform back to its own services. No Firebase, no Play Services dependencies, no AdMob, no cloud messaging. The result is an app that runs cleanly on GrapheneOS and LineageOS — operating systems built for people who want a phone that does not report back to its maker — without sacrificing anything a nutrition tracker actually needs.

This is also a constraint we chose to keep, not a phase we will grow out of. It would be easy, the moment sync or a team feature is asked for, to reach for the standard vendor SDKs and ship faster. We would rather build the slower, honest version than become another tracker with a privacy policy nobody reads.

Built on open data

Nutrient lookup draws on Open Food Facts — a community-maintained, openly-licensed database of food products from around the world. When you scan or search for an item, the answer is not coming from a proprietary catalog we lock behind an API key; it is coming from a corpus anyone can read, audit, correct, and fork. The hosted mirror we run is just a copy made fast enough to be useful on a phone, not a source of control over what you are allowed to look up.

If a food is missing — your local bakery's loaf, a family recipe, the protein bar a small maker sells at a market — FoodPal lets you build it as a custom food, with as much or as little macro and micronutrient detail as you have, and it sits alongside the open catalog entries in your logs from then on.

Open source, always

The source is on GitHub under an open licence. You can read it, audit it, build it yourself, and run your own derivative if you want something we do not. If FoodPal disappears tomorrow, the version on your device keeps working, because the only thing it talks to is a mirror of a database that is itself public.

We ship in the open as well. The development lifecycle above is accurate today and tracks where the project actually is — not a marketing state. When it moves to beta, the bar moves with it.