---
title: "Principal Software Engineer – Platform & Site Reliability Engineering"
author: "Jarrod Carlson"
company: "Cox Automotive, Inc."
industry: "Automotive & logistics"
location: "Atlanta, GA (Remote)"
period: "Sep 2018 – Apr 2026"
websites:
  - "https://www.coxautoinc.com/"
  - "https://www.centraldispatch.com/"
  - "https://www.readylogistics.com/"
tech:
  - "AWS"
  - "Terraform"
  - "Docker"
  - "Kong"
  - "Ruby on Rails"
  - "GitHub Actions"
  - "MySQL"
  - "Claude Code"
  - "MCP"
canonical: "https://builtbyjarrod.com/experience/cox-automotive"
---

# Principal Software Engineer – Platform & Site Reliability Engineering — Cox Automotive, Inc.

Sep 2018 – Apr 2026 · Atlanta, GA (Remote)

> Automotive services & software division of Cox Enterprises

## Highlights

- **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](https://12factor.net) 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.
