Startup Experts Discuss Doing Things That Don't Scale
- Aisha Washington
- 1 day ago
- 7 min read
Early-stage founders are often encouraged to think about scale from the beginning. They are asked how their systems will support millions of users, how customer acquisition will become repeatable, and how operations will expand without costs rising at the same rate. Those are legitimate questions—but the startup experts in this Y Combinator discussion argue that they are frequently asked too soon.
The speakers revisit Paul Graham’s influential essay “Do Things That Don’t Scale” and explain why its message remains central to building a company from scratch. Through examples including Airbnb, Fleek, Stripe, Algolia, Instacart, and DoorDash, they make the case that manual effort is not merely an acceptable temporary compromise. Used deliberately, it is a powerful way to test demand, understand customers, and discover which parts of a business are actually worth scaling.
Why the Startup World Needed a Different Playbook
According to the speakers, Silicon Valley’s enthusiasm for scalable systems grew partly from observing extraordinarily successful internet companies. Google demonstrated how software and online distribution could reach enormous audiences with relatively little incremental effort. Founders and investors naturally began searching for similarly repeatable growth models.
That ambition gradually became a constraint. Entrepreneurs felt pressure to present a scalable solution before they had proved that anyone needed it. They could spend months designing automated systems for hypothetical demand while remaining distant from real customers.
Paul Graham’s essay challenged that sequence. As the panelists explain, most young startups are not threatened by excessive demand or collapsing infrastructure. Their immediate risk is much simpler: they may never attract enough users, or they may build something people do not value.
The practical priority is therefore to solve the problem directly, even if the first method is labor-intensive. Scalability matters eventually, but only after the company has found something worth scaling.
Getting from Zero to One Comes First
The discussion frames startup progress as a series of immediate constraints. At the beginning, the challenge is not serving the millionth customer efficiently. It is winning the first customer, delivering the first successful outcome, and learning why that person chose the product.
This changes how founders should evaluate early work. A task that looks inefficient in a mature company may be entirely rational when it answers a critical question quickly. Personally onboarding a customer, manually assembling a service, or improvising an internal workflow can reveal more than weeks spent building infrastructure in isolation.
The speakers use Airbnb as a defining example. Its founders needed better listings, so they helped hosts produce higher-quality photographs. Traveling to properties and improving listings individually could never have been the permanent operating model. Yet it addressed the company’s urgent problem: making the marketplace more appealing and generating enough activity for growth to begin.
The lesson is not that every founder should reproduce Airbnb’s tactic. It is that founders should identify the obstacle directly in front of them and be willing to solve it without waiting for an elegant system.
Fleek Learned the Marketplace Before Building It
Fleek offers an especially vivid illustration of learning through manual operations. The company began without a finished website, an inventory of clothing, or a sophisticated marketplace infrastructure. Instead, its founders went to London wholesalers, developed relationships, and connected supply with shops directly.
The panel describes how the team even transported clothes between wholesalers and retailers. From a conventional efficiency perspective, founders carrying merchandise themselves looks like a process failure. From a learning perspective, however, it placed them inside the transaction.
By participating in the work, Fleek could observe what retailers wanted, how wholesalers behaved, which prices worked, and how demand responded to changes. These were not abstract survey answers. They were insights gathered while helping real buyers and sellers complete real purchases.
After roughly four months of operating manually, the founders had enough knowledge to move the activity online. The marketplace was informed by behavior the team had already seen, rather than by assumptions about how the market ought to function.
Hands-On Onboarding Creates Better Products
The speakers point to Stripe and Algolia as further examples of founders closing the gap between product development and customer reality. Stripe’s founders helped install their payment software for early users instead of simply sending documentation and waiting. Algolia similarly assisted Product Hunt with implementing search.
Direct implementation accomplishes more than getting a new account activated. It exposes confusing setup steps, hidden technical dependencies, and differences between what customers say they need and what they struggle with in practice.
It can also change the relationship. A customer who has worked alongside a founder is more likely to share candid feedback than someone submitting a support ticket to an unfamiliar company. That trust gives the startup access to sharper product insight.
The panelists describe this personal attention—founder “FaceTime”—as an advantage that established companies often cannot match. A large competitor may possess more resources, but it usually cannot have its founders personally committed to each small customer’s success. For a startup with an incomplete product and limited credibility, visible care can become part of the value proposition.
Optimize Early Work for Learning
The central argument of the discussion is that founders should optimize the early phase for learning rather than operational elegance. Manual delivery helps establish whether the promised result is genuinely valuable before the team encodes that process in software.
This principle can be translated into a simple sequence:
Identify the most important uncertainty in the business.
Design the fastest credible way to test it with real customers.
Perform the work manually when automation would delay the answer.
Record what repeatedly creates value or causes friction.
Build systems only after the pattern becomes clear.
This does not mean treating every improvised process as proof of a viable business. Manual work is useful when it generates evidence. Founders still need to determine whether demand repeats, whether customers will pay, and whether the underlying service can eventually support an attractive business model.
What they should avoid is confusing technical polish with validation. A beautifully engineered platform cannot compensate for an unwanted product.
Instacart and DoorDash Tested Demand with Improvised Tools
The Instacart story shows how founders can test a marketplace before obtaining all the partnerships that a mature version would require. As recounted in the video, the company launched without formal grocery-store relationships. The team purchased items from Trader Joe’s, photographed them, and listed them online to see whether customers would order groceries for delivery.
That approach bypassed a potentially long cycle of partnership negotiations. Instead of asking retailers to support an unproven concept, the founders first gathered evidence that consumers wanted the service.
DoorDash took a similarly pragmatic route. The speakers describe its early product as something assembled in a single day with ordinary tools, including Google Drive and Find My Friends. The goal was not to create a durable logistics platform immediately. It was to find out whether local consumers would order restaurant delivery and whether the founders could fulfill those orders.
These experiments exploited a genuine startup advantage: small teams can temporarily coordinate work in ways that would be impractical for large organizations. They have fewer processes to protect, less infrastructure to integrate, and more freedom to change direction after each result.
Imperfect Systems Make Adaptation Faster
Doing things manually allows a team to revise the experience without rebuilding an entire product. If customers dislike a step, the founders can change it on the next order. If an assumption proves false, they can abandon it before it becomes embedded in months of engineering work.
The speakers also argue that founders should not be overly afraid of early operational errors. Problems created by growing demand often produce strong incentives to find solutions quickly. When a startup finally has more users than its improvised process can support, the need for automation becomes concrete, urgent, and easier to define.
This is why startups seldom fail because they attracted too many customers and could not scale. Capacity problems are painful, but they come with evidence of demand. A lack of users is far more dangerous because it offers neither revenue nor a clear reason to keep building.
The engineering implication is important: postponing infrastructure can be a form of speed, not negligence, provided the shortcuts are understood and do not create unacceptable risks for customers.
Knowing When to Build for Scale
Unscalable work is a discovery method, not a permanent philosophy. Once a startup understands the recurring job, sees sustained demand, and encounters manual bottlenecks, it must begin converting what it has learned into repeatable systems.
The panel notes that experienced advisors and investors can help founders recognize this transition. Scaling too early wastes resources on unverified assumptions. Scaling too late can damage service quality, exhaust the team, and prevent the company from capturing demand.
A useful signal is repetition. If founders keep solving the same problem in roughly the same way, software may be able to standardize the process. Another is opportunity cost: when manual delivery consumes time that could produce more valuable learning or growth, automation becomes increasingly attractive.
The objective is not to eliminate human involvement for its own sake. It is to automate the parts that are now understood while preserving close contact wherever customers are still teaching the company something important.
Consulting Can Be a Bridge, but Not the Destination
The speakers also address the boundary between a software startup and a consultancy. A young company can earn revenue by providing hands-on services to businesses, and its first product may simply make that service faster or more reliable.
This can be a productive starting point. Consulting work exposes founders to real operating environments and gives them detailed knowledge of customer problems. It may also finance early development.
However, the panel cautions that service revenue alone does not create a high-growth software company. Customized work expands primarily by adding people, while a scalable product can serve far more customers without proportional headcount growth. Ambitious growth goals help force the distinction: if the business is expected to grow by an order of magnitude, founders must eventually turn repeated expertise into a product rather than indefinitely selling bespoke labor.
The Durable Advantage of Founder Effort
The video’s closing message is that willingness to perform awkward, manual, or seemingly minor tasks is one of a startup’s strongest advantages over established competitors. Such work brings founders closer to customers, accelerates experiments, and creates opportunities to deliver unusually attentive service.
The deeper principle is not a celebration of inefficiency. It is disciplined sequencing. First, learn what people need. Then prove that they will act on that need. Deliver the result by whatever responsible method is available, study the recurring pattern, and only then invest in making it repeatable.
Scalability becomes valuable when demand has earned it. Before that point, the founder’s most effective system may simply be curiosity, urgency, and a willingness to do the work personally.
