Do Things That Don't Scale: Examples and When to Stop

"Do things that don't scale" means deliberately manual, founder-led work to win a startup's first users and make them very happy: recruiting customers one by one, onboarding them yourself, even doing by hand what your software will later automate. In our view, you stop piece by piece, when a manual task becomes the bottleneck to growth and you understand it well enough to automate it or hand it off.

Definition: Doing things that don't scale is a startup strategy, named in Paul Graham's July 2013 essay, of using unscalable founder effort (manual recruiting, white-glove service, hand-built operations) to start growth and learn what customers need before investing in systems.

Most early startups don't have a scaling problem. They have a user problem.

That's why the approach tends to work. The manual work gets you users, and it teaches you what to build for them.

What doing things that don't scale means in practice

Our working definition: if a task is manual, done personally by a founder, and would look absurd at a company of 1,000 people, it probably counts.

This isn't hustle for its own sake. Startups rarely take off on their own. Founders have to push them into motion, and that push is a different, more laborious job than keeping the company running once it moves.

The idea landed because it cut against the fashion of its time. In the 2000s, investors and big tech companies prized scalability above almost everything, and a startup without a scalable answer often struggled to raise money. We prefer the opposite order. Deal with the problem in front of you (usually getting a first customer) before worrying about problems further down the road. You still scale eventually. You just earn the problem first.

Graham adds a test we like for any early idea: treat it as two parts, what you will build plus the unscalable thing you will do to get it going. If you can't name the second part, for example because you have no way to reach users by hand, the idea may be a bad one, at least for you.

One uncomfortable consequence: at this stage the CEO's job includes the lowest-status work in the company, from delivering orders to answering angry support emails. Founders who treat that work as beneath them often learn more slowly.

Do things that don't scale: examples from Airbnb, Stripe, DoorDash and more

These are among the better-documented cases, each tied to what it taught the company.

Airbnb. By Paul Graham's account, the company was so fragile early on that about 30 days of going out and engaging with users in person made the difference between success and failure. Brian Chesky knocked on hosts' doors in New York and photographed homes himself. His rule of thumb is the one-line version of this guide: do everything by hand until it is painful. Only then did Airbnb bring in other photographers.

Stripe. When anyone agreed to try Stripe, the Collison brothers asked for the person's laptop and set them up on the spot rather than promising to send a link. The less visible part: the "instant" merchant accounts early users received were, behind the scenes, traditional merchant accounts the founders opened by hand.

DoorDash. DoorDash's S-1 dates the company to January 12, 2013, when the founders put up a website with menus from Palo Alto restaurants. The first customer ordered Thai food within hours, and the company was incorporated as Palo Alto Delivery Inc.

Co-founder Stanley Tang's Stanford lecture and a later YC discussion fill in the rest. The landing page took about an hour and the whole first version one afternoon. The phone number was the founders' own. The founders were the drivers, dispatchers and support team, running on Square, Google Docs and Apple's Find My Friends, and they emailed every new customer personally each night.

A team of Stanford engineers could have built the real system. Proving demand was the harder question. And the habit stuck: CEO Tony Xu's letter in the S-1 notes that everyone at DoorDash, including him, tries to do a delivery or customer support once a month.

The software edition: technical shortcuts that don't scale

The same logic works inside the codebase. A handy rule of thumb is the 90/10 solution, a phrase associated with Gmail creator Paul Buchheit: find the version that gets 90 percent of the benefit for 10 percent of the work, and build the robust system only when growth forces you to. Three well-known cases:

• Gmail began as Buchheit reading his own email in a repurposed internal tool, and its famous invite system existed partly because Google had limited storage.
• Facebook ran a separate set of servers and a separate database for each college rather than building one global user table.
• Justin.tv and Twitch had a button that turned any overloaded channel page into a static page, and got the site translated by volunteers from its own community instead of paying for professional translation.

Don't engineer against failures you're only imagining. Many teams ship the crude version, let real usage show which parts break, and fix those first. For capacity planning, a common rule of thumb is to plan for the next order of magnitude: at 10 users, plan for 100, not a million.

How to do things that don't scale: the manual-first loop

We'd run manual work as a loop with a start, a log and an exit.

1. Write down the one question you need answered. For example: will anyone pay for this, or which restaurants generate repeat orders? Manual work pays off when it answers a question, not when it just keeps you busy. If you are still testing whether the idea deserves any work at all, the 4-week idea validation plan is probably the better first step.
2. Pick a narrow starting market. Facebook started with Harvard only. Look for a contained group where you can reach critical mass by hand.
3. Recruit users one at a time. Cold messages, communities, events, and the Collison installation (set people up on the spot). Our guide on how to talk to users covers the conversations; founder-led sales for technical founders covers turning them into customers.
4. Deliver the service by hand behind a simple front end. A form, a spreadsheet, a shared inbox and a phone can stand in for software, as DoorDash showed.
5. Over-serve the first users. Onboard them personally, fix problems the same day, and follow up. Being your user should feel exceptional even while the product is incomplete.
6. Log every manual task with time spent. This makes it much easier to decide what to automate first.
7. Automate the bottleneck, not everything. When one manual step caps growth, automate or delegate that step and keep the rest manual.

Worked example: when manual onboarding pays for itself

Some of the most detailed public numbers come from Superhuman. In a First Round Review piece published in 2025, co-founder Gaurav Vohra reports that he personally onboarded hundreds of customers before hiring a specialist. Sessions ran up to 90 minutes before being cut to 30. More than 65 percent of customers onboarded by a human fully switched their email to Superhuman, more than double the self-serve rate.

Each fully ramped specialist, doing 40 calls a week for 45 weeks, could add up to $650,000 of ARR a year at $30 per month. The arithmetic checks: 40 times 45 is 1,800 customers, and 1,800 times $360 a year is $648,000.

Now an illustrative, hypothetical B2B tool priced at $200 per month, using activation rates like Superhuman's as assumptions: 65 percent for human-led onboarding, 40 percent for self-serve.

Stage 1, founder-led. 40 signups a month, one founder hour each (40 hours). Human-led onboarding activates 26 customers versus 16 self-serve: 10 extra customers, or $2,000 more MRR from each monthly cohort ($24,000 annualized). That is about $600 of annualized revenue per founder hour. On these assumptions, keep going.

Stage 2, growing. 400 signups a month. That is 400 hours, far more than any founder has, so the choice is specialists or self-serve. At 40 calls a week (about 160 a month) each, you need 2.5 specialists; at an assumed $80,000 fully loaded cost each, that is about $16,667 a month.

Our read of the table: volume doesn't kill the manual process. A better self-serve product does, by closing the gap. That is what Superhuman eventually did, moving to self-serve when the costs, especially mismatches between onboarding capacity and demand, outweighed the benefits. A better in-product onboarding then lifted self-serve activation from 40 to 50 percent.

When to stop doing things that don't scale: five signals

We don't think there is a single milestone, whether the Series A or a revenue number. A common approach is to stop one task at a time, when signals like these appear.

• It hurts. Pain means volume, and volume means you have learned the job. This is Chesky's rule in practice.
• You can write the playbook. When you automate yourself out of the loop, you ideally know what to build because you did it by hand. If you can't describe the task step by step, it is probably too early to automate it.
• Manual work is capping growth. Fleek, a YC W22 company that hand-carried boxes of secondhand clothing to shops for about four months, had to move buyers and sellers onto its platform to build a business with real margins.
• The economics flip. Use the worked example above: when the activation or retention gain from the manual step no longer pays for its cost, it is probably time to automate it.
• Price and complexity say so. Vohra's framework is one we find especially useful: low-price, low-complexity products should keep human onboarding only until product-market fit; high-price, high-complexity products may keep it indefinitely.

Some habits are worth keeping long after the rest is automated: founders talking to users, reading support tickets and caring about early customers. Delighting customers often scales better than founders expect, partly because it becomes part of the culture. DoorDash's once-a-month delivery habit is that idea in practice. Track whether each handoff hurts retention with a cohort retention view before and after.

But investors want to see something that scales

It's a fair worry. You are raising money on the promise of a big, efficient business, and a founder personally driving Thai food around Palo Alto doesn't look like one. Some manual work doesn't turn into software. Some founders hide in it because it feels productive.

But.

Investors at the earliest stage are mostly asking whether anyone wants the thing. Hand-won customers answer that more convincingly than a scalable system nobody uses. In our view, the manual phase is fine to show investors as long as you can explain what it taught you and which step you will automate next.

Where views differ on doing things that don't scale

• Stop as late as possible, or flip a switch? One camp holds that founders should hold on to the manual advantage as long as they can; the other that at some point you have to deliberately flip to scale, ideally with advisors who help you see when. We lean toward the task-by-task view above: keep the manual work that still teaches you something, and flip the switch on each task when its signal fires.
• Consulting can be a trap. Charging companies to do the work by hand before a product exists can prove demand, as Optimizely did by building A/B tests for clients. The risk is getting addicted to that revenue, because it depends on human labor. Our line: over-serving a customer is fine until they pay you by the hour for it. Ambitious growth targets expose the problem, because a consultancy rarely grows tenfold in a year. AI-enabled services companies try to escape that limit by having AI do most of the production work.
• Free is rarely a shortcut. We would be cautious about giving the product away to win early users. People tend to treat free products differently, and free usage can create a false sense of demand. Some products use free tiers on purpose, but we'd rather see whether people will pay; as our take on customer discovery argues, purchase intent tells you more than polite opinions.
• Partnerships and big launches. Both often disappoint as ways to start growth. Instacart is a useful illustration: it skipped a grocery partnership, built demand by hand, and negotiated deals once it had scale.

Common mistakes

• Doing unscalable work without a question to answer. Busy is not the same as learning.
• Hiding behind a big-company image. Founders sometimes copy big companies' indifference to individual users because it seems professional. In our view that wastes one of your few structural advantages.
• Waiting for a big launch. Launches usually matter less than how happy you make the first users. Our launch guide covers launching repeatedly instead.
• Underrating small numbers. 100 users growing 10 percent a week becomes roughly 14,000 in a year (100 times 1.1 to the 52nd power is about 14,204) and about 2 million in two.
• Not automating at all. Manual work that no longer teaches you anything is mostly cost.

How 1752vc's GTM Accelerator fits

Once you have validated the product and have early traction, the next job is turning hand-won customers into a repeatable motion. 1752vc's GTM Accelerator is a 12-week, hands-on, remote and self-paced program that teaches founders at that stage to sell, recruit, fundraise and build traction, with rolling admissions. It can be a useful place to work out which unscalable habits to keep and which to turn into process.

The bottom line

Doing things that don't scale is a learning strategy with a growth side effect. Pick the question, do the work by hand, write down what you learn, and automate each task once it starts to hurt.

Do it by hand until you understand it.

Then build it so you don't have to do it again.

Key takeaways

• Doing things that don't scale means founder-led, manual work to recruit and delight early users and to learn what to build; Paul Graham named it in July 2013.
• Well-documented examples include Airbnb's door-to-door photography, Stripe's Collison installation and DoorDash's founders doing the deliveries.
• It helps when each manual task answers a question, and logging its time shows what to automate first.
• A reasonable time to stop a manual task is when it becomes painful, capping growth or uneconomic, and when you can write its playbook.
• Consulting revenue and free products deserve caution: both can hide whether a scalable business exists.
• Many companies keep the habits that build culture, like founders doing support or deliveries, long after they automate the rest.

Frequently asked questions

When should a startup stop doing things that don't scale?

A common answer is to stop a specific manual task when it becomes a bottleneck to growth, when it no longer pays for itself, and when you understand it well enough to automate or delegate it. Chesky's rule of thumb is to do it by hand until it is painful. We would keep founder habits like talking to customers indefinitely, because those tend to remain an advantage.

What is the Collison installation?

It is the name, from Paul Graham's 2013 essay, for how Stripe's founders recruited early users. When someone agreed to try Stripe, Patrick and John Collison asked for their laptop and set up the integration on the spot instead of sending a link. It turns a polite yes into an active user immediately.

Is doing things that don't scale the same as running a consulting business?

Not quite, in our view. Doing things that don't scale means over-serving customers of a product company to learn and grow. Consulting means being paid for labor, which caps growth. One practical line is customers paying you by the hour, and it is worth being wary of consulting revenue that depends on your own time.

What are examples of doing things that don't scale in software?

Well-known cases include Gmail's invite system, created partly because storage was scarce; Facebook running a separate database for each college; and Justin.tv turning overloaded pages static and crowdsourcing translation from its own users. Each shipped a crude 90/10 solution first and built the robust system only once growth forced it.

How can a B2B startup do things that don't scale?

One approach is to pick one customer and build as if you were their dedicated consultant, without billing by the hour. Onboard every account yourself, write their integration for them, as Algolia did for Product Hunt, and handle support personally. Other startups often make good early adopters because they tend to adopt new tools quickly and give candid feedback.

Sources

• Y Combinator: Do things that don't scale (Paul Graham)
• Y Combinator: YC's Group Partners Discuss Doing Things That Don't Scale (Garry Tan and YC Group Partners)
• Y Combinator: Dalton & Michael: What does it really mean to do things that don't scale? (Michael Seibel and Dalton Caldwell)
• Y Combinator: Dalton & Michael: Things that don't scale, the software edition (Michael Seibel and Dalton Caldwell)
• Y Combinator: How to Start a Startup: Getting started, getting press, and doing things that don't scale (Stanley Tang, Walker Williams, Justin Kan)
• Paul Graham: Do Things that Don't Scale (July 2013)
• SEC: DoorDash, Inc. Form S-1 (November 2020)
• Masters of Scale: Do things that don't scale, with Brian Chesky
• First Round Review: Superhuman's Onboarding Playbook (Gaurav Vohra)