About / Josh Caffey
Building the systems behind the software.
I’ve spent 18 years building production software. I started as a software engineer building applications and distributed systems. Platform engineering and architecture grew out of that work: building something, scaling it, and understanding what it takes to keep it running.
2014–2019 / ART19
Building from zero.
I joined ART19 as a contractor before transitioning to full-time. I was one of the first three engineers. We built ART19 from actual zero.
My work included distributed synchronization, APIs, and deployment and infrastructure concerns—the engineering required to turn an early system into a production platform. I helped build and scale systems that eventually included APIs exceeding 100,000 requests per minute.
ART19 was later acquired by Amazon in 2021.
2024–2026 / Volt Labs
Improving how systems get built.
At Volt Labs, I eventually became Head of Platform, working on an enterprise messaging platform processing millions of SMS messages per day. I applied that production experience to the systems behind the team’s work: a shared service framework, developer tooling and environments, platform modernization, observability, and cloud architecture.
That changed how I think. I still care about code. But the problems that cost organizations the most rarely live in one function or one service. They live between things: between teams and tools, between a design and the people who have to build it, between what a system does and what anyone can see it doing.
01 / The whole system
Software is a system, not just code.
An engineering organization is a system too. Architecture, build and deploy tooling, developer environments, infrastructure, and operational visibility all decide how fast a team can change its software, and how safely.
When something is hard, it’s usually hard because of how those pieces fit together. So I start with questions about the system.
- Where is the same complexity being solved again and again?
- Which constraints are real, and which are accidental?
- What should become a platform capability, and what should stay with the team?
Sometimes the answer is a new platform capability. Sometimes it’s deleting something. Adding another layer is the last thing I reach for.
02 / Implementation
Architecture should survive contact with implementation.
I like a whiteboard. It’s the best place to find a design. But a diagram doesn’t have to be built, deployed, debugged at 2 a.m., or changed by someone new. So I test designs against the work.
- What will an engineer actually have to write?
- How will it be deployed, and what does it look like when it breaks?
- Who has to change it in a year, without me in the room?
If I can’t answer those, the design isn’t finished. Often the fastest way to answer is to build the thin version: a prototype, a CLI, a working pipeline.
I’m as comfortable in the code as I am in the diagram, and I’ll go where the design needs me.
03 / Craft
The craft still matters.
My scope got larger. My interest in programming didn’t get smaller. I still care about a clear API, an abstraction that earns its place, and a system simple enough to hold in your head. I still love terminals, and I still build the command-line tools I’d want to use.
Experience mostly changed what I ask of the code. Early on, a clever solution or an interesting technology was reason enough. Now I ask who will run it, who will change it, and what it costs to own. Sometimes the answer is still something sophisticated. It has to earn its place. Often the answer is Postgres.
What I do now
Make good engineering easier.
Today I work as a Platform Architect & Engineering Consultant. I welcome consulting engagements and engineering roles where I can help design and build the next system.