Crafting Engineering Strategy

Chapter 22. Developer, API, and Acquisition Strategy at Stripe

The hypergrowth companies of the 2010s adopted a number of techniques to balance the constraints of running a rapidly growing business without being overwhelmed by the technical complexity created by quick expansion. One common technique was decomposing their monoliths; another was acquiring existing companies with missing functionality. Both are conceptually simple, but they went wrong for many adopting companies.

This chapter focuses on Stripe’s somewhat atypical approaches to three specific challenges that it encountered during that period: API deprecation, managing a large monolithic codebase, and integrating the Index acquisition. For example, Stripe did not decompose its monolithic Ruby codebase, sticking with a centralized codebase as it grew past three thousand engineers. Even in 2025, Stripe has relied on techniques such as creating the Sorbet static type checker rather than migrating to a statically typed language or decomposing into isolated codebases.

These documents are a particular testament to how much the details matter in strategy—I imagine these approaches would not consistently work if adopted elsewhere—and the value of enduring strategy. Almost all the impact of these strategies would have been undermined if they’d only lasted a year or two, but they’ve been remarkably effective over the course of a consistent decade of application.

Reading These Documents

The documents in this chapter are: