Startup Experts Discuss Doing Things That Don't Scale

Core Thesis: Paul Graham's 2013 essay "Do Things That Don't Scale" inverted the Silicon Valley orthodoxy that startups must prioritize scalable infrastructure and business models from day one, arguing instead that early-stage founders must obsess over solving immediate user problems, even manually.

• The Scalability Trap: In the early 2000s, investors and big tech companies equated "scalability" with technical capacity (server load) and infinite revenue potential, leading founders to delay customer acquisition while building perfect, theoretical architectures.
• The Result of the Trap: Many startups failed because they built scalable solutions for problems no one actually had ("Field of Dreams" syndrome), prioritizing architecture over product-market fit.
• The Counter-Strategy: Graham's solution was to prioritize "hair-on-fire" problems and direct customer contact over theoretical scaling, accepting that early operations will be manual and one-off to validate demand.

Strategic Rationale for Manual Operations:

• Optimizing for Learning: The primary goal of unscalable actions is to maximize the speed and depth of founder learning about user needs, pricing elasticity, and workflow realities.
• Speed vs. Perfection: Founders must avoid spending months building "perfect" software before contacting a real customer; the risk of building unwanted features is higher than the risk of manual labor.
• Cultural Shift: This approach requires founders to adopt a mindset where "nothing is beneath them," including tasks like cold calling, admin, and manual fulfillment that would be delegated in larger corporations.

Historical Precedents and Case Studies:

• Airbnb: To solve the lack of high-quality listings, founders physically traveled to apartments to take professional photos themselves, creating the initial flywheel of trust and bookings that their platform could not have generated otherwise.
• Fleek (Winter 22 Batch): Founders manually acted as intermediaries between secondhand clothing wholesalers and retailers, physically transporting boxes of clothes to learn pricing, demand, and inventory patterns before building their marketplace platform.
• Stripe & Algolia: Founders manually implemented their own software (APIs and search engines) directly into customer codebases (e.g., Product Hunt) to bypass integration barriers and build deep user trust, learning exactly how customers used the product in the process.
• Vendor (Ryan): The founder sold himself personally to prospects by sharing his direct cell phone number and promising 24/7 availability, leveraging the personal commitment of a small team to win against well-funded competitors.
• Instacart: Instead of waiting for years to secure corporate data partnerships with grocery chains like Trader Joe's, founders manually purchased all inventory at a store, photographed items, and listed prices online to launch the service immediately.
  • Outcome: This "janky" launch created immediate traction, eventually granting them the leverage to negotiate formal partnerships once they had scale.
• DoorDash: The initial product was a "Wizard of Oz" setup built in one afternoon using Google Drive for menus, HTML/CSS, and the "Find My Friends" app to simulate real-time dispatch tracking by hand.
  • Validation: The team used this manual process to prove demand before engineering a complex system, accepting that errors and manual intervention were acceptable during validation.

Operational Nuances and Risks:

• The "Consultancy Trap": While unscalable services (e.g., manually building A/B tests for clients) can generate early revenue and validate demand, founders risk getting "addicted" to this revenue stream if they do not transition to a software-based product.
  • Scale Limitation: Consulting revenue grows linearly with headcount and cannot scale 10x, whereas software revenue can; founders must set ambitious growth targets to force the transition.
• Error Handling: Unlike big companies that seek error-free planning, startups should embrace chaos (e.g., "turning on the water" to find cracked pipes) because the high incentive to fix breaking systems upon gaining traction ensures rapid resolution.
• Legal Flexibility: Early unscalable methods (like scraping data) may skirt legal gray areas initially, but once the startup gains scale and customer leverage, formal negotiations and settlements become the priority rather than shutdown.

Transition Points and Scaling:

• The Flip: Founders must eventually transition from manual to automated operations once they have answered the "zero to one" question of whether people want the product.
  • Advisor Role: Investors and advisors serve as a check to tell founders when to stop doing unscalable work and begin investing in infrastructure.
• Future Engineering: The manual work done early allows founders to understand the exact configuration of value they need to encode into software later, preventing the creation of scalable systems for the wrong problems.

Forward-Looking Implications:

• Competitive Advantage: The ability to do unscalable work is a unique advantage startups hold over larger incumbents who are bound by corporate processes and risk aversion.
• Validation Priority: Doing things that don't scale allows for "failing fast" and pivoting before hard-coding incorrect assumptions into software, effectively saving months or years of development time.
• Investment Criteria: The capacity to grow 10x is a key metric investors use to distinguish between a scalable startup and a stagnant consultancy.