AI Skill Pod

Thinkers' principles

Paul Graham-style unscalable launch plan

Official

Official · updated Nov 4, 2026 · v1.0.1

Turns a product idea into a plan for its first users from Paul Graham's essay Do Things that Don't Scale: a narrow start, users recruited by hand, manual steps, no big launch, weekly growth.

Sign up free to add this skill to your pod

You come back here after you sign in, and add it with one click.

Sign up freeAlready have an account? Sign in

When to use it

What you give it

What you get

The idea as a vector, a narrow starting group, a recruit-by-hand list, the early-user experience, manual steps with automate-when triggers, cuts, and one weekly measure.

The SKILL.md

---
name: paul-graham-style-unscalable-plan
description: Turns a product or business idea into a plan for its first users using the advice in Paul Graham's essay Do Things that Don't Scale (July 2013) - treat the idea as a pair of what you build plus the unscalable things you do to get going, recruit users by hand, start in a deliberately narrow market where you can reach critical mass, make the experience of being an early user extraordinary, work closely with one user as if building just for them, do by hand what you will automate later, skip the big launch and the big partnership, and track weekly growth. Use when a founder or team is about to launch, has a product but few users, is waiting for users to arrive on their own, is planning a big launch or partnership to get growth started, or asks how to get the first customers or what to do that doesn't scale.
---

# Paul Graham-style unscalable launch plan

These are principles Paul Graham has described publicly in his essays, mainly "Do Things that Don't Scale" (July 2013) and "Startup = Growth" (September 2012). Not affiliated with or endorsed by Paul Graham or their companies. The skill reviews the user's launch plan against the essay's advice and turns it into a concrete plan for the first users: who, how they are found, what is done by hand, and how growth is measured week by week.

## Ground rules

- Do not attribute quotes or opinions to Paul Graham beyond the cited sources.
- Do not role-play, imitate, or write in the voice of Paul Graham; review the user's material against the principles below.
- Use the user's own numbers. Never invent user counts, growth rates or conversion rates; mark gaps "[check: ...]".
- The essay is written for startups that aim to grow fast. For a business that doesn't aim to grow fast (a studio, a local shop), say which principles still fit and which don't.
- Doing things by hand must stay honest with users: never propose misleading anyone about what they are paying for, and respect privacy and consent when contacting people.
- Company examples from the essay (Stripe, Airbnb, Facebook and others) are the essay's; don't add claims about those companies beyond it.

## The principles

1. **Startups take off because founders push them.** Few grow by themselves; the essay compares the early push to the hand crank on early car engines. Source: "Do Things that Don't Scale", July 2013, opening section.
2. **Recruit users manually.** The most common unscalable thing founders do at the start is to recruit users by hand rather than wait for them; the essay describes founders setting people up on the spot instead of sending a link. Find the most promising group by watching which early users are most enthusiastic, then seek out more like them. Source: same essay, "Recruit" and "Fragile".
3. **Small numbers compound; measure weekly growth.** Founders dismiss manual recruiting because the absolute numbers look small, underestimating compound growth; the essay encourages measuring progress by weekly growth rate. "Startup = Growth" explains why Y Combinator measures growth per week and, in its "Compass" section, advises picking a growth rate you think you can hit and trying to hit it every week. Source: same essay, "Recruit"; "Startup = Growth", September 2012.
4. **Delight early users.** Take extraordinary measures to make early users happy; being small lets you give a level of attention no big company can. The essay's example is a company that sent each new user a hand-written thank-you note. Source: same essay, "Delight".
5. **The experience, not just the product.** In a new startup it is the experience of being a user that should be extraordinary, and attentiveness can make up for an early, incomplete product. Engaging directly with early users is part of the feedback loop that makes the product good. Source: same essay, "Experience".
6. **Start with a contained fire.** Sometimes the right move is a deliberately narrow market where you can reach critical mass quickly, then widen. When choosing between the subset that signs up quickest and the one that pays most, the essay says the former is usually best. Source: same essay, "Fire" and note 8.
7. **Work for one user like a consultant.** For B2B, pick a single user and build something just for them; the first user is the mould, and what fits them often fits others. Don't get paid by the hour for it. Using your own software on users' behalf teaches you how it feels to them. Source: same essay, "Consult".
8. **Be the software, then automate the bottlenecks.** With few users, do by hand what you plan to automate, then automate gradually; you'll know what to build because you did it yourself. Source: same essay, "Manual".
9. **No big launch, no big partnership.** All you need from a launch is an initial core of users; how you are doing months later depends more on how happy you made them. Partnerships with big companies usually don't get growth started. Source: same essay, "Big".
10. **An idea is a vector.** Think of an idea as a pair: what you will build, plus the unscalable things you will do at first to get going, usually recruiting users by hand and giving them an extraordinary 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. Source: same essay, "Vector" and note 12.

## When to use

- Before a launch, to replace "launch and see" with a plan for the first users.
- A product that works but has few users, and a team waiting for them to arrive.
- A plan that relies on one big launch day, press coverage or a large partner.
- Deciding which narrow group to start with.
- Not for a mature product's growth programme (use experiment-plan or positioning-statement), and not for unit economics (use unit-economics-check).

## What you need

- What you are building, in a sentence, and who it is for.
- Current users or customers, if any, and how each one found you.
- The current launch plan.
- Where your likely early users gather, online or offline, and whether you can reach them yourself.
- What part of the product could be done by hand for now.
- Any weekly numbers you have (sign-ups, active users, revenue).

## Steps

1. **Write the vector (principle 10).** Component one: what you build. Component two: what you will do by hand to get going. If component two is empty, stop and say so plainly; that is the essay's warning sign.
2. **Pick the contained fire (principle 6).** Name the narrowest group where you could reach critical mass quickly, how many of them there are, and why they would feel the product is for them. Prefer the group that signs up quickest over the one that pays most, unless the user's case says otherwise.
3. **List who to recruit by hand (principle 2).** Ten to thirty named places or people (communities, events, past customers, peers) and the exact first action for each: a visit, a call, a setup session. Replace "send a link" with "set them up together".
4. **Design the early-user experience (principles 4 and 5).** What each new user gets from the founders that a big company couldn't give: a personal onboarding, a direct line, a note, a fix shipped the same day. Name who does it and how much time it takes per user.
5. **Choose one user to build for (principle 7).** For B2B, the one user whose needs you will fit closely, and what you will learn by using the product on their behalf.
6. **Mark what stays manual (principle 8).** Each step you will do by hand now, its time per user, and the number of users or hours per week at which you will automate it.
7. **Cut the big bets (principle 9).** List any big launch, press push or partnership in the plan, and what to do instead with that time.
8. **Set the weekly measure (principle 3).** One number (revenue if there is any, otherwise active users), its current value, a weekly growth target the team thinks it can hit, and a weekly review.

## Output format

```markdown
# Unscalable launch plan: [product]
These are principles Paul Graham has described publicly in "Do Things that Don't Scale" (July 2013) and "Startup = Growth" (September 2012). Not affiliated with or endorsed by Paul Graham or their companies.

## The vector
Build: [what]. Do by hand: [what]. [Warning if the second part is empty]

## Contained fire
[Group], about [n] people [or check], because [why it is theirs].

## Recruit by hand
| Where / who | First action | Who on the team | By when |
|---|---|---|---|

## Early-user experience
| What each new user gets | Who does it | Time per user |
|---|---|---|

## One user to build for
[Who, what you will fit, what you will learn]

## Manual now, automate later
| Step done by hand | Time per user | Automate when |
|---|---|---|

## Cut or postpone
[Big launch / partnership items and what replaces them]

## Weekly measure
[Number], now [x], weekly target [y], reviewed [day].

## Principles used
[Numbered, with essay and section]
```

## Example

**Input:** "We built a booking and reminder tool for independent hair salons. 4 salons use it, all friends of my co-founder. Plan: launch on a big product directory next month and try to partner with a salon supply chain. Our onboarding is a sign-up form; reminders are sent by our code but setting up the salon's services takes them an hour and most quit."

**Output (excerpt):**

```markdown
These are principles Paul Graham has described publicly in "Do Things that Don't Scale" (July 2013) and "Startup = Growth" (September 2012). Not affiliated with or endorsed by Paul Graham or their companies.

## The vector
Build: booking and reminders for independent salons. Do by hand: set up each salon's services and staff ourselves, in the salon, and check in weekly.

## Contained fire
Independent salons in one district of one city [check: count], where owners know each other and can see the tool working at a friend's salon.

## Recruit by hand
| Where / who | First action | Who on the team | By when |
|---|---|---|---|
| Owners the 4 current salons know | Ask each current owner for two introductions | Co-founder | This week |
| Salons on the main street of the district | Visit in person on a quiet weekday morning, set up on the spot if they say yes | Both founders | Next two weeks |

## Manual now, automate later
| Step done by hand | Time per user | Automate when |
|---|---|---|
| Entering services, prices and staff | About 1 hour [from input] | When setups take more than [check: hours] a week |

## Cut or postpone
The directory launch and the supply-chain partnership. The essay says a launch only needs to bring an initial core of users, and big partnerships usually don't start growth; spend that month on the district.

## Weekly measure
Active salons, now 4, weekly target [set by the team], reviewed every Monday.
```

## Checks

- [ ] The attribution and not-affiliated lines are in the output.
- [ ] The vector has both parts, or the plan says plainly that the second part is empty.
- [ ] The starting group is narrow and named, with a reason it is theirs.
- [ ] Recruiting is by hand, with named places or people and first actions.
- [ ] Every manual step has an automate-when trigger.
- [ ] Any big launch or partnership is questioned, with the essay's reason.
- [ ] One weekly number with its current value; no invented figures.

## Common mistakes

- Treating "do things that don't scale" as permission to stay manual forever; the essay says to automate the bottlenecks gradually.
- Picking a broad market because it looks bigger, instead of a group that can reach critical mass.
- Counting total sign-ups instead of weekly growth.
- Copying the essay's company stories as tactics without checking they fit the user's market.

Download SKILL.md

Changelog

Sources

  1. Do Things that Don't Scale, Paul Graham, July 2013 (2026-11-04)
  2. Startup = Growth, Paul Graham, September 2012 (2026-11-04)

Related skills

← All skills