Patrick Collison

The Story

Summer 2010. Mountain View, California. Patrick Collison was twenty-one years old, sitting in a cramped Y Combinator office on Pioneer Way, when a startup founder replied to his email saying he'd "give Stripe a look sometime."

Patrick typed back in under thirty seconds: "Are you free at 2pm? We'll come over."

That was the whole trick.

He and his brother John had spent months building a way to accept payments online — something that, at the time, required a merchant account, a payment gateway, a separate bank agreement, weeks of paperwork, and somewhere between 500 and 1,000 lines of code. Stripe reduced that to seven. But nobody knew it existed yet. And in the world of early-stage startups, knowing about something and actually using it are separated by a canyon.

Patrick had no interest in waiting for founders to cross that canyon on their own.

The tactic became known inside YC lore as the "Collison installation." When a potential user said they'd look into it, Patrick or John would show up in person, open a laptop, and walk them through the integration on the spot. Not a sales call. Not a demo. An actual setup. The user would have a working payment form — real card, real money — running on their site before Patrick closed his laptop and left. Paul Graham later said it was one of the most instructive things he'd watched a founder do: not because it was clever, but because it treated urgency as a form of care.

Patrick grew up in Dromineer, a village of about 300 people in County Tipperary, Ireland. There was one computer in the house, shared between the family. He taught himself to code at ten. By sixteen, he had won the Young Scientist and Technologist Exhibition — Ireland's most prestigious student science fair — with a programming language he'd written from scratch. The prize was €3,000 and a place representing Ireland at the European competition in Vienna.

He didn't win there. He came third. He has said, without apparent bitterness, that he learned more from that loss than from the win — specifically that what judges reward and what is technically strong are not always the same thing. The distinction between external validation and real quality became a thread he'd return to throughout his career.

In 2007, while Patrick was still a teenager, he and John founded Auctomatic, a tool to help eBay sellers manage high-volume listings. They sold it in March 2008 for $5 million. Patrick was nineteen. He enrolled at MIT. He left after about a year to build what would become Stripe.

The original problem wasn't payments-as-a-product. It was a developer experience problem. Patrick had watched dozens of capable engineers lose weeks of their lives to payment integration. The existing systems weren't badly built. They'd been designed for large retail businesses with compliance teams and legal departments — not for a twenty-two-year-old with a good idea and a weekend. He thought someone should fix that. He decided it should be him.

The summer in Mountain View was not glamorous. Patrick and John woke early, wrote code, ate at the same Vietnamese restaurant on Castro Street most days, wrote more code, and went to bed. The company was two people and a laptop.

The Collison installation wasn't born from a strategy document. It came from frustration. They had emailed one founder three times. The founder kept saying he'd get to it. Patrick drove over unannounced. It took twenty minutes. The founder had Stripe processing a real payment before lunch.

What Patrick noticed was the founder's face in that moment — the second the dashboard updated and the money actually moved. Something shifted. He stopped treating Stripe as another item on a list and started treating it as something that mattered to him. Patrick would later describe this in a talk: "You can describe a product, or you can show someone what their life looks like when they're using it. Those are completely different things."

The lesson wasn't really about sales technique. It was about the gap between capability and adoption. You can build something genuinely useful, and it can still sit unused for months because the first-run experience is slightly too confusing or the setup cost is slightly too high. Closing that gap, Patrick argued, is product work — not support work, not marketing. It belongs to the builder.

That thinking shaped how Stripe grew. The developer documentation — which engineers still cite as an industry benchmark — wasn't written by a technical writer. Patrick wrote the first version himself. He spent weeks on it and has described it as part of the product, not a description of the product. His internal test was blunt: can a competent developer integrate Stripe without ever speaking to anyone at Stripe? If the answer was no, the docs weren't finished.

There's a story from 2013 that circulates in engineering circles. Patrick was in a meeting about a new feature. The estimate was three months. He asked the team to walk through the work piece by piece. Then he asked a specific question: which parts are actually hard, and which parts are just assumed to be hard?

Three weeks later, the feature shipped.

He wasn't dismissing the difficulty. He was being precise about the nature of it. His claim was that most project timelines contain a large amount of lag — not genuine constraint, but the gap between when you could start something and when you've decided to. He called this pattern out in other contexts too, sometimes under the label "Collison fast": the observation that many things in the world move far slower than the physical or technical constraints actually require. He kept a running list of historical examples — projects and discoveries that had moved dramatically faster than the consensus said was possible — not as motivational fuel, but as evidence. The world's default pace is not the world's possible pace. Recognising the difference is the first competence.

By 2016 Stripe had more than a thousand employees and was processing hundreds of billions of dollars annually. Patrick was in his late twenties. He was still known inside the company for reading user support tickets, for writing code, and for appearing in engineering rooms to ask precise questions about specific things. When a colleague once pointed out that this wasn't what CEOs typically do, he said something to the effect that he wasn't trying to be a typical CEO — he was trying to make sure the company built things that actually worked.

He has spoken about ambition the way a craftsperson speaks about a skill — as something you can practice well or badly, honestly or not. His concern wasn't with people who weren't motivated enough. It was with motivated, capable people who had drifted toward doing things that were fine when they had the skills to tackle things that were genuinely important.

In a 2019 conversation with economist Tyler Cowen, Patrick said: "We're at this remarkable moment where the cost of starting things has gone to near zero, and the ability to have impact has never been higher. And I think we're not nearly ambitious enough about what we should be trying to do."

He meant it concretely, not inspirationally. He was frustrated that intelligent people with real skills were building things that were adequate when they could be building things that were necessary. The question, as he framed it, was not about effort. It was about the quality of the problem you choose to take seriously.

This is a builder's question. Not: are you working hard enough? But: is the problem you've chosen worth building hard for?

Patrick Collison runs a company now valued at around $65 billion and still, by most accounts, thinks of himself primarily as someone who builds things and reads books. He has been photographed at events holding biographies of industrial-era engineers. He recommends that builders read economic history not for inspiration but to understand how systems change and why.

The Collison installation, as a specific tactic, doesn't scale to a company of thousands. But the principle behind it does: the difference between a product that gets used and a product that sits ignored is often just a single push — a single act of showing up before someone changes their mind, doing the thing in front of them rather than leaving them instructions, closing the gap between "it's possible" and "it's happening right now."

That's not a growth hack. It's a builder's habit.

What to take from it

Urgency is a form of respect. When the founder said "I'll try it at some point," Patrick replied in thirty seconds with "We'll come over." That wasn't impatience — it was a signal that the other person's time and intention mattered enough to act on now. Delay is often invisible to the person doing it. The Collison installation worked in part because it made the delay visible and then eliminated it entirely.

Documentation is part of the product, not a description of it. Patrick wrote Stripe's first docs himself and held them to a single test: can someone integrate this without ever talking to us? Whatever you're building — a feature, a process, a team onboarding — the first-run experience alone, with no guidance, is the real product quality test. If it only works with someone explaining it, the work isn't done.

Separate real difficulty from assumed difficulty. The three-month feature that shipped in three weeks didn't require heroic effort. It required a precise question: which parts are actually hard? Most timelines carry lag disguised as necessity. Naming it clearly — out loud, in a meeting, in a plan — is the first step to moving past it.

Ambition is a craft, not a trait. Patrick's frustration wasn't with unmotivated people. It was with motivated people building adequate things when they had the ability to build important ones. The question isn't whether you're working hard enough — it's whether the problem you've chosen is hard enough to deserve it.

Quality and speed reinforce each other. Confusion produces delay dressed up as carefulness. Clarity produces speed. When something is taking longer than it should, the Collison instinct is to look for what's unclear — a goal, a constraint, a decision that hasn't been made — rather than accepting the timeline as fixed.

Today's Growth Point

The gap between "I'll get to it" and "let me do this right now" is where most good intentions die. Patrick's move — showing up before someone changed their mind — is available to anyone in any field. The builder mindset isn't only about software. It's about treating the distance between intention and action as a problem you're responsible for solving.

The one thing to remember

The builder who goes to the problem gets it done; the builder who waits for the problem to come to them waits a long time.

Try this today

Before your first meeting or work block tomorrow morning, pick one thing you've been meaning to follow up on — an email you drafted but didn't send, a conversation you've been planning to have, a decision you're holding open. In the first five minutes of that block, take the one action that moves it off your list: send the email, book the five-minute call, make the call itself. Definition of done: it is no longer on your "to get to" list. The Collison installation in miniature — you show up for it before you find a reason not to.

Sit with this

What's one thing you've been meaning to start or push forward that you'd do right now if someone you respected was watching?

Send this to someone

This story is for the friend who's had an idea for three months and still hasn't sent the first email — not because they don't believe in it, but because the first step feels vague and the timing never feels quite right.

"Sounds interesting. I'll try it at some point." "Are you free at 2pm? We'll come over."

Read this — took me 12 min. Might unstick the thing you've been sitting on.

Sources

• https://www.wired.com/story/stripe-payments-company-patrick-john-collison-silicon-valley/ — Wired's long-form profile of the Collison brothers and Stripe's early years, including the founding circumstances, YC period, and the Collison installation practice.
• https://conversationswithtyler.com/episodes/patrick-collison/ — Patrick Collison in conversation with economist Tyler Cowen (2019); source for his remarks on ambition, speed, and what builders should be building — well worth reading in full.
• https://en.wikipedia.org/wiki/Patrick_Collison — Overview of Patrick's early life in Tipperary, his Young Scientist win, the Auctomatic sale, and Stripe's growth arc.

This is a dramatized editorial narrative created for personal inspiration, drawn from publicly available sources listed above. It is not a biography, does not claim to represent the subject's exact views or experiences, and is not affiliated with or endorsed by the person or their estate. For a fuller picture, we recommend exploring the sources linked above.

Rate 1-5 when you like.