Building a product catalog from barcodes

The problem

A distributor with three thousand products isn't going to type them in one by one. And if adding a product is tedious, the catalog stays empty and the agent has nothing to sell. The goal was for a shop owner to point a phone at the barcode: scan, and the product appears with a name, an official photo, ready to sell.

Constraints

• 01A barcode is a lookup key, not a product. The number identifies the item; the details have to come from somewhere.
• 02The public data is dirty. GTIN databases have wrong names, missing photos and duplicates. Usable, but not the way it arrives.
• 03Fast enough to feel like magic. If a scan takes ten seconds and might still fail, people go back to typing.
• 04Fill the gap ahead of demand. The item a shop scans should already be known, not fetched cold while they wait.

Architecture

Drinks and packaged food are standard products. A Coca-Cola is the same barcode nationwide, and that's why the idea works: the details are worth fetching once and reusing everywhere. What one shop scans and cleans becomes a ready template for the next, so the catalog gets richer with every store instead of starting from zero each time.

The hard part

The problem is that the public data lies just enough to be dangerous. A GTIN lookup returns an abbreviated name, a photo of the wrong flavour, a weight buried in the middle of the title. Trust it blindly and the catalog fills with subtly wrong products; reject it and people go back to typing everything by hand.

The answer was to treat the lookup as a draft: fetch, normalize, and let what one shop confirms become the clean version the next one inherits. A background crawler warms the catalog ahead of demand, so the common items are already known and already cleaned when someone scans. The magic moment, scan and done, is bought with a lot of unglamorous normalization happening before anyone scans anything.

Trade-offs

• Depending on a public GTIN database means depending on someone else's data quality. Normalizing and asking for confirmation is the price of using a source you can't trust.
• A crawler that warms the catalog spends requests and storage on items nobody may ever scan. Worth it: the alternative is a cold, slow, failable lookup at the exact moment the user is deciding whether to trust the feature.
• Barcode-first is perfect for standardised goods and useless for bespoke ones. A distributor of branded products is the sweet spot, a custom service business isn't, and the product is honest about which of the two it serves.

What I'd do differently

I'd make the shared catalog explicitly collaborative. Today each shop benefits from what the others cleaned as a side effect. I'd make that a first-class idea: a confirmed, photographed, correctly-weighed product is a public good every store draws from, and the crawler plus the shops together would keep one clean national catalog instead of ten thousand private near-duplicates.