QueueReaper:
auction intelligence,
built for the floor.
Wholesale dealers make $30,000 calls in under two minutes, across five lanes at once, with a paper run list and a spreadsheet. I watched them work, then designed a command center that keeps every lane, buyer, delivery, and invoice in view without making anyone slow down. I built it too, schema to deployed app, so the demo below is the real product.
The floor-pace problem
Wholesale auto auctions move fast. At a place like Manheim Dallas, dozens of vehicles cross the block every hour across multiple simultaneous lanes, and the dealers buying inventory are expected to make $30,000 decisions in under two minutes, with no centralized tool to help them do it.
The workflow before QueueReaper was a patchwork of improvisation: paper run lists, spreadsheet buyer trackers, phone-call delivery coordination, and disconnected invoicing. A dealer managing five auction lanes at once had no real-time visibility into what was selling, who was buying, or whether transport had been arranged for the vehicle they closed yesterday.
I designed and built QueueReaper to close that gap entirely. It’s a full-stack auction intelligence platform covering everything from live feed monitoring to final invoice, designed with the data density and speed that wholesale dealers actually demand. Every screen is built for a user who has zero time and needs every number in front of them.
The deepest design challenge wasn’t visual. It was data architecture: how to model a relational chain from auction → vehicle → buyer → delivery → invoice, and surface exactly the right slice of that chain depending on where a user is in the workflow.
Field research & workflow mapping
I spent time at the auction floor observing how dealers actually worked: run lists marked in pen, phones open to Manheim’s live feed, texts flying to buyers in real time. The core insight: the existing tools weren’t being ignored out of laziness. They genuinely didn’t map to the speed and non-linearity of auction buying. Dealers needed a tool that could handle five things happening simultaneously without demanding they slow down to use it.
Schema-first data architecture
Before a single screen was designed, I built the full PostgreSQL schema: auctions → vehicles → buyers → vehicle_buyers (CRM) → deliveries → invoices. Getting the relational model right early meant every subsequent design decision had a clear data contract to work against, with no retrofitting fields, no ambiguous foreign keys. The schema became the product’s single source of truth.
Dark-mode, data-dense UI design
Built a dark, data-dense interface dealers can scan from across the lot. Live vehicle counts, sold status, and buyer pipeline are visible at a glance, not buried behind drawers or modals. The dark palette reduces eye strain during long auction sessions; tight grid layouts fit more data per screen without sacrificing scannability.
Full-stack build & AWS deployment
I built the React frontend using a component architecture that mirrors the data model, so each major entity (Auction, Vehicle, Buyer, Invoice) has a corresponding view hierarchy. The Python backend serves a REST API consumed by the frontend. The whole stack is deployed on AWS, with PostgreSQL as the persistence layer. I wrote the API documentation, migration scripts, and deployment runbooks myself.
Live auction monitor
Watch multiple simultaneous auction lanes in real time. Vehicle count, sold count, and close rate update live, so a dealer running five lanes at once always knows exactly where attention is needed.
Vehicle intelligence & history
VIN-level tracking for every vehicle that crossed the block: year, make, model, seller, lane position, time on block, sold price. Filterable by auction, date range, make, model, year, and state.
Buyer pipeline CRM
Every dealership buyer lives in a full profile with contact info, assigned vehicles, and a pipeline status of Lead, Contacted, Closed, or Lost. Deals move through the pipeline with a click; invoices generate from the same record.
Delivery coordination
Assign transport vendors to purchased vehicles, set pickup and dropoff addresses, and track delivery status (Scheduled, In Transit, Delivered) without leaving the platform or picking up a phone.
Invoice management
Per-vehicle invoices with itemized line items (transport, insurance, handling fees), payment status tracking (Paid, Pending, Missing Payment), and due dates, all linked directly to the buyer and vehicle records.
Auction history & analytics
Every past auction is logged with full vehicle and outcome data. Dealers can drill into any historical auction to see exactly what sold, at what price, and to which buyer, with multi-field filtering across 50+ records per session.
I designed and built this entire prototype myself, from data schema to deployed React application, using AI-assisted development to move at a pace that compressed weeks of traditional engineering into days. It is a working application, not a mockup, and it has not launched to customers yet. Every click, filter, and modal works.
Data density is a feature, not a debt
Designing for power users means resisting the impulse to simplify. Wholesale dealers need every number visible without drilling down. The right design decision was to trust the user’s expertise and give them the dense, fast interface they actually work in, not the one a consumer UX playbook would prescribe.
Schema first, screens second
Every time I’ve jumped to UI before the data model was solid, I’ve paid for it in retrofits. Building the full PostgreSQL schema before designing a single screen gave QueueReaper a clarity of information architecture that would have been impossible to reverse-engineer from mockups.
Real-time design is a different discipline
Designing for live auction feeds forced me to think about state in ways that static UX doesn’t require. What happens when a vehicle sells mid-session? When a lane count changes? When a buyer status updates while the list is filtered? Every state transition had to be a design decision, not just a development detail.
Full-stack ownership accelerates everything
Owning the design, frontend, backend, and infrastructure meant zero handoff friction. When a design decision surfaced a data modeling problem, I could fix both in the same session. When a user request required a new API endpoint, I could design the UI and ship the endpoint in parallel. That velocity changes what’s possible.
Have a complex problem
that needs untangling?
I’m available for new roles and the right freelance projects.