In-Store Product Locator Powered by Shelf-Scanning Robots
A major Chilean supermarket chain ran autonomous robots that roamed the aisles at night scanning shelf labels. I built the system that turned those scans into something a person could use: search any product and see exactly which aisle and shelf position it was in, store by store, from a phone on the sales floor.
Role: Sole designer and builder
The problem
"Where is this product?" is the most-asked question in a supermarket, and during the e-commerce surge it became an operational bottleneck: pickers walking the aisles to assemble online orders spent a large share of their time just finding things. The chain had already deployed shelf-scanning robots, so the location data existed. It just lived inside the robot vendor's platform, where nobody on the floor could reach it.
What I built
flowchart LR R["Shelf-scanning robots
nightly aisle scans"] --> Z["Robot vendor API
token auth, per store"] Z --> ETL["Sync jobs
per-store ingestion"] ETL --> DB[("PostgreSQL
16 store tables")] SAP["SAP item master"] --> ENR["Catalog enrichment"] VTEX["VTEX e-commerce catalog
names · brands · images"] --> ENR ENR --> DB DB --> UI["Responsive locator
aisle + shelf coordinates"]
Robot scans flow in per store; SAP and VTEX data turn barcodes into recognizable products; the floor gets a searchable locator.
- Robot data ingestion: authenticated sync against the robot vendor's API (Zippedi), pulling each store's shelf-label scans: EAN, aisle, x/y/z shelf coordinates, orientation, and last-time-seen, into per-store PostgreSQL tables covering 16 stores.
- Catalog enrichment: a raw shelf scan only knows the barcode. An enrichment pipeline cross-referenced each EAN against the SAP item master and the VTEX e-commerce catalog to attach real product names, brands, and images, with accent normalization so Chilean product names matched reliably.
- The locator: a responsive, searchable view per store. Type a product, get its aisle and shelf position and when a robot last saw it. Built mobile-first because the people who needed it were standing in an aisle, not at a desk: e-commerce pickers assembling online orders, store staff answering "where is…?", and in some stores customers themselves.
- Freshness handling: "last time seen" was displayed rather than hidden, because a location a robot confirmed last night is trustworthy and one from last month is a lead, and the people using it deserved to know the difference.
Try it
I recreated the experience as an interactive demo with fictional data: search a product, open it, and see its aisle, shelf position, robot-freshness, and the highlighted store map. This is the flow as pickers and staff used it, on a phone, mid-aisle.
Why it mattered
This was part of the same operations suite as the order-fulfillment dashboard and the product search system: three tools that together gave the e-commerce operation visibility it didn't have. The locator attacked the physical half of picking time, the walking and searching, by reusing data the company was already paying robots to collect. No new hardware, no new process: just connecting an existing data source to the people who needed it.