Teaching a Catalog to See
A used-equipment catalog stuck at 5,000 items, a company going public, and one to two million photos nobody was using.
- My role
- Conceived it, directed the technical design, owned the testing and the definition of "good enough to publish."
- Where
- The used-equipment marketplace of a Nasdaq-listed construction technology company.
- When
- Built and scaled while the company was going public, alongside the digital rental channel.
- Stack
- Amazon Rekognition Custom Labels, trained on 1 to 2 million equipment photos.
- Measured by
- A precision and recall evaluation framework I defined, applied at scale before anything went live.
- Outcome
- 5,000 to 100,000 listings, 20 images each, in production.
The company had a used-equipment business that could only sell what someone had hand-cataloged, and hand-cataloging is slow. Five thousand listings online. Tens of thousands of machines in the yard. Every one photographed, none of the photos doing any work. Meanwhile the company was heading toward going public, and the used business needed to look online like what it actually was in the yard.
Not "hire more people to catalog." Not "buy a vendor's tool." Train a model on the photos we already had. I conceived it, directed the technical design, and owned the testing: image recognition on Amazon Rekognition Custom Labels, trained on one to two million equipment photos, so a machine could be identified and listed from a picture instead of a form.
A pipeline that read the photos, recognized the equipment, and pushed it into the online catalog. The catalog grew from 5,000 manually managed, barely trafficked listings to 100,000 items with 20 images each. Alongside it, a second model read live data off the machines and flagged one drifting out of its normal range before it broke down: the same idea, pointed at uptime instead of inventory.
A model that's right most of the time still publishes wrong listings at scale, and on a used-equipment marketplace a wrong listing is a real person driving to a yard for a machine that isn't what the photo said. So before the pipeline touched a single listing, I wrote down what right had to mean: the performance criteria the model had to clear, and the precision and recall framework we'd measure it against, at the volume it would actually run.
Then we tested it until the numbers were true, fixed the process around the model wherever the process was the actual problem, and only then let it publish. That order, process first and the model on what's left, is the one I've used on every applied-AI build since.
The AI wasn't the hard part. The hard part was deciding what "good enough to publish" meant, then testing it until it was true, and refusing to ship a demo. That's the standard I bring to every applied-AI build: it clocks in and does a job, or it doesn't go live.
If AI is supposed to be doing real work in your business and so far it's been demos, this is the engagement I'd start with: fix the process first, put a model on what's left, and measure it against real use until it holds up when real people lean on it. On the site that's Applied AI.