Dealer.com — Developer Tooling & Platform

Dealer.com, part of Cox Automotive, builds the digital-marketing and website platform that car dealerships run their online presence on — dealer websites, inventory, advertising, and the software behind them.

Before the AI era, I spent the better part of a decade at Dealer.com (Cox Automotive), UI Engineer to Senior UI Engineer, building the layer underneath the product — the tools that let other engineers ship. Platform work at that scale is its own discipline: your users sit a few desks away, they are not shy, and every rough edge gets paid for by everyone who touches it, daily. I wrote a lot of those tools myself — dozens of internal single-page apps, plus the generators and services around them. The theme in the ones I am proudest of: take a painful manual process, treat its data as something you can read and merge, and hand people a tool that does the tedious part.

The scaffolding

My team owned the internal platform for spinning up single-page apps; my piece was the front end — the templates and the generator that let anyone start a new app without scaffolding by hand. Minutes instead of days, conventions already wired in, so the first commit could be a feature, not setup. That generator was my baby, and it is the direct ancestor of packkit.

Config as data

The work I am proudest of started with a boring problem. Every site’s configuration — pages, content, widget settings, forms — lived as versioned records in an internal service, and seeing a site’s setup meant pulling it through a command-line tool every time and hoping it was not stale. My first app there put that config in a browser: look up any site by version and read it on a web page. It quietly became one of the most-used internal tools in the company.

Then I went after changing it at scale. Bulk updates meant a one-off script each time, so I designed a small merge format — write the change in the shape the system already speaks, and it merges cleanly across thousands of records — and wrapped it in a UI that generated and applied the change with a click. Later I folded editing into the browser itself: see a site’s setup, change it in place, save — a full loop from read-only viewer to safe self-service editor. I reused the same merge idea for shared forms, so a site could add or move fields without cloning the form and losing the parent’s updates.

A fleet of small tools

Around those sat smaller apps, each removing a specific pain: a self-service intake tool so non-engineering teams could file requests that routed to the right engineers and opened tracked work; a reporter that mapped which sites ran which third-party add-ons, for a push to make the platform faster; a weekend service that gathered widgets’ scattered preference definitions into one searchable docs site; an asset manager (my last app there) that let designers manage global brand imagery without reaching into GitHub; and a Slack bot that answered the same chat question for the tenth time and, on request, served cat pictures. A tool people enjoy opening is a tool they use — delight is a feature, even in a dev tool.

What a decade of platform work taught me

• Internal tools are real products — with users, onboarding, bugs, and a reputation. The moment an engineer routes around your tool, you shipped a failure.
• The best DX is the kind you never notice. If people had to read the docs to use the scaffolding, the scaffolding was wrong.
• Maintenance is the job, not a tax on it. Pre-AI, every tool was hand-written and kept alive by a human as the ground shifted. Build small, build boring, leave a trail.

packkit is the AI-era descendant of that generator — same mission, an order of magnitude more leverage, because the thing doing the scaffolding can now reason about what it is scaffolding. It is the same instinct behind everything else on this page: build the thing that makes the next thing easy.

(High-level outline only; specifics stay confidential.)