Every car sold at auction, captured as it sells.
A car delivery business paid an employee to watch live auctions and write down every car that sold and who bought it, so the owner could call each buyer and offer delivery. I designed and built QueueReaper to do the watching: an employee pastes a lane link, and every sale lands as a row with its VIN, vehicle, final bid and buyer, on up to five auctions at once.
Everything: research, requirements, brand, design system, screens and the build
Just me, on a client project at InnoGEV
Next.js, a Python API, PostgreSQL and a Chrome extension
Built, waiting on the client’s approval to launch
One person, one live feed, one notepad
A sale the employee misses is a customer the owner never hears about. My first build proved a scraper could read the auction screen, and I built it as a full CRM. The owner loved the demo, then told me what he actually needed: the capture, auction history, auction detail and a home screen. Real auctions showed three problems no screen design could fix.
- STOPSThe scraper failed during active streams.
- BAD DATAFields came back wrong or garbled.
- ONE LANEIt could not follow two or three auctions at once.
- THE BRIEF
- Read final bid, VIN, vehicle and buyer for every sold car, on up to five lanes at launch. A wrong value is visible and fixable, and the original read is never lost.
- CUT
- Buyers, vendors, deliveries and invoices, on the owner’s word after the first demo. He only needed the list.
Read the page text, not pixels
Every scraper in my first build took a picture of the screen and read each field from a fixed pixel box. A moved window or a notification put the wrong thing in the box. The limit was the capture method, not the server.
- OPTIONS
- A desktop app for the video, one Chrome extension for the page and the video, or page text only.
- PICKED
- The Chrome extension. Lane, run number, vehicle, VIN and the sold message are already text on the page, and it is easier to take away what we do not need later than to add it.
- NO BOT
- It reads inside a real person’s Chrome session, only on lanes someone pasted, so nothing logs in on its own.
Live is one bar and a ledger, and only the rows move
- OPTIONS
- Three layouts from my first build’s Live screen: the ledger first, a workbench with the car on the block in a left rail, or the car on the block inside the auction bar.
- PICKED
- The car on the block lives in the bar, and the Sold and To review counts double as filters. Only the rows scroll, with new sales landing on top.
- TRADE-OFF
- A long auction name cuts off on one line and shows in full on hover.
Flag it, fix it, never lose the original
- RULES
- A row flags itself when the VIN fails its check digit or holds an I, O or Q, or when the buyer or final bid is missing.
- PICKED
- The ledger with a car panel: the screenshot from the moment of the sale, the bad field as an input with the reason under it, and every change with who, when and Restore.
- TRADE-OFF
- The panel takes 400 pixels, so minimum bid and the review column hide while it is open.
- ALSO MY IDEAS
- Five auctions at launch, one header tab away, and an export that shows the car count and rows still needing review before the file downloads.
The app and the brand, 32 screens
I redefined the brand: QUEUEREAPER in wide caps, with REAPER highlighted like selected text and a caret after it. Orchid for state and action, warm stone greys, Manrope for the interface and IBM Plex Mono for VINs, bids and times. Light and dark run on one set of tokens, and every text role passes WCAG AA in both.
What I would do differently
- READ THE PAGE FIRST
- My first scraper read the screen like a photo. I would check whether the fields are already text before writing any capture code.
- MEASURE THE MANUAL WAY
- I never counted how many sales the employee caught or missed. I would run both on the same auction before anything else.
- WILL MEASURE
- Fields read right against the employee’s notes, and minutes from a sale to the first call.