In October 2008, in New York, Brian Chesky and Joe Gebbia went door to door to Airbnb's first hosts with a borrowed camera to photograph their listings. The next week, those listings started converting better. Five years later, in July 2013, Paul Graham gave the tactic a name in a 4,346-word essay: Do Things that Don't Scale. The idea contradicts almost everything founders get told. To make a startup take off, you have to start with things that are structurally non-repeatable, expensive in founder time, and invisible on any slide. That means recruiting users one by one, showing up where they are, delivering more than you promised, asking hard for referrals, and doing by hand what you'll automate later. This guide covers the five canonical tactics, fifteen documented cases and the 2026 version, and then takes on the one question the essay never addressed: when to stop.
What does "do things that don't scale" mean?
The expression comes from an essay Paul Graham published in July 2013, after watching startups across hundreds of YC batches repeat the same mistake: build a product, launch on the app store, wait for organic growth. The growth never shows up 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 hard to miss. You design your whole product to scale: serverless stack, SaaS CRM, performance-marketing acquisition. Yet the first thing you need to do is the opposite: manual, individual, expensive work, because organic growth doesn't exist yet.
Two clarifications. First, it's a phase. Sometimes it's long (HyperSpectral still does white-glove onboarding at $3.5M ARR), sometimes short (Stripe stopped as soon as its self-service held up). The pattern is simple: you don't automate anything until you understand what you're automating. Second, the phase is no excuse for skipping the 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: three reasons
1. You don't have organic growth yet. Nobody is coming.
At launch, your signup curve is a flat line, because nobody knows you exist. "Build it and they will come" has never worked outside a Kevin Costner movie. You have to go get your first ten users by hand, then the next hundred. Until you reach product market fit, you'll be going after every single user yourself.
2. Manual work is user research in disguise
As long as you code in isolation, you're guessing. You imagine what frustrates your users. The moment you set up the product for a customer by hand, you see where they get stuck, which words they use, and what they miss. No dashboard or 50-question survey will tell you that. You learn it by watching someone click.
3. Your startup is fragile, and only for a short time
Paul Graham puts it in black and white: "Almost all startups are fragile initially." The window closes fast. Those weeks Chesky and Gebbia spent in New York photographing listings are what separate Airbnb from a project buried in the YC startup graveyard.
The 5 canonical tactics (Inari taxonomy and PG essay)
Frank Cretella, founder of Inari (YC S23), compiled an open-source list of 86 startups that did things that don't scale and sorted them into categories. Cross-reference his taxonomy with the seven patterns Paul Graham identified and you get five canonical families.
1. Recruit manually (PG pattern "Recruit")
Every startup goes through this. The only question is how much discomfort you're willing to put up with.
DoorDash is the textbook case. At Stanford, Tony Xu and his co-founders built a landing page called PaloAltoDelivery.com in a single afternoon. They pasted in PDF menus they found online and put their cell phone number at the bottom of the page. When the phone rang with an order for Thai food, they jumped in the car. Before any of 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 their first merchants' laptops. There was no signup button and no self-service dashboard. Paul Graham calls this the "Collison installation", and the phrase became part of YC's internal vocabulary.
Levels.fyi took manual work somewhere unexpected: their initial version had no backend. The entire infrastructure ran on Google Sheets.
2. Go physically to your users (Inari pattern "Go directly")
You can wait for your users to come to you, but they won't, so you have to go to them.
Tinder is the best-known example. Alexa Mateen Abdi, part of the founding team, toured USC's sororities and fraternities with a microphone, sometimes standing on a piano in a frat house. She then turned the method into the "Tinder University Program" so it could be repeated at SMU, UT Austin and UCLA. On every campus, someone showed up, gave a demo, and counted downloads in real time.
Pinterest hosted design meetups in the Bay Area. Etsy went to craft fairs. Bumble copied Tinder's playbook in lecture halls. In each case, the founders went where their audience already gathered instead of buying its attention with paid ads.
3. Deliver beyond what's asked (customize to the point of absurdity) (Inari pattern "Insanely delightful")
Nobody forgets excessive service, and "excessive" is exactly the right word.
Substack ran manual 1-to-1 onboarding with every writer who opened an account. A real person got on a video call and showed them how to set up their newsletter.
Algolia DocSearch: the team personally configured search, by hand, for every open-source project that asked for it. Algolia became the de facto standard for technical documentation.
HyperSpectral, at $3.5M ARR, still runs white glove onboarding today. CEO Matt Theurer is proud of 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 destroys unit margins. In practice, the feedback it generates feeds the entire product roadmap, and the team considers it a competitive advantage.
4. Ask for help and referrals (Inari pattern "Ask for help")
Lyft built its early growth entirely on referrals: "shares with friends", referral codes and cash bonuses on both sides. Without them, it would never have reached a critical mass of drivers. Derek Sivers (CD Baby) personally answered 6,000 emails in 10 days at launch. He wrote every reply himself, with no autoresponder and no assistant.
5. Do by hand what you'll automate later (PG patterns "Manual" + "Consult")
This is the most misunderstood tactic. It looks like weakness, but it's a strategy.
Stripe, again. Early on, Stripe advertised "instant merchant accounts." Behind the scenes, the founders were setting up accounts with traditional processors by hand. Users thought they were dealing with software, but a human was doing the work.
Pebble: before its $10 million Kickstarter, Eric Migicovsky and his team assembled the first few hundred watches by hand in a garage. Paul Graham says Eric came away with an unexpected lesson: "how valuable it was to source good screws." Nobody would have spotted that on a Gantt chart.
Meraki (the origin of the YC verb "to pull a Meraki") built its routers by hand before Cisco acquired it for $1.2 billion.
Viaweb, Paul Graham's own startup: when merchants wouldn't build their store with Viaweb, the team told them "OK, we'll build it for you." PG admits they felt pathetic ("we felt pretty lame at the time") selling luggage and shirts on other people's behalf. That experience gave Viaweb the product sense that led to its acquisition by Yahoo in 1998.
Pandora: its music recommendations started out human. A dozen musicians listened to songs one at a time and scored each one, and Will Glaser, the founding CTO, wrote an Excel macro that calculated the distance between songs. A year later, the team had indexed 10,000 songs by hand.
How to apply it in 2026 (tutorial)
Recruiting manually today
Use LinkedIn Sales Navigator to identify your first 100 prospects by ICP, then Apollo or Clay to enrich their emails. A sequencer (Lemlist, Smartlead, Instantly) handles three personalized touches. Above all, record a 90-second Loom for each prospect with their first name on screen. That's the 2026 version of Chesky's door-to-door, and it costs you about 3 minutes per prospect.
Meeting your users in 2026
There are three channels. The first is Discord and Slack communities where your ICP hangs out: don't pitch, contribute for 60 days, then mention what you're building in passing. The second is Reddit, where r/SaaS, r/startups and r/marketing are full of your future early users, so be useful before you try to sell. The third is in-person meetups. Lu.ma has replaced Eventbrite for tech events, so go, and come home with contacts.
Delivering beyond what's asked in 2026
Send a personalized Loom to every new signup on day 0, a Slack Connect or WhatsApp message on day 7, and set up a video check-in on day 30. Keep this up while you're under 100 active users. Beyond that, you adapt: a generic recorded Loom, with a real person answering questions.
Manual / Wizard of Oz in 2026
Zapier + Airtable + Slack for routing. The Notion API for storage. n8n if you want to self-host. In the middle sits a human in the loop who approves every critical action. This setup is called a concierge MVP or a Wizard of Oz. The user sees an interface while you do the work behind it, which buys you time to figure out what to automate.
Consult-to-product in 2026
Sign a single paying design partner on an 8-week contract, and build features inside their context. What you learn becomes your roadmap. It's a trap (see the next section), but it's also the fastest way to reach product-market fit in vertical B2B.
Five mistakes: from "unscalable" to "unrecoverable"
The Inari sheet lists the cases, and PG's essay lays out the patterns. What's missing are the failure modes: five signs you're running the wrong version of the pattern.
Mistake 1. You bill for your time. You've become an agency.
Paul Graham wrote 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." Once a client pays for your time by the hour, they're buying your time instead of your product. You stop studying a user to design a feature and start filling a job description.
Mistake 2. Your churn looks artificially low because you're doing everything by hand.
You're keeping your users on board through sheer effort. Every incident gets a video call. Every ticket gets a feature coded overnight. Reported churn stays low as long as you carry each account yourself, but it would climb the moment founder effort stopped. What you're measuring is your effort, and that tells you little about your product.
Mistake 3. Founder time-to-value exceeds 1 hour per user.
When every user needs more than an hour of your personal time to get productive, and you have even a dozen to serve, your week of product work is gone. Manual work is there to feed the product, never to replace it.
Mistake 4. Your use cases are too varied to add up to a product.
You've signed ten users, and each one uses your product for something completely different. No shared feature is emerging, so what you actually have is ten mini service projects. For a pattern to emerge, you need one tight ICP instead of ten random paying ones.
Mistake 5. You put off automation because manual work feels good
Manual work gives you warm, rewarding feedback, and every customer conversation energizes you. If you stay manual because you enjoy it, you'll never make the call to automate. At that point you're addicted to customer feedback.
When to stop? Brian Chesky's rule
Brian Chesky's version of the rule is the one everyone quotes: "Do it until it hurts, then automate it away." Here are four concrete signals that it's time:
Signal 1. Your manual LTV/CAC has crossed your target LTV/CAC. If each manual user costs you a lot of founder time, that looks terrible. But if retention on hand-held accounts clearly beats self-serve retention over three years, the math flips. That's HyperSpectral's situation at $3.5M ARR.
Signal 2. The founder gets product time back. If you're coding new features again, you've stepped away from the manual work. That's fine, as long as you've handed it to someone who does it with the same intensity.
Signal 3. Churn becomes random. Early on, you understand every account that churns because you were there. Past a certain volume, you lose the context behind each departure. That's your cue to set up proper churn 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. This is the moment to break the process into formal steps. Otherwise you'll hand over your exhaustion instead of your method.
The anti-pattern is switching from fully manual to fully automated in one jump. The approach that works is what Matt Theurer calls the "manual co-pilot": a human plus automation, where the human keeps the part of the work that teaches the most. At $3.5M ARR, HyperSpectral still keeps part of its onboarding manual, and it does so on purpose.
FAQ
How long should the "unscalable" phase last?
As long as you learn more by hand than from a dashboard. HyperSpectral still does it at $3.5M ARR. The test is simple: as long as manual work generates product insight, keep going.
Does doing things that don't scale work for B2B too?
Yes, and B2B is where it works best. Paul Graham calls it the "Consult" pattern. You take on a single design partner, build the product around their specific context, and extrapolate from there. The one rule: don't charge by the hour, or you'll turn into an agency (see Mistake 1).
What about hardware?
PG calls this pattern "pulling a Meraki". You assemble your first few hundred units by hand. Pebble did exactly that before its $10 million Kickstarter. The hidden advantage is that you can iterate on the design faster because you are the factory. Eric Migicovsky learned that screw quality mattered, which is the kind of lesson a Gantt chart will never show you.
How do you measure whether an unscalable tactic is working?
Use different measures from standard business metrics: (1) the number of product insights you generate each week, (2) founder time per active user, and (3) the manual versus self-serve conversion rate when you test both in parallel. If manual work doesn't produce more insights than your analytics, stop.
What is Paul Graham's original essay?
Paul Graham published Do Things that Don't Scale 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 also hosts a copy in its Startup Library.
Further reading
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 detailed HyperSpectral case study on Frontlines: https://www.frontlines.io/hyperspectrals-white-glove-onboarding-at-scale-when-things-that-dont-scale-actually-do/.
If you're launching and want more structure, our guide to finding a startup idea picks up where this article leaves off. For the methodology side, the lean startup definition explains why manual work is really user research in disguise. And if you're hiring your first CTO, our startup CTO guide explains why a founder who talks to users is worth as much as a well-chosen CTO.
