October 2008. New York. Brian Chesky and Joe Gebbia knock door to door at the homes of Airbnb's first hosts, a borrowed camera in hand, to shoot the listings. The listings convert 3x better within the week. Five years later, in July 2013, Paul Graham gives the tactic a name in a 4,346-word essay: Do Things that Don't Scale. The idea contradicts everything founders are told: for a startup to take off, you have to start with things that are structurally impossible to reproduce, expensive in founder time, and that no pitch slide ever shows. Recruit your users one by one, show up wherever they are, over-deliver, beg for referrals, do by hand what you'll automate later. Here are the five canonical tactics, fifteen documented cases, the 2026 version, and the one question the essay never addressed: when to stop.
What does "do things that don't scale" actually mean?
The phrase comes from a Paul Graham essay published in July 2013, after hundreds of YC batches kept making the same mistake: build a product, open the app store, wait for organic growth. It never comes. Not unless the founders go out and get it manually, one transaction at a time.
"Startups take off because the founders make them take off." (Paul Graham, 2013)
The paradox is head-on. Your entire product is supposed to scale. Serverless stack, SaaS CRM, performance-marketing acquisition. The first thing to do is the opposite: manual, individual, expensive work. Not out of nostalgia. Out of necessity.
Two clarifications on what this is not. It isn't a forever strategy, it's a phase. Sometimes a long one (HyperSpectral runs white-glove service at $3.5M ARR), sometimes a short one (six months for Stripe). The pattern isn't "never automate," it's "don't automate before you understand what you're automating." Nor is it an excuse to skip building a product. Pebble assembled its watches by hand, but Pebble had a product. Stripe set up merchant accounts by hand, but Stripe had an API.
Why your startup depends on it (the 3 real reasons)
1. You don't have organic growth yet. Nobody's coming.
At launch, your signup curve looks like a flat line. Not because your product is bad. Because nobody knows you exist. "Build it and they will come" never worked outside of a Kevin Costner movie. You have to go get your first ten users by hand. Then the next hundred.
2. You don't know what works. Manual = disguised user research.
As long as you code in isolation, you're projecting. You imagine your users' frustrations. The moment you set up the product for a customer by hand, you see where it snags, which words they use, what they miss. That information doesn't come from a dashboard or a 50-question survey. It comes from watching someone click.
3. Your startup is fragile. These 30 days can change everything.
Paul Graham puts it in black and white: "Almost all startups are fragile initially." That fragility has an expiration date. The 30 days Chesky and Gebbia spent in NYC shooting listings made the difference between Airbnb and a project buried in the YC startup graveyard.
The 5 canonical tactics (Inari sheet taxonomy + PG essay)
Frank Cretella, founder of Inari (YC S23), open-sourced a compilation of 86 startups that did things that don't scale, and classified them. Cross-referencing his taxonomy with the seven patterns Paul Graham identified gives you five canonical families.
1. Recruit manually (PG pattern "Recruit")
Every startup goes through it. The question isn't "should we do it?" but "how far into the discomfort will you go?"
DoorDash is the textbook case. Tony Xu and his co-founders, at Stanford, built a landing page called PaloAltoDelivery.com in a single afternoon. They pasted in PDF menus found online and their cell number at the bottom of the page. When the phone rang for a Thai food order, they jumped in the car. Before that, they had talked to 150 to 200 small-business owners to validate the problem (source: Sam Altman, Startup Class lecture 8).
Stripe: Patrick and John Collison installed Stripe themselves on the laptops of their first merchants. No "sign up here," no self-service dashboard. Paul Graham calls it the "Collison installation," which became an internal YC expression.
Levels.fyi pushed manual to an improbable place: their initial version had no backend. The entire infrastructure ran on Google Sheets. Today the site gets 1 to 2 million unique visitors per month.
2. Physically go where your users are (Inari pattern "Go directly")
You can wait for your users to come to you. They won't. Move.
Tinder is the most emblematic case. Alexa Mateen Abdi, on the founding team, toured the sororities and fraternities at USC, microphone in hand, sometimes standing on a piano in a frat house. She then codified the method into the "Tinder University Program" to replicate it: SMU, UT Austin, UCLA. Each campus, a human who shows up, runs a demo, and counts the downloads in real time.
Pinterest ran design meetups around the Bay. Etsy went to craft fairs. Bumble copied Tinder in lecture halls. The pattern: go where your audience is already gathered, rather than aggregating it through paid ads.
3. Over-deliver (personalize to the point of absurdity) (Inari pattern "Insanely delightful")
Nobody forgets excessive service. And "excessive" is the operative word.
Substack did manual 1-to-1 onboarding with every writer who opened an account. A human, on video, showing how to set up a newsletter. At 50 writers, that's what changed everything.
Algolia DocSearch: the team configured search itself for every open-source project that asked. By hand. For every project. Algolia became the de facto standard for tech docs.
HyperSpectral, at $3.5M ARR, still maintains white-glove onboarding today. CEO Matt Theurer owns it: "We still do a lot of white glove service. We'll set up the account for them, help them write their questions, train their team." On paper, it wrecks the unit economics. In reality, the feedback loop it produces informs the entire product roadmap. It's their competitive edge.
4. Ask for help and referrals (Inari pattern "Ask for help")
Nobody does it. That's exactly why it works.
Lyft based its early growth on pure referral: "shares with friends," referral codes, cash bonuses on both sides. Without it, no critical mass of drivers. Derek Sivers (CD Baby) personally answered 6,000 emails in 10 days at launch. Not an autoresponder. Not a VA. Him. Every email. Guess how many of them told the people around them about CD Baby.
5. Do by hand what you'll automate later (PG patterns "Manual" + "Consult")
The most misunderstood tactic: it looks like weakness when it's actually strategy.
Stripe, again. Early on, Stripe advertised "instant merchant accounts." The reality: the founders manually configured accounts with traditional processors in the background. The user saw software. It was a human.
Pebble: before its $10 million Kickstarter, Eric Migicovsky and his team assembled the first few hundred watches by hand. In a garage. Paul Graham recounts that Eric took away an unexpected lesson: "how valuable it was to source good screws." Nobody would have guessed that from a Gantt chart.
Meraki (the origin of the YC verb "to pull a Meraki") built its routers by hand before being acquired by Cisco for $1.2 billion.
Viaweb, Paul Graham's startup: when merchants refused to build their store with Viaweb, the team would answer "OK, we'll build it for you." PG admits they felt pretty small ("we felt pretty lame at the time") selling luggage and shirts on behalf of others. That's what gave Viaweb the product sensibility that led to the Yahoo acquisition in 1998.
Pandora: their music recommendation was initially human. A dozen musicians listened to songs one by one, assigned a score, and Will Glaser, founding CTO, wrote an Excel macro that computed the distance between each song. A year later, 10,000 songs were indexed. By hand.
How to actually apply it in 2026 (tutorial mode)
Recruit manually today
LinkedIn Sales Navigator to identify your first 100 prospects by ICP. Apollo or Clay to enrich the emails. A sequencer (Lemlist, Smartlead, Instantly) to send three personalized touches. And above all: a 90-second Loom per prospect, with their first name on screen. It's the 2026 equivalent of Chesky's door-to-door. Marginal cost: 3 minutes per prospect. ROI: a reply rate that jumps from 2% to 25%.
Go where your users are in 2026
Three channels. First, the Discords and Slacks where your ICP gathers. You don't pitch. You contribute for 60 days, then mention what you're building in passing. Second, Reddit. r/SaaS, r/startups, r/marketing concentrate your future early users. Be useful before you sell. Third, physical meetups. Lu.ma has replaced Eventbrite for tech-founder events. Go. Bring your cards.
Over-deliver in 2026
A personalized Loom for every new signup (day 0). A Slack Connect or WhatsApp message on day 7. A video check-in on day 30. You do it as long as you're below 100 active users. Beyond that, you improvise (a generic recorded Loom, but with a human who answers the questions).
Manual / Wizard of Oz in 2026
Zapier + Airtable + Slack for routing. Notion API for storage. n8n if you want to self-host. A human in the loop in the middle, validating each critical action. This is what's called a concierge MVP or a Wizard of Oz. The user sees an interface, behind it you're working. The time it buys you to understand what to automate is exactly what you need.
Consult-to-product in 2026
A single paying design partner. An 8-week contract. You code the features in their context. The learnings become your roadmap. It's a trap (see the next section) but also the fastest way to reach product-market fit in vertical B2B.
The 5 mistakes that turn "unscalable" into "unrecoverable"
The Inari sheet lists the cases. The PG essay gives the patterns. No source covers the wrecks. Five signals that you're doing the wrong version of the pattern.
Mistake 1. You're billing for your time. You've become an agency.
Paul Graham writes the key line: "Consulting is the canonical example of work that doesn't scale. But it's safe to do it so long as you're not being paid to." The moment the client pays for your time by the hour, they're buying your time. They're no longer buying your product. You're no longer understanding a user in order to produce a feature. You're filling a job description.
Mistake 2. Your manual churn is artificially low.
You're holding your users up at arm's length. Every incident, a video call. Every ticket, a feature coded overnight. Reported churn: 1%. Real churn without the founder effort: 30%. You're measuring your cargo cult, not your product.
Mistake 3. Founder time-to-value exceeds 1 hour per user.
When each user needs more than an hour of your personal time to become productive, and you have even a dozen to serve, you've lost your product week. Manual informs the product. It doesn't replace it.
Mistake 4. Your cases are too heterogeneous to productize.
You've signed ten users, each using your product for a completely different use case. No common feature emerges. That's ten mini service projects. To make a pattern emerge, you need one tight ICP, not ten paying ICPs picked at random.
Mistake 5. You're delaying automation out of comfort, not strategy.
Manual gives warm, gratifying feedback. Every customer conversation feeds you. If you stay manual because you enjoy being manual, you'll never decide to automate. That's an addiction to feedback, not a strategy.
When to stop? Brian Chesky's rule
Brian Chesky coined the most-quoted rule: "Do it until it hurts, then automate it away." Four concrete signals that it's time:
Signal 1. Your manual LTV/CAC has crossed your target LTV/CAC. If each manual user costs $5,000 in founder time and pays $10,000/year, it looks horrible. But if manual retention gives you 95% at 36 months versus 60% self-serve, the math flips. That's the HyperSpectral case at $3.5M ARR.
Signal 2. The founder no longer has zero hours for the product. If you're starting to code a new feature again, it means you've disengaged from manual. That's fine, as long as you've handed off manual to someone who does it with the same intensity.
Signal 3. Churn becomes stochastic. At the start, you understand every churn (you were there). Beyond a certain volume, you lose the context of each departure. That's the signal to set up real analysis.
Signal 4. You've made your first ops/CS hire. You've decided to pay someone to do what you were doing for free. That's the moment to break the process into formal steps, otherwise you're handing them your exhaustion, not your method.
The anti-pattern: jumping from all-manual to all-automatic in one move. The pattern that works is what Matt Theurer calls the "manual co-pilot": human plus automation, where the human stays on the 10% that produces 90% of the insight. HyperSpectral at $3.5M ARR keeps part of its onboarding manual, by strategy, not by default.
FAQ
How long should the "unscalable" phase last?
As long as you learn more by hand than from a dashboard. In practice: between 6 months (fast consumer SaaS) and 3-5 years (vertical B2B). Stripe ran its Collison installation for about 18 months. HyperSpectral still does it at $3.5M ARR. The criterion: as long as manual produces product signal, don't stop it.
Does doing things that don't scale work for B2B too?
Yes, and that's actually where it's most effective. Paul Graham calls it the "Consult" pattern. You take a single design partner, you build the product in their precise context, and you extrapolate. The golden rule: don't get paid by the hour, or you become an agency (see Mistake 1).
And for hardware?
The PG pattern is called "pulling a Meraki." You assemble your first few hundred units by hand. Pebble did that before its $10 million Kickstarter. Hidden advantage: you can iterate the design faster because you are the factory. Eric Migicovsky discovered that screw quality mattered. You won't find that in a Gantt chart.
How do you measure the effectiveness of an unscalable tactic?
Not with standard business metrics. You measure: (1) the number of product insights generated per week, (2) the founder time per active user, (3) the manual vs self-serve conversion rate when you test them in parallel. If manual doesn't produce more insights than your analytics, stop.
What's the original Paul Graham essay?
The essay Do Things that Don't Scale was published in July 2013 on paulgraham.com. It runs 4,346 words and is still available at its original URL: https://www.paulgraham.com/ds.html. Y Combinator publishes a copy on its Startup Library.
Going further
Paul Graham's original essay: https://www.paulgraham.com/ds.html. The list of 86 cases compiled by Frank Cretella (Inari, YC S23): https://useinari.com/blog/the-definitive-list-of-startups-doing-things-that-didnt-scale. The HyperSpectral case in detail on Frontlines: https://www.frontlines.io/hyperspectrals-white-glove-onboarding-at-scale-when-things-that-dont-scale-actually-do/.
If you're launching and looking to structure your approach, our guide to finding a startup idea picks up where this article leaves off. To dig into the methodology, the definition of the lean startup explains why manual is really disguised user research. And if you're at the point of recruiting your first CTO, our startup CTO guide explains why the founder who talks to users is worth a well-recruited CTO.
