The Problem
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
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.
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.
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.
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
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
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
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.
Next Case Study
SupercarIQ →
Build With RAIL: Free
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.