Patrick Collison has told the story a few times. In Stripe’s earliest days, the company would literally go to a customer’s office and set up payments for them by hand. Not a sleek onboarding flow. Not documentation. Patrick or John sitting next to a founder, typing in credentials, debugging in real time. The first paying customers didn’t get Stripe. They got the Collison brothers as their personal IT support.

Most founders hear this story and focus on the hustle angle. The scrappiness. The “do things that don’t scale” lesson that Paul Graham codified into startup gospel. But that misses the more important thing happening: Stripe’s first customers were almost certainly terrible fits for what Stripe would eventually become. They needed hand-holding that a payments infrastructure company couldn’t sustainably provide. They had edge cases that bent the product in directions it was never meant to go. They were, in the precise sense, the wrong customers.

And that’s exactly why they were the right customers.

The Customer Who Reveals the Product

Airbnb’s early users were not the cosmopolitan travelers who would eventually make the company worth tens of billions. They were people booking air mattresses in strangers’ living rooms, mostly because hotels were full during a conference. Brian Chesky has described the experience of staying in early Airbnb listings himself, and what he found was frequently alarming. Broken locks. No towels. Hosts who had no idea what hospitality meant. The product was a mess because the customers were surfacing a mess that already existed.

This is the thing that the “find your ideal customer profile” advice gets backwards. You don’t find your ideal customer in the early days. You find the customer who is desperate enough to use something half-finished, and they show you what the product actually needs to be. Airbnb’s first customers didn’t confirm the founders’ vision. They complicated it in ways that turned out to be essential. The trust and safety infrastructure, the photography program, the review system: all of it came from early users doing things the founders hadn’t anticipated.

Slack’s founding story follows the same pattern, though it’s even more compressed. Stewart Butterfield and his team built Slack for themselves while making a video game called Glitch. The first external users were friends and former colleagues, people who already trusted the team and were willing to tolerate significant roughness. They were, as early users almost always are, not representative of the eventual market at all. They were too patient, too forgiving, and too technically sophisticated. But their specific complaints and workarounds became the product’s backbone.

Diagram showing signal extracted from noise, representing the challenge of interpreting early customer feedback
The work isn't surviving difficult early customers. It's knowing which of their problems to actually solve.

The Survivorship Problem With “Early Traction”

Here’s what the founding mythology doesn’t tell you: most companies that followed this exact playbook, scrappy early customers, doing things that don’t scale, hand-holding the first cohort, didn’t make it. The strategy isn’t a formula. The reason Stripe and Airbnb survived their early customers wasn’t the hustle. It was that the founders were paying a specific kind of attention.

They were watching for the difference between problems that revealed something true about the market and problems that were just noise from a bad-fit customer. That distinction is brutal to make in real time. A first customer who demands a feature that only they will ever need can send a founding team on a months-long detour. A first customer who complains about something the founders wrote off as a minor issue can be pointing at the thing that will matter most at scale.

The skill isn’t finding perfect early customers. It’s developing the judgment to know which of their complaints to act on. Your worst early customer is often your most educational one, but only if you’re asking why they’re difficult rather than just managing them.

Why First Revenue Is a Trap As Much As a Milestone

First revenue creates a commitment bias that most founders don’t fully account for. Once someone is paying you, you feel obligated to keep them happy. That’s rational. But it can calcify your product around a customer whose needs don’t generalize.

This is what almost happened to several enterprise software companies that landed large first customers and spent years building features for a single account. The revenue was real and the relationship felt like validation, but it was actually a constraint. The product became the shape of one customer’s organization instead of the shape of a market.

Stripe avoided this partly by keeping their first customer relationships short-and-intensive rather than deeply integrated. The goal was to get developers to the point where they didn’t need Stripe’s help, not to make Stripe indispensable through dependency. That’s a meaningful philosophical choice, and it’s not obvious. Plenty of founders take the opposite bet: make the first customer so dependent that they never leave. That works until you try to sell to the second customer and realize your product is a bespoke solution wearing a SaaS costume.

Pricing is part of this trap too. First customers often get rates that reflect your desperation more than your value, and those rates become anchors that are almost impossible to move without damaging the relationship.

What Surviving Your First Customer Actually Teaches

The companies that came through their early customer chaos intact share a trait that’s less romantic than the hustle narrative suggests. They were ruthlessly honest about what the chaos was telling them.

Airbnb didn’t just fix the broken locks. They built an entire trust infrastructure because the broken locks were a symptom of a market dynamic, strangers transacting with strangers, that would always generate this kind of problem. Stripe didn’t just help each developer manually. They used every manual integration to find the pattern that would let them write documentation and tooling that made manual help unnecessary.

The first paying customer almost kills you because they demand specificity before you have it. They want answers to questions you haven’t thought through. They want reliability from infrastructure you built last week. They want support from a team that is also the product team, the sales team, and the finance team.

Surviving that isn’t about being scrappy. It’s about staying curious under pressure. Every early customer who breaks something is showing you where the product was lying to you about being finished. The ones who nearly killed Stripe and Airbnb and Slack turned out to be the most honest feedback the founders ever got. They just delivered it in the most inconvenient way possible.