How do you do things that don't scale?

Doing things that don't scale means deliberately choosing labor-intensive, manual, or one-on-one actions that no large company would bother with—because those actions are exactly what gets a startup off the ground. The goal is not efficiency; it's learning, survival, and creating the conditions for growth that can later be automated or systematized. Most founders skip this phase out of misplaced ambition, and that's usually what kills them.

Why 'unscalable' is actually the point

There's a persistent myth among first-time founders that the work of building a startup should look like the work of running a mature company—clean processes, repeatable systems, leverage at every step. This instinct is wrong at the earliest stage, and it's costly. A startup in its first weeks or months is not a small version of a big company; it's a completely different organism operating under completely different constraints. Its job is to find out if anything it's doing matters to real people, and the fastest way to answer that question is direct, inefficient, person-to-person contact.

Paul Graham's analysis of early-stage startups makes clear that nearly all of them are fragile at the start in ways that outside observers—and sometimes the founders themselves—fail to appreciate. The mistake is judging a new company by the standards of an established one. A startup that manually onboards its first ten customers isn't doing something embarrassing; it's doing something essential. Scalability is a problem you earn the right to have. Before you have it, unscalable effort is the price of admission.

The founders who skip this step tend to build products shaped by their own assumptions rather than their users' actual behavior. They optimize distribution before they've confirmed the thing is worth distributing. Doing unscalable things forces a confrontation with reality that no amount of analytics dashboards can replicate.

Manual user recruitment: go get them yourself

The single most common unscalable act a founder can take is personally recruiting their first users rather than waiting for them to appear. This means sending individual emails, showing up at places where your target users congregate, cold-calling, posting in niche forums, knocking on doors—whatever gets a warm human being to actually try the product. It is slow, it doesn't compound, and it absolutely cannot be the long-term plan. That's fine. The long-term plan requires a short-term plan that works.

Airbnb is the canonical example Graham cites. The founders flew to New York, met their early hosts in person, and used professional cameras to improve their listings' photos. This produced no leverage whatsoever. It also produced a company. The insight from that story isn't that you should take photos for your users—it's that the founders were willing to do whatever the moment required, regardless of how unscalable it looked. The 30 days they spent in direct contact with users was, in Graham's framing, the margin between success and failure.

For your own company, the practical translation is simple: make a list of ten people who should want your product, and contact each of them today with a personal, specific message—not a mass email, not a drip campaign. Sit with them while they use the product if you can. Watch what confuses them. Listen to what they wish it did differently. This information is not available any other way.

Treating early users like consulting clients

One of the most useful framings for early-stage startup work is to treat your first users less like customers and more like clients in a consulting engagement—where you are building something specifically to solve their problem, not shipping a finished product and hoping it fits. Graham recommends that B2B founders, in particular, sometimes pick a single user and orient everything around making them successful, even if it means custom work that won't generalize immediately.

This works because the constraint of serving one real user extremely well forces you to understand the problem at a depth that generalized product thinking rarely reaches. The custom work you do for that first user often reveals the actual shape of the problem—edge cases, workflow dependencies, terminology, organizational dynamics—that you couldn't have anticipated from the outside. Once you've built something that one user genuinely loves, the question of whether other users have similar needs becomes much easier to answer, because you've seen the problem up close.

The key distinction Graham draws is between this kind of intensive, uncompensated attention and actually becoming a consulting business. If you start charging for custom work, you've crossed a line: you're no longer a product company doing extraordinary early support, you're a services company with a side project. The right posture is to give consulting-level attention while building a product, not to sell consulting as the product. Stay on the right side of that line and users will be grateful; cross it and you'll find yourself trapped.

The 'fire' tactic: start in a deliberately tiny market

Another form of doing things that don't scale is intentionally constraining your addressable market at launch—not because you can't reach more people, but because concentration creates intensity. Graham uses the image of keeping a fire contained to get it really hot before adding fuel. A product that is genuinely loved by a small, specific group is a far better foundation than a product that is mildly interesting to a broad audience.

Facebook is the example Graham points to here: it launched only for Harvard students, a pool of a few thousand people, and the narrowness was the feature, not a limitation. Students felt the product was made specifically for them, which created the psychological conditions for rapid adoption within that group. The density of usage in a small market generates word-of-mouth, social proof, and feedback loops that a broad, thin launch cannot. Only after that density was established did the product expand.

For marketplaces and social products especially, this isn't optional—it's structurally necessary. A marketplace with thin supply and thin demand on both sides is worthless. A marketplace that dominates one city, one category, or one community actually works, and working is what makes expansion possible. Ask yourself: what is the smallest coherent market in which my product could be the clear, obvious, dominant choice? Start there. Do unscalable things to win it completely.

What you actually learn from unscalable work

The case for doing things that don't scale isn't purely about survival—it's also about the quality and type of information you get. Direct, manual, intensive engagement with early users produces qualitative insight that no quantitative feedback mechanism can replicate. You learn not just what users do, but why, what they were expecting, what adjacent problems they have, and what vocabulary they use to describe their situation. This shapes everything from product priorities to marketing copy to positioning.

Graham notes that Pebble's Eric Migicovsky learned something unexpected from close engagement with hardware manufacturing: the importance of sourcing good screws. That level of specific, operational knowledge comes only from being physically and intellectually present in the work. It doesn't come from surveys, user interviews conducted over video at arm's length, or cohort analysis. The insight is almost always surprising, which is exactly why you needed to find it.

The other thing unscalable work teaches is whether you actually care about the people you're building for. Founders who are unwilling to do the slow, manual, unglamorous work of serving their earliest users often have a misalignment between the business they want to run and the problem they've chosen to work on. If spending a day watching someone struggle with your product sounds tedious rather than fascinating, that's important information about fit—between you and the problem, and between the problem and your current solution. The founders who find this work energizing are usually the ones who eventually don't need to do it anymore.

“Almost all startups are fragile initially. And that's one of the biggest things inexperienced founders... get wrong about them.”

— Paul Graham, source

The one thing to do

Today, personally contact ten potential users, sit with at least one of them while they use your product, and let what you observe change your priorities.

Frequently asked questions

When should I stop doing things that don't scale?

When the unscalable action has produced enough density—users, data, revenue, feedback—that you understand the repeatable pattern underneath it. The transition point is when you're no longer learning anything new from the manual work, not when it becomes inconvenient.

Does this apply to B2B and enterprise startups, or just consumer products?

It applies especially to B2B. Graham explicitly advises B2B founders to treat a single early customer like a consulting client, building to their exact needs until the fit is perfect. Enterprise sales almost always require high-touch, unscalable founder involvement at the start.

How do I manually recruit users without it feeling spammy or desperate?

Be specific and honest. Identify exactly who has the problem you solve, explain clearly why you think your product is relevant to them, and ask for a single concrete action—a call, a trial, feedback. Generic outreach reads as spam; targeted, personal outreach reads as founders who care.

What if my co-founder thinks manual work is beneath us and wants to focus on growth?

This is a serious misalignment worth resolving directly. Premature focus on scalable growth before product-market fit is one of the most reliable ways to accelerate toward failure. The manual work isn't beneath the company—it is the company at this stage.

Sources

More playbook answers · Growth Prophet home