Paddock20
High-volume automotive dealership lot at dusk

Automotive  ·  Enterprise Operations  ·  Production Retainer

DRX Lot
Assistant.

A mobile-first lot operations platform that controls every vehicle intake, transfer, and release on a high-volume dealership floor. Built to handle $125M+ in monthly throughput with zero manual database migrations. Currently on production retainer.

Vehicle IntakeLot TransfersRelease AuthorizationFloor Staff Mobile UXReal-Time Inventory StateZero-Migration Architecture
$125M+
Monthly throughput managed
Per month, in production
0
Manual database migrations
Since day one of deployment
26
Years of operational context
Behind every design decision
100%
Floor-staff adoption
No training mandates required

The Problem

The Lot Was Running on Memory and Workarounds.

A high-volume dealership floor handling tens of millions of dollars in monthly vehicle inventory was operating without real-time lot state visibility. Vehicle intake was tracked manually. Transfers between lots required phone calls. Releases were authorized by memory and paper. Every handoff point was a potential failure — and the failure cost was measured in delayed sales, lost vehicles, and staff hours spent reconstructing what should have been known instantly.

The request was not for a feature. It was for operational clarity at scale — a system that could absorb the actual complexity of a live dealership floor and make the floor faster, not just more documented.

The staff had built their own workarounds. That was the first signal that the existing tooling had already failed them. The job was to replace the workarounds with something better than they had invented — which is a higher bar than replacing bad software.

How It Got Built

Four Phases.
No Surprises.

01
Discovery

Start With the Floor, Not the Feature List.

The engagement started not with a scope document but with time on the lot. Every intake workflow, every handoff friction point, every workaround the staff had invented to survive the existing system — all of it was observed and mapped before a single line of code was written. The software was designed around how the floor operated, not how a product manager imagined it did.

02
Architecture

Build for Load, Not Demo Day.

A high-volume dealership floor doesn't operate at demo scale. The architecture was designed from the ground up to handle $125M+ in monthly vehicle throughput without requiring manual database migrations as inventory grew. Schema decisions were made with operational reality in mind — not the clean, low-volume environments most software is prototyped against.

03
Design

Mobile-First. No Exceptions.

Floor staff are not at desks. They are moving, on the lot, between vehicles, in all conditions. The UI was designed mobile-first with zero tolerance for anything that required more than two taps to complete a core action. Intake, transfer, and release were each mapped to the shortest possible interaction path — then tested against actual staff workflows before any release.

04
Delivery

Production on Day One. Retainer After That.

The platform shipped into production — not beta, not pilot — and has been on a production retainer ever since. That retainer structure exists because the software is load-bearing: it controls real vehicle movement on a live lot handling tens of millions of dollars in inventory monthly. The engagement did not end at launch. It deepened.

Architecture

Designed for Load.
Not for Demos.

Platform
Mobile-first native UX
Architecture
Zero-migration schema design
Data layer
Real-time inventory state
Auth
Role-based floor staff access
Deployment
Production from day one
Engagement
Active retainer — ongoing

The architectural decisions were made around one constraint: this system cannot go down, cannot lose data, and cannot require a developer on-site when inventory volume changes. Every choice cascades from that requirement.

The Result

Running in Production.
Not Retired After Launch.

The platform shipped into production and has been on a production retainer ever since. Floor staff adopted it without training mandates — which is the real measure of whether a mobile UX works in an operational environment. No manual database migrations have been required since deployment. Vehicle intake, transfer, and release are now tracked in real time.

The retainer is not maintenance. It is continued architectural ownership — the same studio that built it stays responsible for what it becomes. That is what separates a production system from a delivered project.

Start a Project

Have an Operation
That Needs This?

Every engagement starts with a free 15-minute Fit Call. We decide together if it's a fit — and if it is, we move straight to scope, cost, and timeline.

Book a Free Fit CallView All Work How this gets built Download case study PDF
$125M+
Monthly Throughput
In vehicle inventory managed through the platform every month, in production.

Next Case Study

SupercarIQ

Automotive · AI

Build With RAIL: Free

90 Seconds to
Build Your App
With RAIL.

Answer three questions—type them or say them out loud—and watch RAIL scope your app in real time. Named app, working interface, and a build blueprint you keep. Before you ever talk to anyone.

A named app. A working interface. A blueprint PDF you keep. Whether we ever talk or not.

AI-powered90 secondsType or speakPDF blueprint
Build Your App Blueprint →Name + email to receive your PDF blueprint.