QueueReaper —
Auction intelligence,
built for the floor.
Designed and built a full-stack wholesale auto auction platform from scratch — giving dealers real-time visibility across live lanes, a buyer pipeline CRM, transport coordination, and invoicing, all inside one dark-mode command center purpose-built for split-second deal flow.
Project overview
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 — 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 at a glance.
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.
Replace the paper run list
Give dealers real-time visibility into every vehicle crossing the block — live lane feeds, sold status, price, and seller data — so they can act in the moment instead of reconstructing history after the fact.
Build a buyer pipeline, not a contact list
Move buyer management from a static spreadsheet to a live CRM pipeline — Lead → Contacted → Closed → Lost — with per-vehicle deal tracking and invoice generation tied directly to the buyer record.
Unify the post-auction workflow
Eliminate the phone calls and sticky notes that governed delivery coordination. Integrate transport vendor management, pickup and dropoff tracking, and delivery status into the same system that captured the sale.
Ship a real product, not a prototype
Design and build a production-grade platform end-to-end — relational database schema, REST API, live React frontend, and AWS infrastructure — owned entirely from concept to deployment.
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 — no retrofitting fields, no ambiguous foreign keys. The schema became the product’s single source of truth.
Dark-mode, data-dense UI design
Wholesale dealers are power users. They don’t want simplified interfaces — they want every number visible, every status readable at a glance, every action one click away. I designed QueueReaper with maximum information density as a design principle, not a problem to solve around. The dark palette reduces eye strain during long auction sessions; the tight grid layouts fit more data without hiding it behind drawers or modals.
Full-stack build & AWS deployment
I built the React frontend from scratch using a component architecture that mirrors the data model — 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 — Lead, Contacted, Closed, 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, 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. The result is a fully functional, production-ready platform, not a mockup. 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.