Product Scanner Apps: Where Eco Scores and Carbon Numbers Actually Come From

Point a camera at a jar of pasta sauce and get back an eco score, a carbon estimate, a note on the packaging and a suggestion for something better on the same shelf. It is one of the most satisfying two-second interactions in consumer software, and it is also the one where the gap between what the screen says and what is actually known is widest. Every number in that result was computed by someone. The interesting engineering question is not how to read the barcode — that is close to free — it is what you are entitled to say once you have.

TL;DR:

  • There are two identification routes — barcode lookup and vision — and they fail in opposite directions. Serious apps run both.
  • No authority publishes an eco score per product. Every score on the market is a formula somebody wrote, which makes it an editorial position with a number attached.
  • Carbon figures are category estimates scaled by weight, not measurements. Saying so is a feature, not a weakness.
  • Open Food Facts removes the cold-start problem for packaged groceries at no cost, so the database is not the reason not to build.
  • Scanning is occasional. Receipts and a weekly impact summary are what make the app worth keeping installed.

Table of Contents

Two Ways to Identify a Product

There are exactly two ways to turn a thing on a shelf into a record in your app, and choosing between them is really choosing which failure you prefer.

Barcode lookup. The camera reads the EAN-13 or UPC — on iOS this is a single Vision request, on-device, offline, effectively instant — and the number becomes a database query. When the product is in the database the answer is exact: this brand, this size, these ingredients. When it is not, you get nothing, and nothing is a bad screen to show someone standing in a supermarket.

Vision identification. The camera photographs the product and its packaging and a model infers what it is. This never returns nothing, which is its appeal and its problem: it is confident on a product it has never seen, and it will describe a regional own-brand cereal as a plausible generic cereal rather than admitting it does not know. It also handles the cases barcodes cannot — loose produce, a bunch of carrots, a cosmetic sold in a market whose codes nobody has catalogued.

The combination is what works. Read the barcode first; if it resolves, that is the trusted path and the app should say so. If it does not, fall through to vision and label the result as an inference rather than a lookup. The distinction costs one line of interface and buys the only thing that matters in this category, which is that the user knows how much to believe.

Pro Tip: Design the miss before you optimise the hit. A scanner that says "not in the database — here is what we can tell from the packaging" is a working product; one that shows a spinner and then an error is a deleted one.

Where the Score Comes From

There is no authority that publishes a sustainability score per product. Every app showing one has written its own formula, which means the score is an editorial decision presented as arithmetic.

The inputs are real enough; it is the weighting that is invented. A typical formula draws on some combination of the following, and the second column is where each one actually comes from.

InputSourceHow reliable
Ingredients and additivesOpen Food Facts, product label OCRHigh for packaged food in large markets
Processing levelDerived from the ingredient listReproducible, but the thresholds are a judgement
Packaging materialDatabase field, or inferred from the photographPatchy — often missing, often guessed
Origin and transportLabel, database country fieldFrequently absent; "packed in" is not "grown in"
Category emissions factorPublished life-cycle assessment datasetsGood at category level, meaningless at brand level

Two consequences follow. The first is that the apps users trust are the ones that show the components rather than only the total — a score you cannot open up is indistinguishable from one that was guessed, and the category has enough bad actors that users are right to suspect it. The second is that the formula is the product. It is the part a competitor cannot copy from a screenshot, and the part worth iterating on long after the scanning pipeline is finished.

The Carbon Number Is an Estimate

A genuine product carbon footprint requires a life-cycle assessment of one specific supply chain, and almost no consumer product publishes one.

What an app can honestly do is map the identified product to a category with a published emissions factor and scale it by weight. That is enough to rank a beef product above a chicken one and a chicken one above lentils, which is the comparison users are actually making. It is not enough to state a precise figure for one brand versus another brand of the same thing, and an app that does so is asserting a precision it does not have.

The good news is that admitting this improves the product. "Around 2.5 kg CO₂e, based on the category average for beef, scaled to this pack size" is more useful than a bare number, because it tells the reader what would change the answer. It is also considerably more defensible, which matters more every year.

Receipts Are the Underrated Input

Scanning a single product is a decision-support moment. Scanning a receipt is a measurement moment, and it is the one that produces a number worth returning for.

A photographed receipt is a list of twenty or thirty line items in a compressed retailer shorthand. Resolving those abbreviations to products is genuinely hard — it is closer to fuzzy matching against a retailer's own catalogue than to reading a barcode — but the payoff is that one photograph does what thirty individual scans would, and it happens at the moment the shopping is already done rather than in the middle of it.

It also changes what the app can say. Per-product scanning answers "is this one good". Receipt analysis answers "what did this week actually cost, and which two swaps would change it most", which is both a better question and one the user cannot answer any other way.

What Happens When the Scan Misses

In this category the failure path is the product, because it fires constantly.

Open product databases skew heavily towards packaged groceries in western European markets. Move to a different country, a different retailer's own label, cosmetics, household chemicals or anything sold loose, and the miss rate climbs fast. An app whose entire design assumes a hit will feel broken to most of the world.

Three behaviours make the miss survivable. Degrade rather than fail — if the barcode is unknown but the packaging is photographed, say what can be said from the packaging. Ask for one thing, not five — a single "what is this?" field turns a dead end into a contribution. And show the scan history regardless, so a session with two misses still ends with something on screen.

The Weekly Loop

Scanning is situational: it happens in a shop, a handful of times a month, and a pure scanner is opened three times and deleted in the second month.

What survives is the summary. A weekly figure — what was scanned, what it added up to, what moved compared with last week — works because it arrives without the user doing anything and because it is the only screen in the app that shows progress rather than judgement. Alongside it, a short list of concrete swaps outperforms any amount of educational content, because it is actionable at the next shop rather than interesting in the abstract.

The failure mode to avoid is the guilt loop. Sustainability apps that score the person rather than the product get uninstalled after the first bad week, and the mechanic that causes it — a running total that only ever goes the wrong way — is easy to build by accident.

What You Are Allowed to Claim

Environmental claims in consumer software are moving from a marketing question to a regulatory one.

The EU has been tightening the rules on how environmental claims may be made and substantiated — the green claims work under the Commission is the thread to follow — and the direction of travel is consistent: a claim needs evidence proportionate to how specific it is. An app that says "this category is typically high-emission" is on solid ground. An app that says "this product emits 1.8 kg CO₂e" needs to be able to show where that came from.

Apple's App Review Guidelines add the second constraint, on the same principle that governs health apps: an app presenting data as authoritative is expected to be able to back it. The practical translation for this category is short. Say what the number is. Say what it is derived from. Never round an estimate into a fact.

How Product Scanners Make Money

  • Subscription — unlimited scans, receipt analysis and history. Best fit: inference costs are per-use and the value is ongoing, so the two models line up.
  • Affiliate — links to greener alternatives. Pays well where it works, but needs regional inventory, and a recommendation the reader cannot buy locally is worse than no recommendation.
  • One-off unlock — pay once for the full tool. Suits the app's character and caps revenue per user, while leaving recurring model costs unfunded.
  • Advertising — the weakest fit by some distance. Trust is the entire product here, and a sponsored eco recommendation is the fastest way to lose it.

Build or Buy

Built new, a product scanner of this shape is a few months of work: the dual identification pipeline and its fallbacks, the scoring formula and the data plumbing behind it, receipt parsing, the history and summary surfaces, a subscription, and an App Store submission. Commissioning it lands in the tens of thousands of euros, and — as with the wine and file-transfer categories — the time goes into the unglamorous parts: making a miss produce something useful, and making a formula that survives being argued with.

Buying one already published skips the submission and, more usefully, skips the months of tuning that decide whether the output reads as informed or as invented. Our cost calculator prices the new-build route.

A Finished One, as a Worked Example

The decisions above describe EcoScan AI : Product Scanner, a React Native app in our catalogue.

It takes the vision-first route: point the camera at a product and the model identifies the item and its packaging, then returns an eco score, a CO₂ estimate and a sustainability read on what it found. Receipt analysis is a first-class surface rather than an afterthought — photograph a receipt and it processes the basket as a whole, which is the measurement moment this article argues for.

The retention layer is the one described above: impact tracked over time rather than per scan, so the app has something to show on a week when nothing was scanned, and alternatives suggested in the context of what the person actually bought.

The sale includes the full source and the App Store listing transfer, so the reviews and ranking history move with it. The panel below reads the catalogue row directly, so the price and availability there are current.

Sources

FAQ

How does a product scanner app identify a product?

Two routes, and they fail differently. Barcode lookup reads the EAN or UPC and queries a product database, which is exact when the code is there and returns nothing at all when it is not. Vision identification photographs the product and packaging and infers what it is, which always returns something but is confident rather than certain. Barcode wins on packaged groceries in large markets. Vision wins on loose produce, unlisted regional products, cosmetics and anything whose barcode is not in any open database. Most serious apps run both and treat the barcode as the trusted path.

Where do the eco scores in product scanner apps come from?

They are computed, not looked up. There is no authority publishing a single sustainability score per product, so every app that shows one has written its own formula over whatever inputs it can get: ingredients, packaging material, processing level, origin and transport distance. That means the score is an editorial position with a number attached. The apps users trust are the ones that show the components behind the score rather than only the total, because a score you cannot interrogate is indistinguishable from one that was guessed.

Are the carbon numbers in product scanner apps accurate?

They are estimates, and the honest ones say so. A real product carbon footprint requires a life-cycle assessment of that specific supply chain, which almost no consumer product publishes. What an app can do is map the product to a category with a published emissions factor and scale it by weight — accurate enough to rank a beef product above a lentil one, not accurate enough to claim a precise figure for one brand. Presenting an estimate as a measurement is both misleading and, under tightening EU rules on environmental claims, a growing legal risk.

Do you need a product database to build a product scanner app?

Not to start, and assuming you do is what stops most of these apps from being built. Open Food Facts is a free, openly licensed database of millions of packaged food products with ingredients, packaging and nutrition data, and it covers the barcode path for groceries at no cost. What it does not cover — cosmetics in some markets, regional products, anything unpackaged — is exactly where a vision model earns its place. The combination is available to a small team now; building a proprietary catalogue is not.

How do product scanner apps make money?

Four routes, in rough order of how well they suit a small app. A subscription for unlimited scans and history fits best, because the model costs are per-use and the value is ongoing. Affiliate links to greener alternatives pay well but need regional stock to be useful, and a recommendation the user cannot buy locally is worse than none. A one-off unlock suits a reference tool but leaves recurring inference costs unfunded. Advertising is the weakest fit: the audience is small, the trust is the product, and a sponsored eco recommendation destroys it.