Paul Graham's "Do Things That Don't Scale" argues that young startups rarely take off by waiting for a superior product to attract users on its own. Founders should recruit customers manually, deliver unusually attentive service, operate parts of the product by hand, and concentrate on a narrow initial market. The essay remains useful because it treats early growth as active learning rather than a launch event.
Its weakness is not the advice to begin manually. It is the absence of a clear rule for deciding when the manual work is producing knowledge and when it is merely concealing a business that does not work.
A founder who personally installs software, answers every message, or completes a workflow behind the scenes gets unusually rich feedback. But the customer is also receiving a version of the service that later customers may never receive. Satisfaction can reflect the founder's judgment, urgency, and unpaid labor more than the product itself. If those inputs are not separated, early enthusiasm may validate a bespoke service while being interpreted as evidence for a scalable product.
The essay recognizes the boundary between attentive product work and paid consulting, yet the economic boundary appears earlier. Founder time is still a cost when nobody invoices for it. A startup can report attractive revenue or retention while excluding hours that would require several employees at ordinary wages. Manual acquisition can likewise look efficient when the founder's network, accelerator access, reputation, or willingness to work indefinitely is treated as free. Those advantages may be legitimate, but they are not necessarily repeatable.
There is also a selection problem. The famous examples are companies whose unscalable beginnings eventually led somewhere scalable. We hear less about teams that delighted a handful of customers for years without finding a broader pattern. Their failure would not prove Graham wrong, but it changes how the advice should be used. Extraordinary attention is an experiment, not evidence by itself. The question is whether each intervention reveals a recurring need that can be served without the same extraordinary input.
That distinction matters most when one early customer becomes the mold. A demanding customer can expose a valuable market, as Graham suggests, or pull the product toward requirements unique to its organization. Founders need to test whether the lesson transfers across customers, not simply whether the first customer becomes happier. Otherwise responsiveness becomes a polite name for accumulating custom work.
The transition to scale deserves the same deliberate attention as the start. Teams should record which manual actions they perform, how often, why they were needed, and what happened afterward. They should distinguish learning work from recurring operations, price the hidden labor, and set thresholds for automating, standardizing, charging for, or stopping each task. A manual process that reveals the same pattern repeatedly is a candidate for productization. One that produces a new exception every time may be exposing a fragmented market rather than a software opportunity.
None of this favors premature automation. Automating an unproven workflow can efficiently build the wrong product, and founders should absolutely experience the customer's problem up close. But proximity needs measurement. The goal is not to eliminate human effort as quickly as possible; it is to learn which human effort creates a repeatable advantage and which merely props up the current result.
The addendum is that doing things that do not scale should come with a stopping rule. Manual work is valuable when it converts uncertainty into reusable knowledge. It becomes dangerous when exceptional service, unpriced founder labor, and customer-specific fixes are allowed to impersonate product-market fit. Start by carrying the customer if necessary—but keep asking whether the product is learning to walk without you.