The Counterintuitive Core
In 2013, Paul Graham published an essay that has shaped more startups than almost any other single piece of writing. Its title is its whole argument: "Do Things That Don't Scale."
The advice runs against everything a technical founder instinctively believes. Engineers are trained to build systems that scale, to automate, to avoid manual work, to design for a million users from day one. Graham's essay tells them to do the opposite at the start. "One of the most common types of advice we give at Y Combinator is to do things that don't scale," he wrote. "A lot of would-be founders believe that startups either take off or don't. You build something, make it available, and if you've made a better mousetrap, people beat a path to your door as promised. Or they don't, in which case the market must not exist. Actually, startups take off because the founders make them take off."
That last sentence is the hinge of the entire essay. Startups are not seeds that either germinate or don't. They're more like fires that need to be lit and fanned by hand until they're hot enough to sustain themselves. The unscalable work is the fanning.
The essay endures because it corrects a specific delusion: that a good product markets itself. It almost never does at the start. The founders of companies you admire didn't wait for traction. They manufactured it through effort that wouldn't have worked at any larger size, and that was the point.
Why Startups Need a Push
Graham uses a vivid image. He compares getting a startup going to the hand crank that car engines needed before electric starters: "Once the engine was going, it would keep going, but there was a separate and laborious process to get it going." A startup works the same way. Once it has momentum it can coast, but at the start there's a separate, laborious process to get it moving, and nothing happens unless the founders do that cranking.
This reframes the worry every early founder feels. When you launch and almost no one shows up, the instinct is to conclude the idea is bad. Graham says that conclusion is usually premature. The absence of automatic growth tells you almost nothing, because automatic growth at the start is rare even for companies that become huge. What matters is whether you're willing to generate growth manually while you learn.
The push has a second purpose beyond momentum. When you personally recruit and serve your first users, you're standing close enough to see exactly what they need. That proximity is impossible to maintain at scale, and it's where the real product gets discovered. The unscalable phase is when you figure out what to build. The scalable phase is when you build it for everyone.
There's a reason this connects to finding genuine demand. Doing things that don't scale is how you discover whether the pull you feel is real, the same search at the heart of product-market fit. You can't sense that pull from behind a dashboard. You sense it by handing your product to a human and watching their face.
Recruit Users Manually
Graham is specific about the most important unscalable thing: "The most common unscalable thing founders have to do at the start is to recruit users manually. Nearly all startups have to. You can't wait for users to come to you. You have to go out and get them."
This is uncomfortable for founders who'd rather build than sell. Writing code is concrete and controllable. Walking up to a stranger and asking them to try your product is awkward and full of rejection. But the awkward path is the one that works.
Graham makes a sharp point about scale here that founders consistently misread. He notes that founders worry manual recruitment won't scale, and he agrees that it won't, and says that's fine. "But that conviction that it won't scale is precisely what you need to be doing in the early stage." The unscalability is a feature. You do it because it teaches you things automation never could, and you stop when you've learned enough and growth becomes self-sustaining.
There's a reason the manual phase aims for intensity, not breadth. A small number of users who genuinely love your product gives you a clearer signal and a stronger foundation than a large number who merely like it. A handful of obsessed early users will teach you more, and refer more people, than a crowd of indifferent ones.
The Airbnb Story
The Airbnb story is the centerpiece of the essay, and for good reason. In its early days, Airbnb was barely growing. The founders, Brian Chesky and Joe Gebbia, did something no scalable playbook would suggest: they went door to door in New York, where many of their listings were.
They met hosts in person. They helped them improve their listings. And they took professional photos of the apartments themselves, since good photography made a listing far more appealing than a host's own snapshots. None of this scaled. You cannot personally photograph every apartment on a global platform. Early on, with a small number of listings concentrated in one city, they could, and Graham notes the door-to-door push ran for about a month.
Graham's summary became startup canon: "It's not enough just to do something extraordinary initially. You have to make an extraordinary effort initially." The Airbnb founders weren't waiting for network effects to kick in. They were manually fixing the experience for one host at a time, learning what made a listing convert, and using that knowledge to shape the product. The door-knocking phase is where Airbnb learned what Airbnb actually was.
The lesson generalizes. Whatever your equivalent of "fly to New York and photograph the apartments" is, that's probably the thing you're avoiding because it doesn't scale. It's also probably the thing you most need to do.
The Collison Installation
Stripe contributed a term to the startup vocabulary that perfectly captures the spirit of the essay: the "Collison installation."
Stripe was founded by brothers Patrick and John Collison to make accepting payments online dramatically easier for developers. When they met someone who said they'd be willing to try Stripe, the brothers didn't email a signup link and hope. As Graham tells it: "When anyone agreed to try Stripe they'd say 'Right then, give me your laptop' and set them up on the spot."
That move, grabbing the prospect's laptop and getting them live then and there, is the Collison installation. It's the opposite of a frictionless self-serve funnel. It's maximum friction for the founders and zero friction for the user. It doesn't scale, and it was exactly right. Every installation taught the Collisons where the product confused people, and it converted lukewarm interest into a live, integrated customer before the moment of enthusiasm faded.
Graham's broader point is that more diffident founders shy away from this. Grabbing someone's laptop feels pushy. Asking a busy person to integrate your API on the spot feels presumptuous. But the founders who did the pushy, unscalable thing built one of the most valuable private companies in the world, partly because they refused to let interested users drift away unactivated.
Delight: Be Insanely Good to Early Users
Beyond recruitment, Graham emphasizes the quality of the early experience. Because you have so few users at the start, you can afford to treat each one extraordinarily well, in ways that would bankrupt you at scale. Graham's term for it is "delight," and he means it as a deliberate tactic rather than a nicety.
His examples are small and human. Wufoo, a form-building startup, sent each new user a handwritten thank-you note. That's absurd at scale and delightful at small numbers. The point isn't the note itself. It's that an over-the-top early experience builds a core of users who genuinely love the product, and those users become your first evangelists and your best source of feedback.
Graham frames this as a deliberate strategy, not just niceness: "Your first users should feel that signing up with you was one of the best choices they ever made. And you, in turn, should be racking your brains to think of new ways to delight them." The delight is partly a learning tool. When you're bending over backward to make users happy, you discover precisely what they value and what they tolerate.
This is also where many founders underestimate the compounding value of early word of mouth. A hundred users who feel personally cared for will recruit the next thousand. A thousand users who feel like ticket numbers won't. The unscalable delight of the first phase is what makes the scalable growth of the next phase possible. For the broader mechanics of how that early love turns into durable growth, see our growth handbook.
Shyness and Laziness
Graham diagnoses why founders resist this advice, and his diagnosis is unflattering in a useful way. The reluctance to recruit users by hand, he writes, comes from "a combination of shyness and laziness."
Laziness is the preference for building over selling. Recruiting users by hand, photographing apartments, installing software on strangers' laptops, sending handwritten notes: all of it is tedious, repetitive, and unglamorous. It's far more pleasant to sit behind a screen and refine the product, telling yourself that if you just build it a little better, users will come. They usually won't.
Shyness is the fear of seeming pushy or presumptuous. It feels uncomfortable to ask people to try your thing, to follow up, to grab the laptop. Founders talk themselves out of the high-effort move because it feels socially risky. Graham's response is that this discomfort is exactly the toll you pay for traction, and the founders who pay it win.
Both excuses share a feature: they masquerade as reasons. "It won't scale" sounds analytical. "I don't want to bother people" sounds considerate. Underneath, they're often just avoidance of work that's hard and unflattering. Naming them as shyness and laziness strips away the disguise. Once you see that your "strategic" reluctance is really one of these two, the path forward is obvious, even if it's still uncomfortable.
How to Apply It to Your Startup
The essay is famous, but its application is where most founders stumble. Here's how to translate it into action.
Make a list of your first 50 users by name. Not a marketing funnel. Actual people you can reach. Friends, communities you belong to, strangers in the right places. Your job in the first months is to get these specific humans using your product and loving it.
Identify your "fly to New York" move. What's the high-effort, unscalable thing that would make your early users' experience dramatically better? Onboarding them personally, doing part of the work for them, sitting with them while they use the product. Whatever you're avoiding because it doesn't scale is your candidate.
Do the Collison installation. When someone shows interest, don't send a link and hope. Get them using the product right now, with you, removing every ounce of friction on their side. Convert interest into activation before it cools.
Over-deliver deliberately. Find one over-the-top way to delight each early user. Respond to support in minutes. Build the small feature they asked for and tell them you did. Send the handwritten note. Aim for users who feel signing up was one of their best decisions.
Treat every interaction as research. The reason you do this isn't just to get users. It's to learn. Take notes on every conversation. What confused them? What delighted them? What did they expect that wasn't there? This is the richest product research you'll ever get, and it only exists in the unscalable phase.
Set an exit condition. Unscalable work is for the start, not forever. Decide what signal tells you it's time to build the scalable version: a level of demand you can no longer serve by hand, a pattern in what users need that's now clear enough to automate.
This sequence pairs naturally with knowing which maze you're in. Before you recruit your first 50 users, it helps to understand the terrain, which we cover in our guide to the idea maze.
Turning Unscalable Work Into Knowledge
The hidden payoff of doing things that don't scale is the knowledge you accumulate. Every manual conversation, every onboarding session, every support reply contains signal about what to build. The founders who win aren't just the ones who do the unscalable work. They're the ones who capture what it teaches them.
This is where a deliberate system matters. The insights from fifty user conversations are worthless if they evaporate. The founders Graham celebrates were, almost universally, intense learners who turned raw interaction into product decisions. That habit of converting experience into knowledge is the same one behind how elite founders build knowledge systems.
Reading the source essays directly is part of this. Graham's full catalog, along with the founder stories behind Airbnb, Stripe, and Pinterest, rewards close reading. Highlighting the passages that map onto your own situation with Glasp's web highlighter lets you build a personal playbook you can return to. Many of the best founder lessons also live in talks and interviews, and YouTube Summary by Glasp turns an hour-long YC lecture or founder interview into a timestamped summary you can highlight in minutes.
As your own unscalable phase generates notes from user conversations, Glasp's AI chat lets you query that growing library, surfacing patterns across dozens of interactions that you'd never spot by memory alone. The unscalable work generates the data. A knowledge system turns it into decisions.
Frequently Asked Questions
Doesn't "do things that don't scale" contradict building a scalable business?
No, because it's about sequence, not philosophy. You do unscalable things at the start to find users, learn what to build, and create a core of people who love your product. Once you understand what works and demand exceeds what you can serve by hand, you build the scalable version. The unscalable phase is the research and ignition stage. Scaling comes after, built on what you learned.
How long should I keep doing things that don't scale?
Until manual effort can no longer keep up with demand, and until you've learned enough to automate confidently. There's no fixed timeline. Some startups do unscalable things for months, others longer. The signal to transition is when you have clear, repeated patterns in what users need and more demand than you can personally handle. Stopping too early means you automate the wrong things.
What if I'm an introverted technical founder who hates recruiting users?
Graham would call that shyness, gently. The discomfort is real, but it's also the toll for traction, and it's payable. You don't have to become a natural salesperson. You have to be willing to talk to a manageable number of specific people and make their experience great. Many famously introverted founders, including the ones in Graham's examples, did exactly this. It's a skill you build, not a personality you're born with.
Is this advice still relevant with AI and automated growth tools?
More than ever. AI can scale outreach and automate onboarding, which makes it tempting to skip the manual phase entirely. But automated growth still can't replace the learning that comes from personally watching real users struggle and succeed with your product. The tools change. The need to get close to your first users, understand them deeply, and delight them does not.
How is this different from just providing good customer service?
Good customer service is reactive and sustainable at scale. Doing things that don't scale is proactive, intense, and deliberately unsustainable. You're not just helping users who ask. You're recruiting them by hand, doing parts of their work for them, and engineering an experience so good it couldn't possibly continue at a million users. The unscalability is intentional, and the goal is learning and ignition, not steady-state support.
Conclusion: Fan the Fire by Hand
Paul Graham's most quoted advice survives because it names a truth founders desperately want to avoid: nobody is coming unless you go get them. The product won't market itself. The fire won't light on its own. You have to fan it by hand, user by user, until it's hot enough to burn without you.
The companies founders most admire all went through this phase. Airbnb's founders photographed apartments. The Collisons grabbed laptops. Pinterest's founder went to a conference of design bloggers to find his first users. None of it scaled, and all of it mattered, because that's where each company learned what it really was.
The deepest value isn't the users you get. It's the knowledge you gain while you're close enough to listen. Capture it. Highlight the founder essays and case studies that map onto your situation with Glasp's web highlighter, turn founder talks into searchable notes with YouTube Summary, and query everything you've learned with Glasp's AI chat. Do the unscalable work, and make sure it teaches you something. That's how startups take off, because the founders make them take off.