In 2009, Brian Chesky and Joe Gebbia were flying to New York on a regular basis, knocking on doors, and photographing strangers’ apartments with a rented camera. Airbnb had a website. It had listings. What it did not have was any semblance of a scalable operation. The founders were doing in person what the platform was theoretically supposed to do automatically. Most observers at the time would have called this embarrassing. Paul Graham called it the thing that saved the company.
This is the story of fake scale, and it’s one of the most consistently misunderstood strategies in tech.
What “Do Things That Don’t Scale” Actually Means
Paul Graham published his essay on this in 2013, and it became one of the most quoted and least practiced pieces of startup advice ever written. Everyone nods at the idea. Very few founders actually do it, because doing things that don’t scale feels like losing. It feels like admitting the machine doesn’t work yet.
But the founders who leaned into manual operations in their first year weren’t buying time until the technology caught up. They were making a deliberate bet that understanding the problem at human resolution was worth more than the appearance of efficiency. Chesky wasn’t photographing apartments because Airbnb couldn’t afford a camera API. He was doing it because nobody had figured out yet that professional photos were the single biggest driver of booking conversions. You cannot learn that from a dashboard. You learn it by being in the room.
Stripe’s early team famously did what they called “white-glove” onboarding, sitting with developers, watching them integrate the API, and fixing friction in real time. The founders weren’t doing this because they lacked engineers. They were doing it because watching someone actually use your product tells you things that user analytics never will. You see where they pause. You see what they re-read. You see the exact moment they almost quit.
The Data You Can Only Collect By Being There
There’s a category of information that doesn’t survive translation into metrics. Call it tacit product knowledge. It lives in the hesitation before someone clicks a button, in the workaround a user invents because the obvious path doesn’t work, in the specific word a customer uses to describe their problem that turns out to be the exact search term their entire industry uses.
Zappos, before it became the case study for customer service culture, had Tony Hsieh and his team personally handling customer calls and taking extraordinary measures to help individual buyers find shoes. This wasn’t charity. It was market research with a service wrapper. They were learning, in granular detail, what shoe buyers actually wanted from an online retailer, which turned out to be things no shoe retailer had thought to offer: free returns, 365-day return windows, 24/7 phone support. None of that emerged from a spreadsheet. It emerged from conversations.
The pattern holds across categories. DoorDash’s founders personally delivered food orders in Palo Alto before building out their driver network. They were not doing this to be scrappy. They were doing it to understand the physical and logistical reality of the last mile, a problem that looks simple on a product roadmap and turns out to be genuinely hard when you’re standing outside a restaurant at 7:45pm on a Friday with three bags and a time estimate that’s already wrong.
Why Most Founders Skip This Step
The startup mythology of our era centers on scale. Pitch decks are full of hockey sticks. Investors ask about unit economics at seed stage. The entire aesthetic of “building” has become synonymous with software, automation, and the ability to serve a million users without hiring a person. Manual work carries a whiff of failure, of not having figured out the algorithm yet.
This is backwards. The founders who skip the manual phase are not saving time. They are skipping the curriculum. They are building automated systems to solve problems they do not actually understand, which is why so many products launch technically functional and practically useless.
There’s also a competitive intelligence argument here. When you’re doing things manually, you are inside the problem in a way your future competitors will not be. By the time someone else tries to enter the market you’re building, they will be hiring engineers and data scientists to model the behaviors you observed firsthand. You will have already encoded that knowledge into your product decisions in ways that are genuinely hard to replicate from the outside. This is one of the underappreciated reasons why successful startups enter markets they were never built for: the outsider who goes deep manually often understands the market better than the industry veteran who’s been looking at it through a spreadsheet for twenty years.
When to Stop Pretending
The question founders actually struggle with is not whether to do manual work early. Most intellectually honest founders accept this. The question is when the manual phase ends and automation becomes the right move.
The answer is not “when you have enough users to justify it” or “when it gets too expensive.” The answer is when you have learned the specific thing the manual work was designed to teach you. Chesky stopped photographing apartments when Airbnb understood what good listings looked like and could train photographers and eventually build guidelines that hosts could follow themselves. The manual phase had a thesis. Once that thesis was confirmed or disproven, the mode changed.
Founders who stay in manual mode too long are often avoiding a different problem, usually that they still don’t understand their product well enough to automate it confidently. Founders who exit too early are usually prioritizing the appearance of scale over the substance of understanding. Both are expensive mistakes, but the second one tends to be fatal in ways the first one rarely is.
The Real Reason This Works
The deeper argument for manual-first is not just about learning. It’s about trust.
When Airbnb’s founders showed up at a host’s door with a camera, they were not just collecting photographs. They were communicating that someone at the company cared enough to show up. That’s an emotional reality that no onboarding email can replicate. Early users of products that will eventually become enormous are not just customers. They are the people who will tell their friends, write the early reviews, and either anchor the culture of the product or walk away. How you treat them when you have twelve of them is a message that travels.
The companies that built genuine early loyalty almost always did it through disproportionate personal effort. Not because they calculated the ROI of founder-led customer service, but because the founders were genuinely obsessed with whether the thing worked. That obsession is contagious in ways that matter. The first hundred users of Stripe, of Airbnb, of Zappos, became evangelists partly because they had the experience of being seen by people who actually cared.
You cannot automate that. But if you do the manual work long enough and carefully enough, you eventually understand the problem well enough to build something that scales without losing it.
