Gavel Gavel
Experts Guides Skills
Cited from real sources 6 min read Updated August 2026

A framework by Paul Graham

Paul Graham's Do Things That Don't Scale

Do Things That Don't Scale is Paul Graham's 2013 essay. It is the most-quoted piece of early-stage advice in Y Combinator's canon. Startups do not take off by themselves. At the start you recruit users one by one, by hand. You do the unscalable work that delights them. The work itself is not the point. The point is what doing it by hand teaches you.

What the essay actually solves

"The biggest problem that most startups have is they can't get users."

Not the architecture. Not the scalability. Founders optimize the thing that is not yet their problem.

YC partners on Paul Graham's essay Y Combinator Watch at 03:26

The framework

The startup that scaled itself never existed

A generation of founders absorbed the wrong lesson from Google. Google made scalability look like the whole game, technically and as a business model, and an industry of founders and investors started optimizing for it from day one. Graham's 2013 essay was the counter-argument. The thing that kills most early companies is not that they cannot scale. It is that nobody is using the product, and the founders are polishing architecture for a load that does not exist.

The reframe is to stop treating "it doesn't scale" as a disqualifier. In the beginning, the unscalable thing is usually the only thing that works. You recruit users one at a time. You do their setup for them. You go physically stand where they are. None of that survives contact with a million users, and that is fine, because you do not have a million users. You have ten, and ten is the problem to solve right now.

The canonical example is Airbnb. The founders had an idea, no users, and a flywheel that would not turn. So they went door to door in New York and took professional photos of hosts' apartments themselves. Photography is not a scalable feature of a marketplace. It was the unscalable act that made the early listings good enough that the marketplace started to move.

Do Things That Don't Scale is not a license to avoid building a real company. It is a sequencing claim: the manual, embarrassing work comes first because it is the fastest way to learn whether you are making something people want. Automation is a reward you earn after the learning, not a substitute for it.

How to apply it

How do you actually do things that don't scale?

Five moves, ordered. Each one is something a later-stage company would never let you do, which is exactly why it works now.

  1. 1

    Recruit your first users by hand.

    Startups do not take off on their own. Go find the first ten users individually: email them, message them, meet them. If you cannot name the next ten people who should use this, you do not have a distribution problem yet, you have a who-is-this-for problem.

  2. 2

    Do the unscalable work that delights them.

    Set the product up for them. Take the photos. Do the data entry. Airbnb's founders shot listing photography by hand because that was what made the listings good. Whatever the equivalent embarrassing manual task is for you, do it yourself before you automate it away.

  3. 3

    Take the work that feels beneath you.

    The manual outreach, the support tickets, the admin. Founders who delegate this early lose the one feed of raw signal that tells them what the product should become. The unglamorous work is where the insight is, not despite being unglamorous but because nobody else is paying that close attention.

  4. 4

    Optimize every interaction for learning.

    The point of doing it by hand is not heroics. It is that every manual setup, every support conversation, teaches you what to build next. Ask of each unscalable thing: what did this teach me that a dashboard would not have?

  5. 5

    Use the learnings to justify scaling, then stop.

    The unscalable phase ends. Once you understand the customer well enough to know what to automate, build the scalable version, and resist the trap of staying in lucrative manual work, like custom consulting, that quietly turns you into a service business instead of a startup.

The Airbnb guys would go out and do that, and that was clearly something that did not scale. That's what got them that flywheel turning early on.
YC partners on the Airbnb example Watch at 06:29

The photography did not survive into the scaled company. It did not need to. It existed to get the flywheel turning; once it was, the scaffold came down.

The core move

How do you recruit users manually?

You recruit users manually by going to a specific person who already has the problem, asking them to try it in front of you, and setting it up yourself instead of sending a signup link. Graham's claim is that nearly every startup has to do this, because the alternative, waiting for users to arrive, describes a company that already has distribution. Three plays from YC founders, each a different answer to the same question.

Install it for them, in their codebase

Watch at 10:32

Stripe's founders implemented their API directly inside their customers' software. Algolia copied the play: their first Product Hunt integration was Algolia's own team writing the search implementation as a pull request, because the founder had no resource to build it himself. The customer gets something they could not otherwise have had, and you get a relationship candid enough to ask anything afterward.

Fake the backend until someone wants it

Watch at 18:47

DoorDash's first version was built in an afternoon: menus uploaded to Google Drive, a static page of HTML and CSS, orders taken on a Google Form, a co-founder's personal phone as the hotline, and Find My Friends standing in for real-time driver dispatch. The team had Stanford engineers and could have built the real thing. They did not, because the open question was demand, not dispatch.

Go where they physically are

Watch at 06:29

Airbnb's founders went door to door in New York, signing up hosts and improving the listings they already had. The unscalable act was not a growth hack, it was the only way to see what a good listing looked like before anyone could have told them.

the founders were very pragmatic that was not the hardest thing to prove out it was like is this even a thing that people wanted
YC partners on why DoorDash faked the hard parts Watch at 19:48

The common thread is not effort, it is sequencing. Each team spent its manual work on the one question that would kill the company if the answer was no, and faked everything else.

Boundary conditions

When it works, when it fails

Works best when

  • You are pre-traction with few or no users and need the flywheel to start turning
  • The product needs a human to make the early experience good enough
  • You can personally do the unscalable work and extract the learning from it
  • You treat the manual phase as temporary scaffolding, not the company

Fails when

  • You never exit the manual phase and ossify into a service business
  • The unscalable work drifts into custom consulting that cannot grow 10x
  • You delegate the manual work and lose the learning it was there to produce
  • You use it as an excuse to avoid building the real product at all
The biggest problem that most startups have is they can't get users and they're not making something people want.
YC partners on what Graham realized Watch at 03:26

The honest tension lives between the two columns. The same manual work that gets the flywheel turning becomes the thing that traps you if you never stop. YC pushes hard growth targets partly to force the question: can this grow 10x, or have you quietly built a consultancy that happens to have a login screen?

The sources

Where YC breaks down Graham's essay

00:11
Timestamp

Y Combinator · Doing Things That Don't Scale

The origin of the essay

In 2013 Paul Graham, the founder of Y Combinator, wrote an essay entitled Do Things That Don't Scale, and this essay transformed the culture.
03:26
Timestamp

Y Combinator · Doing Things That Don't Scale

What Graham actually realized

The biggest problem that most startups have is they can't get users and they're not making something people want.
06:03
Timestamp

Y Combinator · Doing Things That Don't Scale

Why Airbnb inspired it

What inspired him with this was the Airbnb guys. They'd been working on that idea for a while, had no users, and they needed to get the flywheel turning.
06:29
Timestamp

Y Combinator · Doing Things That Don't Scale

The unscalable act that worked

The Airbnb guys would go out and do that, and that was clearly something that did not scale. That's what got them that flywheel turning early on.

Common questions

Do things that don't scale, answered

What does "do things that don't scale" actually mean?

It means the manual, unglamorous work you do before automation is worth building: recruiting users one at a time, setting the product up for them yourself, handling support personally. Graham's argument is that startups do not take off on their own, and the manual phase is what teaches you what to automate later.

How do you recruit users manually?

Go to a specific person who already has the problem and get them using it in front of you rather than sending a link. Stripe implemented its API inside customers' codebases; Airbnb's founders went door to door in New York. The play is whichever version removes the work standing between that person and the value.

Is doing things that don't scale still relevant?

The mechanic has not changed, though the surface has. Manual recruitment now happens in DMs, communities, and one-to-one calls rather than door to door. What stays constant is that the first users have to be pulled in individually, and that the pulling is where the product learning comes from.

When do you stop doing things that don't scale?

When you understand the customer well enough to know what to automate, and not before. The failure mode on the other side is staying in lucrative manual work, custom builds and consulting, until you are running a service business rather than a startup.

Where experts disagree

Where operators disagree: build the product first, or the audience?

Paul Graham

says startups do not take off by themselves, so you recruit your first users one by one, by hand, and do the unscalable work that delights them, the way Airbnb went door to door. The manual work is what teaches you what to build.

Greg Isenberg

says distribution first, product second. When AI makes building nearly free the code is commoditised and the moat is an audience, so grow one to about a thousand people, ask them what they need, and build into a warm market.

Isenberg wins in commoditised categories where your audience is your buyer. Graham wins when the product needs a human touch to be any good and ten real users teach you more than a thousand followers.

Useful? Pass it to a founder who is automating before anyone is using it.

Want the full playbook?

Get 329 execution & shipping frameworks.

49 frameworks 97 rules 175 heuristics & principles 7 operators

From Basecamp (DHH & Jason Fried), Jake Knapp, BJ Fogg, and 4 more. Drop one .md into Claude, Cursor, or ChatGPT. Your AI cites practitioners, not guesses.

See the pack

Instant .md download · One-time purchase · No subscription

Related frameworks

Shipping

The Fogg Behavior Model

Bj Fogg

Motivation, ability and a prompt must converge. When a behavior fails, check the prompt first and motivation last.

Shipping

Make Time

Jake Knapp

Pick one Highlight a day, not a longer to-do list. Getting faster at the inbox only refills it, so name what the day is for and defend one block.

Shipping

Kill Criteria

Annie Duke

Name the signals that mean stop before you launch, and attach an action to each one while you still have no stake in the answer.

Shipping

Launch-Jankiest Rule

Garry Tan

Ship the jankiest MVP that still provides value. If users tolerate it, the problem is real.