The simple version
Some customers pay well, demand a lot, and pull your product in a direction that makes it worse for everyone else. The startups that survived this learned to say no to money.
The trap has a name
In the summer of 2009, Airbnb was bleeding cash. The founders were selling novelty cereal boxes to stay alive, and the obvious lifeline was corporate travel. Hotels charge companies a fortune. Companies have predictable budgets. A business-travel deal could have meant reliable, recurring revenue at exactly the moment the company needed it most.
They passed. Not because they were naive, but because they understood something that takes most founders years to learn: a customer who looks like a lifeline is sometimes a leash.
Corporate travel clients would have demanded standardized listings, liability protections, invoice-based billing, and property quality floors that had nothing to do with what made Airbnb interesting. The product would have drifted toward a slightly cheaper version of business hotels. The weird apartment with the great host and the local restaurant recommendation would have gotten squeezed out. Airbnb’s actual advantage, the human texture of staying in someone’s real home, would have been the first casualty of serving enterprise procurement departments.
What this looks like at Stripe
Stripe’s version of this story is subtler. When Stripe launched in 2011, the payment processing world was dominated by legacy players who made their money on large, captive enterprise accounts. The obvious play for a startup trying to get to scale was to chase those same accounts. Big contracts, big logos, credibility with investors.
Instead, Stripe spent years building for developers and small businesses, a customer segment that barely registered as revenue-worthy to traditional processors. The API was clean. The documentation was written for humans. The onboarding took minutes instead of weeks.
The enterprise customers came eventually, but only after Stripe had built a product that worked without them. If they had optimized for enterprise sales first, they would have built a product that required enterprise-style relationships to sell. Sales-driven growth requires sales people. It requires custom contracts. It requires a support model that doesn’t scale. The developer-first bet meant the product could sell itself.
The companies that take the enterprise money early almost always end up charging too little for the wrong things while building features nobody outside that one client actually needs.
Slack almost became an IT tool
Slack’s near-death experience with the wrong customer is the most instructive because it happened after the product was already successful.
By 2015, Slack was growing fast and starting to land large enterprise deals. The pressure inside the company to optimize for IT departments was real. IT buyers want admin controls, compliance features, audit logs, SSO integrations, and the ability to lock things down. These are legitimate needs. Building for them also turns your product into something that feels like IT infrastructure rather than something people actually want to use.
The thing that made Slack valuable was that people chose it. Teams adopted it bottom-up because it was better than email and more fun than the alternatives. The moment Slack started optimizing for the person who signs the purchase order rather than the person who uses it every day, that bottom-up adoption advantage was at risk.
Slack walked this tightrope better than most. They built enterprise features without completely killing the end-user experience. But the tension never fully went away, and it’s a real reason why Microsoft Teams, sold top-down through existing enterprise relationships, eventually overtook Slack in seat count even though many people find it genuinely worse to use. The startup that ignored its best customers to chase a different segment is a cautionary tale that plays out constantly.
How to tell a good customer from a dangerous one
This is where most advice gets vague. “Stay focused on your core user” sounds obvious until you’re looking at a contract that would triple your revenue.
The cleaner test is this: does serving this customer require you to build things that only they need, or things that make your product better for everyone?
Stripe adding fraud detection tools made the product better for every merchant. Airbnb adding better host verification made the product better for every guest. Those investments compound. When a single large customer asks for a feature that only maps to their internal workflow, that investment doesn’t compound. It just accumulates.
There’s a second test: does this customer want you to win, or do they want you to be dependent on them? Enterprise customers who make up more than a significant share of your revenue have enormous leverage over your roadmap, your pricing, and your ability to raise money. Some of them know it and use it. The ones who want you to succeed push you toward things that help other customers too. The ones who want you dependent will slowly turn you into a custom development shop with a SaaS veneer.
The actual lesson
None of this means enterprise customers are bad or that startup founders should be precious about their vision. Airbnb does have business travel features now. Stripe has major enterprise clients. Slack sold to Salesforce for $27 billion.
The sequence is what matters. You build the product that works without the big customer. You establish what makes it valuable on its own terms. Then you add enterprise features from a position of strength, because you already know what the product is. When you take the enterprise money first, you never get the chance to find out.
The founders who survive this don’t do it by being stubborn. They do it by being clear about what their product is actually good at, and honest about which customers are buying that thing versus buying something adjacent that they’ll need you to build. Those are different businesses, and you can only run one of them.
