From Excel to a Dealership Management System

I started working at Cars For Less, a real used-car dealership in Arlington, TX, in 2022. I was not brought in with a software assignment or a requirements document. I was working inside the operation, learning how the business actually ran.

That distinction matters. The problems appeared through the work itself: VIN lookups by hand, pricing decisions scattered across disconnected spreadsheets, photos processed manually, and administrative work tracked on paper. The operation relied on several manual workflows that depended on accurate, current vehicle data.

Every vehicle had details that had to stay consistent and current: its price history, its photos, and its listing. Doing that by hand and across separate spreadsheets worked while the operation was small, and it stopped working as the operation grew.

I wanted vehicle information, pricing, photos, listings, and the day-to-day workflows to work together instead of requiring me to move information between different places. And I wanted that to happen without throwing away the data and processes that were already working.

I built the spreadsheets and VBA tools myself, not to replace Excel, but to give the day-to-day work a place to live. I structured information, tracked vehicles, captured costs, and made the dealership's data easier to work with.

As I used the tools, the shape of the work came into focus: which information belonged together, which tasks were repetitive, and where the spreadsheet approach started to become difficult to manage.

The web application grew out of those earlier tools and everything I had learned from using them. I built it with Next.js 16, React 19, TypeScript, PostgreSQL, and Prisma, and I directed the architecture, the data model, and the deployment myself.

The decision that drove almost every other one was this: the public site and the admin side had to read from the same underlying data. One system of record, not two. I designed a relational data model that unified inventory, customer, sales, and operational workflows, and the customer pages, the admin console, and the background jobs all read and write the same store.

The same codebase serves the public site, so the inventory customers see is the inventory operations manages. The system also handles image optimization, automated inventory distribution, localized search pages, and a first-party inventory assistant that answers customer questions using live dealership data.

VIN entry was manual and error-prone. Most solutions send a photo to a server to read it; I built the opposite: a recognition engine that reads vehicle identification numbers inside the browser, on the device, with nothing uploaded. It handles barcodes, printed labels, and photos, and it works offline.

Real-world photos aren't clean, so the system combines barcode recognition and OCR, applies preprocessing and enhancement only when a defect is actually detected, and validates every read before a candidate is accepted. A bad read never becomes bad data.

The result: VINs can be captured directly on the device without uploading images, which makes the workflow faster, private, and usable offline.

Aside from features, the system had to earn its place in daily operation. I implemented role-based access controls, session security, rate limiting, upload validation, audit logging, and production security hardening, and I ran a security review before deployment.

For search and distribution, the system publishes sitemaps, robots rules, and structured data, and keeps vehicle listings current. Vehicle images are re-encoded to WebP under 200 KB, uploads are re-encoded client side, and caching, lazy chunking, and Core Web Vitals audits keep the site fast.

What changed: vehicle, customer, and sales data live in one place instead of scattered spreadsheets; workflows that used to be repeated by hand now run on a shared system; and the software is deployed in a real operating business, not a class project.

The new system did not erase everything that came before it. The Excel and VBA tools I built remain useful for parts of the operation, while the web application handles the workflows it was designed to improve. New systems have to coexist with existing data, processes, and other tools that cannot simply be thrown away.

The biggest lesson was not about Next.js, PostgreSQL, or any other technology. Software becomes useful when you understand the work behind the problem. Building the Excel and VBA tools first gave me a way to understand the data; working at the dealership gave me the workflows; and the web application turned that understanding into software.