Seven lines of code: how Stripe built infrastructure-first from day one
- Patrick and John Collison founded Stripe in 2010 after concluding that the real obstacle to building an internet business wasn't the idea or the code — it was getting paid online.
- Stripe treated payments as infrastructure rather than a feature: a developer could integrate it by adding seven lines of code, instead of the weeks typically required by a bank and a separate payment gateway.
- Stripe made an explicit promise to developers — once integrated, they wouldn't need to touch the API again for years — which shaped how everything underneath it was built and versioned.
- This is the one story on this list where nobody had to learn the lesson the expensive way, because the architecture decision was made before the company had a single user.
Every other story in this series is about a team learning an infrastructure lesson after it became expensive. This one is about a team that skipped the expensive part entirely, by treating infrastructure as the actual product.
The problem the Collisons noticed
Patrick Collison, 21 at the time, and his younger brother John, 19, had already sold one earlier startup, Auctomatic, in 2008. By 2010, working out of Y Combinator and later a borrowed apartment in Buenos Aires, they kept running into the same observation: building the actual product for an internet business — the idea, the code, getting people to pay attention — was rarely the hardest part. The hardest part was finding a way to accept the customer's money.
The existing options all carried the same friction. PayPal had its own well-known limitations, and payment gateways like Authorize.net — which Visa would go on to acquire for $2 billion that same year — required a merchant account from a bank, a separate gateway account, SSL certificates, and a PCI compliance process. Typically weeks of work, involving more than one external party, before a business could accept its first dollar online.
Treating payments as infrastructure, not a feature
Stripe's response wasn't a slightly better checkout form. It was a decision to build the missing infrastructure layer itself, exposed through an API simple enough that a developer could accept payments by adding seven lines of code to their site — a detail that became central to how the company was described for years afterward.
That's a meaningfully different kind of decision than most startups make at the same stage. Most early products optimize for shipping the visible feature fast. Stripe optimized for making the invisible infrastructure underneath that feature disappear completely from the developer's workload — which only works if the API itself is something the company is willing to commit to long-term, before any users exist to say what they'd like changed.
The promise that shaped the architecture
Stripe's pitch to developers carried an explicit promise: once you integrate the API, you won't need to touch it again for years. That's not just a marketing line — it's an architectural constraint. Honoring it meant every decision about how the API evolved, how new functionality got added without breaking what already existed, and how versioning worked, had to be made with multi-year stability in mind from the very first release, rather than bolted on once enough customers depended on backward compatibility.
What that discipline bought
Stripe's growth over the following decade is well documented: from a Y Combinator-backed startup in 2010 to one of the most valuable private financial infrastructure companies, processing payments at various points for platforms including Amazon, Shopify, and Salesforce, alongside millions of smaller businesses.
None of that growth required Stripe to go back and rebuild its core payments API from scratch. The stability promise made in 2010 is, in a structural sense, still the same promise the API keeps today — new products got built around the core, rather than the core needing to be replaced underneath them.
Build the part everything else depends on so carefully that you never have to touch it again — and let everything else change quickly because of it.
The lesson for builders today
Every other story in this series describes a team learning an infrastructure lesson the expensive way — after an outage, after a database had to be sharded under pressure, after a pivot exposed which part of the system actually mattered. Stripe is the version where the lesson was already learned before the company existed: build the infrastructure layer first, commit to its stability deliberately, and let every feature on top of it be the part that iterates quickly.
That's the difference between a build and an infrastructure-first build, and it's the whole premise behind how we scope a project at Yogreet: the parts of a system that other things will depend on for years deserve more architectural care up front than the parts users will see and ask to change next quarter.
FAQ
How many lines of code did it originally take to integrate Stripe?
Stripe's defining pitch to developers was that adding online payment acceptance to a website took just seven lines of code, compared to the multi-week integration process typically required by banks and payment gateways at the time.
When was Stripe founded?
Stripe was founded in 2010 by brothers Patrick and John Collison, and launched publicly in September 2011 after going through Y Combinator.
What made Stripe different from earlier payment processors?
Stripe treated payments as a developer-facing infrastructure layer rather than a checkout feature, prioritizing API simplicity and long-term stability so companies integrating it would not need to revisit the integration for years.
Who are Stripe's customers?
Stripe has processed payments for a wide range of companies over the years, including large platforms such as Amazon, Shopify, and Salesforce, alongside millions of smaller businesses.
Want the part of your product everything depends on built right the first time?
We treat your core architecture as infrastructure from sprint one — so you're not rebuilding it under pressure later.
Book a Build Audit