Food Scanner

Nutrition labels contain valuable information, but their dense tables, unfamiliar terminology and serving-size assumptions make comparisons difficult in the few seconds people spend choosing a product. The core problem was not access to data. It was translating that data into an answer a shopper could understand without becoming a nutrition specialist.

The primary audience is people who want to make more informed food choices while shopping: families comparing similar products, people tracking ingredients or nutritional values, and curious consumers who need a quick explanation. That made speed, plain language and responsible framing more important than adding every possible analytical feature.

The interaction begins with a photo of the ingredient list. OCR extracts what is printed on the current package, then the app moves to a structured product view with decision-relevant information before deeper detail. This avoids depending on a barcode record that may lag behind a manufacturer's changed recipe.

The product uses layered disclosure. A concise analysis supports the immediate choice, while detailed nutritional information remains available for users who want to inspect it. AI-assisted explanations add context, but the interface keeps source values visible so that a generated interpretation never replaces the underlying facts.

The product was treated as a repeated-use utility, not a one-time report. The cross-platform app is built with Flutter, while a hybrid backend combines Spring Boot and Java with Firebase services and different storage systems selected for different features. Local storage and later synchronisation preserve useful behaviour in shops with weak connectivity.

Three decisions kept the experience focused and maintainable:

• Use OCR on the package itself rather than trusting a barcode database that would need constant recipe updates.
• Keep key data available locally and synchronise it later so a weak supermarket connection does not block the core task.
• Separate factual values from interpretive guidance and reveal deeper detail progressively.

Food data is imperfect: packaging changes, serving sizes differ and databases can contain gaps. A polished interface cannot pretend those limitations do not exist. The product therefore has to communicate uncertainty, handle incomplete records gracefully and avoid turning a convenient score into medical advice.

Growth also changes engineering priorities. Features that feel inexpensive at a small scale can become costly when hundreds of thousands of people scan products. Performance, operating cost and support burden must be considered together. The practical trade-off is to invest first in flows users repeat and to validate optional complexity against real behaviour.

Food Scanner passed 300,000 installs while maintaining a 4.8 store rating. Those numbers show both reach and sustained user satisfaction: acquisition alone would not produce a strong rating if the scan-to-answer loop were confusing or unreliable.

The product also became a public reference point for accessible nutrition technology. It was presented on PRO TV's ILikeIT, Euronews Romania and PRO TV's Doctor de Bine. The coverage provided independent, on-camera proof of the product and helped explain the value to audiences beyond the app stores.