Offline allergen scanner for grocery labels

The idea

A phone app you point at a grocery item's ingredient panel. It runs on-device text recognition to pull the ingredient list, checks it against a personal allergen/avoid-list you set up once (peanuts, gluten, dairy, whatever), and shows a clear pass/flag result with the matched words highlighted in the raw text. No barcode database, no server call, no signup — the whole loop runs offline in under a second.

Why build this

People managing food allergies or intolerances currently rely on apps that need a barcode match against a cloud product database, which fails constantly on store-brand items, imports, or anything not in the catalog — and it fails hardest exactly where it matters, in the cellular dead zone of a supermarket basement. On-device OCR (Apple's Vision framework, Google's ML Kit Text Recognition) is now accurate enough on small, curved label text to make a pure client-side reader viable, and doing it that way is also a real feature, not just a technical flex: nobody wants a corporation logging every ingredient list they scan, especially parents scanning for a kid's allergy or people managing a medical diet. There's no dependency on someone else's database being complete or current.

Stack sketch

• Client: Flutter, single codebase for iOS and Android, camera preview via camera package
• OCR: google_mlkit_text_recognition on Android, native Vision framework bridge on iOS — both run fully offline after model download
• Matching: a small local rules engine — normalize OCR'd text (lowercase, strip punctuation, handle line-wrap hyphenation), then substring/fuzzy match against the user's allergen list plus a bundled synonym table (e.g. "casein" and "whey" both flag under "dairy")
• Storage: SQLite via sqflite for the user's allergen list and scan history — everything stays local, nothing synced by default
• Synonym/allergen data: seed from a curated, static JSON built from public allergen-labeling regulation lists (FDA's Big 9, EU's 14) rather than any live API

Scope for v1

• In: camera scan → OCR → normalize → match against user-defined allergen list → highlighted result screen with a plain pass/flag verdict
• In: onboarding flow to build the allergen list from a checklist of common allergens plus free-text custom entries
• In: local scan history so a user can re-check a product they scanned last week without rescanning
• Out: barcode lookup or any product database, cloud sync or accounts, multi-language ingredient text (English-only labels for v1), nutrition or scoring beyond binary flag/no-flag

Where it could go

Once the OCR-and-match loop is solid, barcode scanning becomes a nice speed layer for repeat purchases — cache a barcode-to-ingredients mapping locally the first time a user scans a product, so the second time is instant with no camera-to-text step at all. A restaurant-menu mode is a natural extension too, since the same OCR-and-flag pipeline works on a photographed menu, just with looser text structure to parse. Further out, an opt-in, anonymized way for users to contribute corrections to the synonym table (e.g. flagging a missed allergen alias) would improve matching quality without ever centralizing the scans themselves.

Watch out for

The core risk is a false negative: OCR misreads a word and the allergen slips through unflagged, which is a real safety issue for someone with a severe allergy, not just an inconvenience. The UI needs to treat low-confidence OCR output as "couldn't verify" rather than a silent pass, and the app should carry a persistent disclaimer that it's a reading aid, not a substitute for checking the full label yourself.