Patrick Collison on Stripe’s Early Choices, Smalltalk, and What Comes After Coding

Stripe built one of the world's most reliable payment APIs on MongoDB and Ruby , technologies that many engineers today would consider questionable choices for mission-critical infrastructure. Last year, Stripe's critical APIs achieved 99.99986% uptime, which translates to just 44 seconds of downtime across the entire year. This isn't despite their early technology choices, but because of how they committed to making those choices work.

Patrick Collison's reflection on Stripe's 15-year technical evolution reveals a counterintuitive truth about startup technology decisions. The specific technologies matter far less than your willingness to invest deeply in making them work at scale. When Stripe launched in 2010, Collison and his team deliberately chose what seemed like "relatively more mainstream" options compared to their previous startup, which had used Smalltalk and a custom object database. "Instead of using small talk, you know, okay. We aren't gonna go to Java, but we went to Ruby, which at least on a relative basis seemed more mainstream. And similarly, rather than write our own object database, we went relatively more mainstream and used Mongo," Collison explains.

These choices created massive technical debt that took years to resolve. Collison admits that Stripe has "rewritten a bunch of key services on Java" when Ruby's performance limitations became insurmountable. "If you torture Ruby enough and, you know, maybe rewrite," he notes, trailing off in a way that suggests the painful engineering effort required. The MongoDB choice demanded even more investment. Stripe had to "build a lot of infrastructure in order to make MongoDB as fault tolerant and as distributed and as durable and as reliable and everything as we needed it to be," Collison says. The result justifies the effort , that 99.99986% uptime figure that Collison believes "is the best in the industry."

But the most dramatic admission comes from Stripe's recent API redesign. After twelve years of building on their original abstractions, Stripe concluded that their fundamental data models were wrong. "We realized that a couple of the core abstractions in Stripe were just not the right long term abstractions and we had to fix that," Collison explains. The company spent significant engineering effort designing entirely new v2 APIs that shipped in 2022, representing a wholesale rethinking of how payments should work. The fact that Stripe had the foresight to namespace their original APIs as "v1" from day one proved prescient , they anticipated this moment of reckoning from the beginning.

This pattern suggests a different way to think about early-stage technical decisions. The conventional wisdom focuses on choosing the "right" technologies upfront, but Stripe's experience demonstrates that no choice is permanently right. What matters is building systems that can evolve and making early choices that preserve future optionality. Stripe's willingness to rewrite core services in Java while maintaining their Ruby infrastructure, and to completely redesign their APIs while preserving backward compatibility, shows technical maturity that transcends any specific technology stack.

The lesson extends beyond technology choices to product development more broadly. Stripe's v2 API redesign represents acknowledgment that even successful products need fundamental reimagining as they scale. Most companies resist this kind of disruption to their core systems, but Stripe treated it as inevitable rather than exceptional. The engineering investment required was substantial, but the alternative , continuing to build on flawed abstractions , would have been far more expensive in the long run.

For startup founders making technology choices today, Stripe's story suggests focusing less on picking the "perfect" stack and more on building organizational capabilities for technical evolution. Choose technologies your team understands deeply, plan for versioning and migration from the beginning, and invest heavily in the infrastructure and tooling that will let you evolve those choices as you scale. The technologies that got you to product-market fit probably won't carry you to IPO, and that's perfectly fine as long as you plan for the transition.