Principal Software Engineer – Platform & Site Reliability Engineering

Cox Automotive, Inc. · Sep 2018 – Apr 2026

165+

applications running on a PaaS I architected from scratch

200+

engineers across 30+ teams shipping on my platform

15B

requests a year through an API gateway I built on Kong

99.99%

gateway uptime across two-plus years of operation

Summary

Built the Logistics division's platform-as-a-service from the ground up — a Heroku-style PaaS running 165+ applications for 200+ engineers, fronted by an API gateway handling 15 billion requests a year — then led the shift to AI-first engineering.

I spent seven and a half years in Cox Automotive’s Logistics division — home of CentralDispatch.com and Ready Logistics. I arrived as a contractor with one job: get out of the data center. I stayed to build the paved road that 200+ engineers ship on every day, and it’s still carrying traffic today.

From data center to cloud

Cox brought me in with a clear mandate: migrate the Logistics division out of a physical data center and into AWS. I led the phased migration of dozens of web servers, converting 100% of the infrastructure to code (Terraform) with automated deployments, and managed the move of a 4TB IBM DB2 database to MySQL with zero data loss. The new footprint was designed for failure from day one — a multi-availability-zone (multi-AZ) disaster recovery strategy with automated backups and failover that eliminated the single points of failure the data center had lived with for years.

In 2021, Cox converted me from contractor to full-time Principal Software Engineer. By then the migration was old news — I was already deep into the project that would define my tenure.

Building the platform

Before the platform, deployments across the division were a wild west of homegrown scripts and Jenkins boxes that worked about half the time. CentralDispatch had come to Cox through acquisition, and its tooling lagged well behind Cox engineering standards. Teams experimenting unguided in AWS produced genuine horrors — production databases on public IP addresses with no password.

I architected and built a platform-as-a-service from scratch, modeled on Heroku and grounded in the twelve-factor methodology: containerized runtimes on AWS ECS, every piece of infrastructure expressed as reusable Terraform modules, and GitHub Actions pipelines (which I lovingly named “Terraflow”) for both infrastructure and application deployments. In front of it all sat Master Control — a Ruby on Rails control-plane application I built (and named for the Tron villain) that gave teams self-service access to their apps, environments, and deployments.

The results reframed what teams expected from infrastructure. Where standing up a new service had been a weeks-long negotiation, the platform delivered complete pipelines and runtime infrastructure in a day or two — actual bootstrap time was down to hours. The platform grew to run 165+ applications for 30+ teams and 200+ engineers, and carried the infrastructure for a $40M re-platforming of Ready Logistics operations onto DHL.

Taming 15 billion requests

Conway’s Law had taken hold at CentralDispatch: the product had evolved into a distributed monolith of more than 60 front-end microservices. Because CentralDispatch didn’t offer an API as a product, customers began reverse-engineering those front-end endpoints — running full pagination walks and exfiltrating commercially valuable data. With 60 discrete apps behind 60 separate AWS WAF (web application firewall) instances, coordinated traffic control was impossible, and WAF could only rate-limit by IP address — not by customer.

The answer was a single front door. I led the implementation of an API gateway built on Kong that enforced rate limits per customer — regardless of IP or endpoint — provided consistent request logging and telemetry across the whole business, and opened a new revenue lever: pay more to go faster. Migrating all 60+ microservices behind the gateway took nearly a year, but once complete we locked down direct access entirely, ending the endpoint abuse for good.

As deployed, the gateway handles more than 15 billion requests a year. In the two-plus years I ran it, gateway uptime exceeded 99.99% — even on days when the services behind it were struggling, the front door held.

Reliability by design

In the last five years of my tenure, we never had a production incident that root-caused to “the platform’s infrastructure fell over.” That wasn’t luck — it was architecture: multiple AZs, a two-instance minimum behind load balancers, autoscaling, and managed data services like Aurora and DynamoDB, so availability simply wasn’t a question teams had to ask.

The deployment pipeline used a rolling replacement strategy: new application instances had to prove themselves healthy before the old ones were retired, so a broken build never made it live — it just never launched. And when incidents did occur (almost always application-level — an unoptimized query, a missing index), the Terraform module structure meant responding was a matter of changing one input value and letting Terraflow scale the compute horizontally or vertically in minutes.

AI-first engineering

In my final years, I led my team’s transition to AI-first engineering practices: spec-driven development with GitHub Spec Kit, and a suite of Claude Code plugins and skills that encoded our best practices and institutional knowledge directly into the tools engineers used every day.

The before-and-after was stark. The previous generation of internal tooling was a Python CLI I’d hand-built — close to a month of work for one simple developer setup utility. With Claude Code, I shipped three plugins in a single week: one automating pull request reviews, one disseminating team best practices, and one integrating Spec Kit with Rally. Internal tooling delivery went from weeks to days, and the guardrails moved into the tools themselves.

Force multiplier

I was an individual contributor on paper, but a core part of my role was making the engineers around me better. I mentored the three to four junior engineers on my team, and ran the technical interviews for nearly every candidate we hired. I held weekly infrastructure office hours, gave regular lunch-and-learn tech talks to audiences of 50+ spanning engineers, managers, and product folks, and was an active voice in Cox’s cross-divisional SRE community of practice — a frequent first call for infrastructure advice well beyond my own team.

The long game

Most enterprise software gets replaced within three years. The Logistics Platform as a Service has been in production for more than seven — and as far as I know, it’s still going today, Master Control and all. After seven and a half years, I’d built the thing I came to build and watched it outlast every prediction. I left ready for a new challenge.