Business thinker

Paul Graham's Do Things that Don't Scale

Updated 4 November 2026

Not affiliated with or endorsed by Paul Graham or their companies.

Paul Graham started Y Combinator in 2005 with Jessica Livingston, Robert Morris and Trevor Blackwell, and has published essays on paulgraham.com since 2001. In Do Things that Don't Scale (July 2013) he argues that startups take off because their founders push them at the start, by doing laborious things that wouldn't work at a larger size: recruit users by hand, make early users extraordinarily happy, start in a deliberately narrow market, and do by hand what you will automate later, rather than count on a big launch. This page explains the essay and shows how to turn it into a plan for your first users.

Startups take off because founders make them

The essay opens against the idea that a startup either takes off by itself or doesn't. Graham writes that a few may grow on their own, but usually it takes a push, and compares that push to the hand crank that car engines needed before electric starters.

The push most founders need is to recruit users manually. Two things hold founders back, according to the essay: preferring to build rather than talk to strangers, and the small absolute numbers at first. On the second, the essay points to compound growth and encourages measuring progress by weekly growth rate. In Startup = Growth (September 2012) he explains that Y Combinator measures growth per week, partly because early startups need frequent feedback from users, and advises picking a growth rate you think you can hit and trying to hit it every week.

To find whom to recruit, the essay suggests a fairly untargeted first launch, then watching which users are most enthusiastic and seeking out more like them.

Delight early users, and make being a user extraordinary

Graham says to take extraordinary measures not just to get users but to make them happy, and gives the example of a company that sent each new user a hand-written thank-you note. Being small is an advantage here: a small company can give a level of service no big company can.

He then shifts the standard of quality: "It's not the product that should be insanely great, but the experience of being your user." An early, incomplete product can still give users an extraordinary experience if the founders make up the difference with attention. The essay calls over-engaging with early users "a necessary part of the feedback loop that makes the product good."

A small example: a bookkeeping app for hair salons has a slow setup. The founders visit each new salon, enter the services and prices themselves and call a week later. That doesn't scale, but it gets salons through setup and shows the founders what the setup screen gets wrong.

Start narrow: the contained fire

Sometimes the right unscalable move is a deliberately narrow market, which the essay compares to keeping a fire contained at first so it gets really hot. Its example is Facebook starting only for Harvard students. The question to ask is whether there is a subset of the market where you can get a critical mass of users quickly. In a note, Graham adds that when choosing between the group that signs up quickest and the group that pays most, the first is usually better, because those are probably the early adopters.

Work closely, and do it by hand first

For business software, the essay suggests picking a single user and building something just for them, as a consultant would; the first user is the mould, and what fits them usually fits others. Graham describes doing this at Viaweb, the company he started with Robert Morris in 1995, by building online stores for merchants who wouldn't build their own, which taught the team how the software felt to use.

A step further is to be the software: with few users, do by hand what you plan to automate. The essay's advice is to solve the problem manually for as long as you can, then gradually automate the bottlenecks; you will know exactly what to build because you did it yourself.

Why the big launch usually doesn't work

Graham writes that the Big Launch is one tactic that usually doesn't work: "All you need from a launch is some initial core of users." How you are doing a few months later depends more on how happy you made those users than on how many there were. Partnerships with big companies, he says, also usually don't work as a way to get growth started.

He ends by suggesting that a startup idea be thought of as a vector: what you are going to build, plus the unscalable things you will do at first to get going, usually recruiting users by hand and giving them an overwhelmingly good experience. An idea where the second part is empty, because there is no way to find users to recruit by hand, is probably a bad idea, at least for those founders.

How to apply it to your own launch

1. Write your idea as a vector: what you build, and what you will do by hand to get going.
2. Name the narrowest group where you could reach critical mass quickly.
3. List the people and places in that group, and the first in-person or one-to-one action for each.
4. Decide what each new user gets from the founders that a big company couldn't give.
5. Mark the steps you will do by hand for now, and when you will automate each.
6. Question any plan that depends on a big launch or a big partner.
7. Pick one number, track its growth every week, and review it every week.

What the sources say, and what they don't

Everything above comes from two of Paul Graham's essays, cited by title and date, and the facts about him from his bio page; the company stories are the essay's own examples. The essay is written for startups that aim to grow fast; applying it to a small business that doesn't aim for that, the salon example, and the planning steps are our adaptation. Quotes are short and taken from the essay as published on paulgraham.com.