Broadhop

In late 2009, I was at Broadhop in Denver, deploying the Quantum Network Suite for international telecoms like Saudi Telecom. Quantum ran on MongoDB—which was still in beta. This was before "DevOps" was a common term, before infrastructure as code was standard practice, before anyone had written the playbooks we all follow now.

MongoDB version 1.4's high availability was, to put it charitably, "completely broken." When v1.5 introduced replica sets, Saudi Telecom asked me why the logs said "1.5 for beta use only." My response? "Just ignore that." We were shipping beta software to production for international telecoms because that's what the business needed.

What I didn't realize at the time was that I was about to start debugging production issues directly with the co-founder and CTO of the database we were betting the company on.

When you're running bleeding-edge technology in production, you don't have Stack Overflow answers or well-documented runbooks. You have Google Groups and the hope that someone who knows the code will respond.

I started reporting bugs and asking questions about multi-master replication issues. Some guy named "Eliot" kept responding—within minutes, not hours. He'd suggest patches, point me to new builds, walk through the replication logic with me.

Eliot Horowitz was the co-founder and CTO of 10gen—the company that built MongoDB. I didn't know that at the time. I was too busy shipping to notice. To me, he was just the most helpful person on the internet, someone who clearly understood the codebase intimately.

Broadhop was competing against solutions built on Oracle RAC—the enterprise standard for high-availability databases. Our competitors had decades of Oracle expertise, proven deployment patterns, and enterprise sales relationships.

We had a beta database and a willingness to work directly with the people building it.

We won deals against Oracle RAC. Not because MongoDB was more mature—it wasn't. But because we could move faster, iterate on problems in real-time, and had a direct line to the people who could fix issues at the source.

Looking back, this engagement embodied patterns that wouldn't have names for years. We were doing "shift left"—bringing operational concerns into the development process. We were practicing "you build it, you run it"—I was both deploying and supporting the infrastructure. We were doing "continuous feedback"—shipping to production and iterating based on real-world behavior.

But we didn't call it any of those things. We called it "getting the job done."

This was my first taste of what I'd later understand as the DevOps mindset: technology decisions aren't just technical—they're about feedback loops, relationships, and the ability to solve problems faster than your competitors.