Paddock20 · Case Study · Automotive · Enterprise Operations
Track every vehicle in, moved, or out. Live, on the phone your crew already carries. It ran a busy dealer floor at $125M+ a month. No one ever moved the database by hand.
The Problem
A dealership floor moving tens of millions in cars each month, with no live picture of where anything was. Intake was written down by hand. Moving a car between lots meant a phone call. Releases ran on memory and paper. Every handoff could drop one, and when it did the cost was late sales, lost cars, and hours spent piecing back together what should have been obvious.
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 Was Built
Discovery
This did not start with a scope document. It started with time on the lot. How cars came in, where handoffs stalled, and every workaround the staff had invented to get through the day, all of it watched and mapped before a line of code. The software fits how the floor works, not how anyone pictured it working.
Architecture
A high-volume dealership floor doesn't operate at demo scale. It was built from day one to carry $125M+ of cars a month, and to grow without anyone running a migration by hand. The schema was drawn for a real floor, not for the clean, quiet test data most software is built against.
Design
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.
Delivery
The platform shipped into production, not beta and not pilot, and ran the floor from day one. It was built to be load-bearing: it controls live vehicle movement on a lot handling tens of millions of dollars in inventory monthly. The engagement did not end at launch. It deepened.
Architecture
One rule shaped every choice. It cannot go down. It cannot lose data. And it cannot need a developer on site when the lot gets busy. Everything else follows from that.
The Result
The platform shipped into production and ran the floor from day one. Floor staff adopted it without training mandates — which is the true 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 live.
The retainer is not maintenance. The architect who built it stays on the hook for what it becomes. That is the line between a live system and a project that was handed over.