Do Things That Don't Scale Mental… | Faster Than Normal
Business & Strategy
Do Things That Don't Scale
Paul Graham's principle that the best startups are built through unscalable, hands-on work that creates insights and relationships automated processes cannot replicate.
Model #0008Category: Business & StrategySource: Paul GrahamDepth to apply:
Paul Graham published "Do Things That Don't Scale" in July 2013, and it became the most cited essay in Y Combinator's history. The thesis is deceptively simple: the best startups are built through deliberate, labour-intensive, unscalable acts of founder effort — recruiting users one at a time, providing concierge-level service, doing things by hand that will eventually need automation. The activities that create great companies are precisely the ones that cannot sustain great companies. That paradox is the entire point.
The essay opens with a line that reframes how most people think about startup growth: "Actually startups take off because the founders make them take off." Not because the market was ready. Not because the product went viral. Because the founders, personally and manually, forced the first growth to happen.
Airbnb is Graham's centrepiece example. In early 2009, the company was generating roughly $200 per week. The product existed. Nobody cared. Graham told founders Brian Chesky and Joe Gebbia to fly to New York — their densest market — and meet every host in person. They went door to door. They photographed apartments with a rented DSLR because the listing photos were terrible. They rewrote listing descriptions by hand. They sat in hosts' kitchens asking what would make the experience perfect and then built those things, one feature at a time. Revenue went from $200 per week to $400, then to $4,000. The growth curve changed shape entirely — not because of a product launch or a press hit, but because two founders did the most unscalable thing possible: they made each individual user feel like the only customer in the world.
Stripe ran an equally unscalable playbook from a different angle. Patrick and John Collison didn't wait for developers to sign up. They went to YC Demo Days and startup meetups, found developers complaining about payment integration, and said "give me your laptop." They installed Stripe's API on the spot — seven lines of code, working payments in minutes. What became known as "the Collison installation" was absurd from an efficiency standpoint. Two cofounders of a payment company doing individual technical integrations, one developer at a time. But each installation created a convert. Those first developers didn't just use Stripe. They evangelised it on Hacker News, on Twitter, in every conversation where another developer mentioned payment friction. By the time competitors improved their developer experience, Stripe had thousands of companies embedded — locked in not by contracts but by genuine devotion.
DoorDash took the principle to its literal extreme. Tony Xu, Stanley Tang, Andy Fang, and Evan Moore — Stanford MBA students — launched their food delivery service in January 2013 with a simple landing page called PaloAltoDelivery.com. For the first six months, the founders personally delivered every order. They drove to restaurants, picked up the food, and brought it to customers' doors. The operational absurdity was the point. By delivering food themselves, they learned which restaurants were slow, which packaging leaked, which neighbourhoods tipped well, and which delivery routes were fastest. That granular understanding — impossible to acquire from a dashboard — became the foundation for the logistics algorithms that eventually powered a $70 billion company.
Wufoo, the online form builder acquired by SurveyMonkey in 2011 for a reported $35 million, sent handwritten thank-you notes to every new user. Not automated emails styled to look personal. Actual handwritten notes, on physical stationery, mailed through the postal service. Co-founder Kevin Hale described the practice as deliberately unscalable — the team could only write so many per day. But the effect on user loyalty was disproportionate. In a world of automated onboarding flows, a handwritten note signalled something automated systems never can: that a human being noticed you and cared.
The underlying paradox cuts against every instinct of efficient management. Founders are told to build systems, automate processes, create leverage. Graham's essay says the opposite: at the earliest stage, systems are the enemy. Systems abstract away the very contact with users that generates the insights you need. When you personally photograph an apartment, you notice the lighting is bad and the description undersells the space. When you personally install your API, you learn which error messages confuse people. When you personally deliver the food, you discover the restaurant takes 45 minutes to prepare a 15-minute order. No analytics dashboard captures that texture. No user survey generates that depth.
The "don't scale" principle is really a sequencing argument. It doesn't say never scale. It says earn the right to scale by first doing things that give you unfair knowledge of your customers, your product gaps, and your market reality. Scale from understanding, not from assumption.
The essay's influence extends well beyond Silicon Valley. Y Combinator has funded over 4,000 companies since 2005, and "do things that don't scale" is the single most-referenced piece of advice in partner office hours. Jessica Livingston, YC co-founder, once estimated that the majority of YC's biggest successes — Airbnb, Stripe, DoorDash, Coinbase — had a distinct phase where the founders did something manually that seemed irrational from an efficiency standpoint but proved essential for product development. The irrationality is the feature. Rational operators optimise for throughput. Founders doing unscalable things optimise for understanding.
Section 2
How to See It
Train your pattern recognition. The Do Things That Don't Scale model — and its conspicuous absence — leaves clear fingerprints across startup trajectories and corporate decisions:
Startup
You're seeing Do Things That Don't Scale when founders spend their first months in direct, manual contact with users rather than building growth infrastructure. They answer support tickets personally. They onboard each customer with a live call. They show up at users' offices and watch them interact with the product in real time. The behaviour looks inefficient. It is. That's the tell — if it were efficient, it wouldn't generate the insights that only unscalable effort produces.
Business
You're seeing Do Things That Don't Scale when a company's origin story includes a period of comically manual operations that later got automated. Zappos founder Nick Swinmurn photographed shoes at local stores and posted them online in 1999 before the company held any inventory. He'd buy the shoes at retail and ship them himself when an order came in. The economics were terrible. The learning was priceless — he proved demand existed before building the supply chain.
Product
You're seeing the absence of this model when a startup launches with a polished product, automated onboarding, and a growth marketing team — but no direct user contact. The founders are optimising a funnel before understanding what should be in it. Metrics look clean. Retention looks terrible. The product is built on assumptions rather than intimate knowledge of what real users actually need.
Investing
You're seeing Do Things That Don't Scale when early-stage founders can describe individual users by name and explain specific behavioural patterns they observed firsthand. A founder who says "our users want faster onboarding" is guessing. A founder who says "Sarah at Acme Corp spends 40 minutes on step three because the API documentation assumes she knows OAuth" is speaking from direct, unscalable observation. The specificity is the signal.
Section 3
How to Use It
Decision filter
"Before investing in growth systems, ask: have we done this manually enough times to understand what we're automating? If the honest answer is no, the system will encode our assumptions instead of our knowledge. Do it by hand until the patterns become undeniable, then build the machine."
As a founder
Resist the urge to scale prematurely. Your first 100 users should feel like they have a personal relationship with the company — because they do. Answer every support email yourself. Call users who churn and ask why. Visit power users and watch them work. The information density of a single 30-minute user visit exceeds weeks of A/B testing.
Identify the three most unscalable things you could do for each new user and do them all. The Airbnb founders didn't just photograph apartments — they also rewrote listings, redesigned the booking flow based on host feedback, and hand-delivered welcome packages. Each action was absurdly time-intensive. Each taught them something dashboards never would.
As an investor
When evaluating early-stage companies, ask founders what unscalable things they've done to acquire and retain their first users. The answer reveals whether they've earned real understanding of their market or are operating from hypothesis.
A founder who says "we ran Facebook ads and got a 3% conversion rate" has data. A founder who says "I spent two weeks sitting in dental offices watching how the front desk handles scheduling, and I discovered the real bottleneck isn't the software — it's that three different staff members update the calendar without syncing" has insight. Data is cheap. Insight is unscalable. Bet on the insight.
As a decision-maker
The principle extends beyond startups. Any new initiative — a product line, an internal tool, a partnership programme — benefits from a period of deliberate unscalability. Before building the system, do it by hand. Before automating the workflow, run it manually for a month. The manual phase reveals failure modes, edge cases, and user needs that no requirements document anticipates.
Amazon's Jeff Bezos personally packed boxes in the early days of the company. In a 1999 interview, he mentioned that the warehouse crew worked on their knees on the floor because they didn't have packing tables. Someone suggested they get tables. "That's the most brilliant idea I've ever heard," Bezos said. The observation only happened because the CEO was doing the work himself.
Common misapplication: Some founders interpret "do things that don't scale" as a permanent philosophy. They hand-craft every interaction, resist automation, and pride themselves on the artisanal quality of a 50-person operation. That misses the sequencing. The model says do unscalable things first — to learn, to build relationships, to earn insight. Then encode that insight into scalable systems. Staying unscalable isn't a virtue. It's a bottleneck.
The second misapplication is performing unscalable acts that don't generate learning. Flying to a user's office and taking them to lunch is unscalable. But if you spend the lunch talking about your product vision instead of listening to their workflow, you've done something unscalable and uninformative. The value isn't in the effort. The value is in the information the effort produces.
Section 4
The Mechanism
Section 5
Founders & Leaders in Action
The pattern recurs across eras and industries. Founders who built enduring companies almost always passed through a phase of deliberate, labour-intensive, unscalable effort — not because they couldn't afford to scale, but because the unscalable work taught them things that no scalable process could.
Graham didn't just write about unscalable effort — he built Y Combinator on it. The first batch in the summer of 2005 included eight startups. Graham and co-founder Jessica Livingston worked with each team individually. Dinners at Graham's house in Cambridge, Massachusetts. Hours spent rewriting pitches, challenging assumptions, pushing founders to talk to users instead of writing code.
The format was deliberately unscalable. Graham couldn't advise a thousand startups the way he advised eight. But the depth of that first batch — the quality of mentorship, the specificity of feedback, the sense that YC's founders were personally invested — produced evangelists. Reddit's Alexis Ohanian and Steve Huffman, part of that first cohort, told every founder they knew that YC was worth the equity. The second batch was larger. The third larger still. Within five years, YC's acceptance rate was lower than Harvard's.
Graham never ran an advertising campaign for Y Combinator. The first cohorts' intensity of experience was the distribution engine. Each batch of alumni became recruiters for the next, because the unscalable personal investment they'd received created a loyalty that no marketing budget could replicate. The model he later wrote about was the model he'd already proven.
By the time Sam Walton died in 1992, Walmart operated 1,928 stores with $55 billion in annual revenue. But the company's competitive advantage was forged during decades when Walton personally visited stores with a frequency that baffled his competitors.
Even after Walmart grew past 100 locations in the mid-1970s, Walton flew his own twin-engine Cessna to stores across Arkansas, Missouri, Oklahoma, and Texas. He walked the aisles. He talked to associates — not managers, associates. He asked what was selling, what wasn't, what customers were complaining about, what competitors down the street were doing. He carried a yellow legal pad and wrote everything down.
David Glass, who succeeded Walton as CEO in 1988, estimated Walton visited every Walmart store at least once per year through the 1980s — more than a thousand stores, personally, every year. The practice was comically unscalable. It was also the mechanism by which Walton maintained the operational granularity that large retailers typically lose. He spotted regional demand patterns months before they appeared in aggregate data. He identified underperforming managers by the condition of the stockroom, not the quarterly report. He gathered merchandising ideas from store associates that corporate buyers would never generate.
Kmart, Walmart's primary competitor through the 1970s and 1980s, managed from headquarters. Their executives relied on reports. Walton relied on his eyes, his conversations, and the 50,000 miles per year he logged in his Cessna. By 1990, Walmart had surpassed Kmart in revenue. By 2002, Kmart filed for bankruptcy. The gap wasn't technology or capital. It was the compound effect of a founder who refused to stop doing the unscalable thing that taught him what no report could.
The early days of Apple were defined by unscalable founder obsession. In 1976, Jobs and Steve Wozniak hand-built the first 50 Apple I computers in the Jobs family garage in Los Altos, California. Each board was hand-soldered. Jobs personally delivered units to the Byte Shop in Mountain View — Paul Terrell had ordered 50 machines, and Jobs showed up with them himself.
When Apple launched the Macintosh in January 1984, Jobs had spent two years micromanaging every detail of the user experience. He personally reviewed icon designs pixel by pixel. He rejected the first set of Macintosh case moulds because the internal layout wasn't aesthetically pleasing — even though no customer would ever see the inside. He insisted the engineering team sign the interior of the case, like artists signing a painting.
These acts were deeply unscalable. A CEO reviewing individual pixels doesn't scale. A CEO demanding beautiful internal circuitry on a sealed product doesn't scale. But the cumulative effect was a product with a coherence and intentionality that no committee-designed computer could match. The original Macintosh team was 100 engineers working in a single building with a pirate flag on the roof. Jobs knew every person's name and what they were working on. That intimacy — impossible at scale — produced a machine that users described in emotional terms competitors' products never inspired.
The pattern repeated at NeXT, at Pixar, and during Jobs's return to Apple in 1997. Each time, the breakthrough came during a phase of unscalable founder intensity. The iPod emerged from a team of roughly 35 engineers that Jobs met with weekly. The first Apple Store in Tysons Corner, Virginia, opened in May 2001 after Jobs personally approved every fixture, sight line, and material — visiting the prototype store in a warehouse dozens of times over six months. The iPhone was developed by a team small enough that Jobs reviewed individual interaction animations frame by frame.
Each product emerged from a small team where Jobs's personal involvement in every decision created a product density that scaled processes could maintain but never originate.
Phil Knight started selling running shoes out of the trunk of his Plymouth Valiant at track meets across the Pacific Northwest in 1964. He'd import Onitsuka Tiger shoes from Japan, pack them into his car, and drive to high school and college meets where he'd set up next to the track and sell directly to runners.
The operation was absurd. A Stanford MBA working as a CPA by day, hawking shoes from his car on weekends. But each sale was a conversation. Knight talked to runners about what they needed — lighter shoes, better traction on wet tracks, more cushioning for longer distances. His co-founder, University of Oregon track coach Bill Bowerman, used this feedback to modify and eventually design shoes. Bowerman's famous waffle-sole innovation in 1971 — pouring urethane into his wife's waffle iron — emerged from years of listening to the specific complaints of runners that Knight brought back from those track meets.
By 1969, Blue Ribbon Sports (later renamed Nike) had $300,000 in revenue. Knight was still selling in person. He hired former runners as salespeople — Jeff Johnson, his first full-time employee, drove up and down the California coast visiting running clubs and track teams, building personal relationships with coaches and athletes. Johnson kept index cards on every customer. He wrote them personal letters. He mailed them Christmas cards.
The company's first million customers were acquired through a network of personal relationships that resembled a community more than a distribution channel. When Nike introduced the "swoosh" logo in 1971 and began scaling through retail partnerships, the brand already had a foundation of runner loyalty built one handshake at a time. The relationships Knight and Johnson built at track meets didn't just sell shoes. They created the culture of athletic authenticity that separated Nike from every shoe company that tried to compete on features alone.
Section 6
Visual Explanation
Section 7
Connected Models
Mental models operate in networks. Do Things That Don't Scale gains its full power when connected to adjacent frameworks — some that reinforce it, some that create productive tension, and some that represent its natural next step.
Reinforces
Product/Market Fit
Marc Andreessen coined the term in 2007: "Product/market fit means being in a good market with a product that can satisfy that market." But how do you find it? Not through A/B tests or growth experiments — those optimise an existing product. You find it through the raw, unscalable contact with users that Graham describes.
Every canonical product/market fit story involves a phase of unscalable effort: Airbnb photographing apartments, Stripe installing integrations, DoorDash delivering food. The unscalable work is the mechanism through which founders discover what users actually need — and product/market fit is the outcome of that discovery. Scale before fit and you amplify a product nobody loves. Do things that don't scale and you earn the understanding that makes fit possible.
Reinforces
Iteration [Velocity](/mental-models/velocity)
The speed at which a startup learns and adapts is its most durable advantage. Unscalable founder effort is the fastest feedback loop available. When you personally install your software on a user's laptop, you learn in real time what's confusing. When you personally deliver the food, you discover the restaurant's bottleneck that afternoon — not next quarter.
Doing things that don't scale compresses the feedback cycle from weeks to hours. Each manual interaction is a rapid iteration cycle: observe the problem, hypothesise a solution, test it with the next user. This is why the founders who do unscalable work learn faster than the founders who build dashboards — the latency of manual observation is near zero, while the latency of aggregated data is measured in sprints.
Tension
[MVP](/mental-models/mvp)
Section 8
One Key Quote
"Actually startups take off because the founders make them take off."
— Paul Graham, 'Do Things That Don't Scale' (2013)
Section 9
Analyst's Take
Faster Than Normal — Editorial View
Graham's essay is the most useful piece of startup advice ever published. It's also the most ignored. Not because founders disagree with it — everyone nods — but because the emotional cost of doing things that don't scale is higher than the intellectual cost of understanding why you should.
The real barrier is ego. A Stanford MBA founder raising a seed round wants to talk about TAM, growth loops, and platform strategy. They don't want to admit that the highest-leverage thing they could do this week is sit in a customer's office for four hours watching someone struggle with their onboarding flow. The unscalable work feels beneath the role. Founders want to be strategists. Graham is telling them to be servants first.
The best founders I've watched operate have an unusual tolerance for this discomfort. Brian Chesky still does periodic "host stays" — sleeping in Airbnb listings to experience the product firsthand. Jeff Bezos packed boxes. Sam Walton drove a Cessna. Phil Knight sold from his car. These weren't PR stunts. They were deliberate acts of information gathering that only work when the person doing them has the authority to act on what they learn. A CEO who discovers a warehouse needs packing tables can order tables that afternoon. A middle manager who makes the same discovery writes a memo that enters a queue.
The model's deepest insight is about information quality, not customer service. Unscalable effort generates a kind of knowledge that no other method can produce. Surveys tell you what people say. Analytics tell you what people do. Sitting next to a user watching them work tells you what people feel — the frustration, the workaround, the moment of delight, the point where they give up. That emotional granularity is the raw material from which great products are built. And it's only available through direct, unscalable observation.
The essay has a blind spot worth naming: it underweights the transition problem. Going from "do things that don't scale" to "do things that scale" is where most companies that got the first part right still stumble. The founder who personally onboarded every user for the first year has to eventually build a self-serve flow. The company that hand-wrote thank-you notes has to eventually automate communications. The challenge is encoding the unscalable insight into the scalable system without losing the quality that made the insight valuable.
Stripe is the best example of this transition done well. The "Collison installation" — Patrick personally integrating the API for developers — couldn't scale past a few hundred users. But the insights from those installations were encoded into Stripe's documentation, its error messages, its API design, and its onboarding flow. Today, a developer integrating Stripe experiences something that feels personal and carefully designed — because it was, originally, by a founder sitting next to them. The unscalable work didn't disappear. It was translated into a product that delivers the same quality at a million times the scale.
Section 10
Test Yourself
Scenario-based questions to sharpen your recognition. Can you spot the model — and tell real unscalable effort from its imposters?
Is this mental model at work here?
Scenario 1
A SaaS startup has 30 customers. The CEO personally conducts a 45-minute onboarding call with every new user, watches them navigate the product via screen share, takes notes on every point of confusion, and ships fixes the same week based on what she observes. Her co-founder tells her to build a self-serve onboarding flow instead.
Scenario 2
A marketplace startup has 5,000 active users. The founder still personally approves every new seller listing, writes custom feedback on rejected submissions, and conducts a phone call with each new seller. The team is backlogged. Users complain about slow listing approvals. Two engineers sit idle waiting for product direction.
Scenario 3
In January 2013, the DoorDash founders launch PaloAltoDelivery.com — a simple landing page listing menus from local restaurants. When orders come in, the founders drive to the restaurant, pick up the food, and deliver it to the customer themselves. They do this for six months before hiring their first driver.
Scenario 4
A B2B startup hires 20 sales development reps to cold-call prospects before the founders have personally sold the product to a single customer. The SDR team generates meetings but can't close deals because nobody on the team understands the buyer's real objections. The CEO blames 'sales execution' and hires a VP of Sales.
The primary source. Graham lays out the full argument with Airbnb, Stripe, and Wufoo as central examples. Short enough to read in fifteen minutes. Dense enough to reread every time you're tempted to automate something you don't yet understand. The opening line alone — "Actually startups take off because the founders make them take off" — is worth the click.
The definitive account of Airbnb's journey from air mattresses to a $100 billion company. Gallagher documents the New York trips, the professional photography programme, and the door-to-door host recruitment in granular detail. The chapters on the 2009 near-death experience — when unscalable effort literally saved the company — are essential reading for anyone who thinks "doing things that don't scale" is a nice idea rather than a survival strategy.
Knight's memoir of building Nike from a car-trunk operation into a global brand. The early chapters — selling Tigers at track meets, building relationships with coaches one by one, relaying runner feedback to Bill Bowerman — are a masterclass in unscalable founder effort. Knight didn't set out to apply Graham's principle. He lived it two decades before the essay existed.
Walton's autobiography, published the year of his death, documents decades of store visits, associate conversations, and competitor reconnaissance that no executive at his scale should have had time for. The book is a case study in how unscalable habits compound into structural advantages. Walton's yellow legal pad — filled with observations from his flights — is the physical artifact of a founder who never stopped doing the work himself.
The essential complement. Hoffman and Yeh argue for prioritising speed over efficiency once product-market fit is established. Read alongside Graham's essay, the sequencing becomes clear: Graham tells you what to do before you've earned the right to scale (unscalable effort), and Hoffman tells you what to do after (scale as fast as possible). The transition between the two is where most of the hard decisions live.
Leaders who apply this model
Playbooks and public thinking from people closely associated with this idea.
Do Things That Don't Scale — The paradox of unscalable effort creating scalable companies
The Minimum Viable Product philosophy says ship the smallest possible version and let the market respond. Do Things That Don't Scale says augment your product with extraordinary personal effort that the product itself can't deliver yet.
The tension is productive: MVP minimises product investment, while unscalable effort maximises service investment. The resolution is that they work in sequence. Ship the MVP to get something into users' hands. Then layer unscalable effort on top — manual onboarding, concierge service, personal follow-ups — to compensate for everything the MVP doesn't yet do. The MVP tests whether the core idea resonates. The unscalable effort reveals what the full product needs to become.
Tension
[Distribution](/mental-models/distribution)
Distribution thinking asks: how do we reach the maximum number of people efficiently? Do Things That Don't Scale asks the opposite: how do we serve each person so intensely that they become our distribution?
The tension is temporal. In the early stage, unscalable effort is the distribution strategy — each hand-served user becomes an evangelist who reaches others on your behalf. At scale, you need systems. The founders who fail the transition try to maintain unscalable intensity with 10,000 users, burning out their team. The founders who succeed encode the unscalable insights into the product itself — Stripe's seven-line integration, Airbnb's professional photography programme — so the product delivers at scale what the founder once delivered by hand.
Leads-to
Network Effects
Unscalable founder effort often seeds the network effects that eventually power scalable growth. Airbnb's door-to-door host recruitment in New York created a critical mass of quality listings in a single city. That density attracted guests. Guests attracted more hosts. The network effect kicked in — but only because the founders had manually loaded one side of the market with enough quality to make the flywheel spin.
The pattern repeats across marketplace businesses: Uber's early drivers were recruited individually by operations managers in each new city. Etsy's early sellers were recruited at craft fairs in Brooklyn by co-founder Rob Kalin. LinkedIn's early professionals were recruited one email at a time by Reid Hoffman, who personally invited his 500 most connected contacts in Silicon Valley. In each case, the unscalable recruitment created the initial density that network effects require. Without the manual push, the flywheel never starts turning.
Leads-to
Founder-Market Fit
The concept of founder-market fit — the idea that the best founders have deep, often personal understanding of the market they serve — is frequently cited as a pre-existing condition. But Do Things That Don't Scale reveals that founder-market fit can also be earned through unscalable effort.
Tony Xu didn't start DoorDash with deep logistics expertise. He earned it by delivering food for six months. Phil Knight didn't start Nike as a shoe designer. He became one by selling shoes from his car and relaying runner feedback to Bill Bowerman. The unscalable work is the mechanism through which founders acquire the intimate market understanding that outsiders interpret as innate "fit." The fit isn't given. It's built — one manual interaction at a time.
The companies that fail this transition fall into two traps. The first is nostalgia: clinging to unscalable practices past their useful life, creating bottlenecks and founder burnout. The second is amnesia: scaling so aggressively that the original insights get lost, and the product regresses to the generic, impersonal mean. The art is in the encoding — capturing what the founder learned during the unscalable phase and building it permanently into the product's DNA.
One question the model doesn't answer well enough: how do you know when to stop doing unscalable things? There's no clean threshold. The honest answer is that you stop when the unscalable effort stops generating new insights — when each new user interaction confirms what you already know rather than revealing something you didn't. That saturation point varies by company, by market, by product complexity. For Airbnb, it was roughly the first year in New York. For DoorDash, it was the first six months of founder deliveries. For Phil Knight, it was arguably the first five years. The model gives you the starting point but not the stopping point. That judgment call is what separates founders who build enduring companies from founders who build artisanal hobbies.
The principle applies far beyond startups. A teacher who spends the first month of school learning every student's name, interests, and learning style is doing something that doesn't scale — she can't maintain that intensity for 150 students all year. But the investment pays compound interest in classroom engagement, discipline, and student trust. A doctor who spends 45 minutes with a new patient instead of the standard 15 is doing something that doesn't scale — but the diagnostic accuracy of that first visit shapes every treatment decision that follows. A manager who spends her first month in a new role sitting with each team member for a full working day is doing something that doesn't scale — but the operational understanding she gains is unavailable through any number of status meetings.
The universal version of Graham's principle: in any domain, the highest-quality information comes from direct, unmediated contact with the thing you're trying to understand. That contact is always unscalable. It's always uncomfortable. And it's always worth more than the scaled alternative.
The companies that internalize this principle share a common trait: they treat the unscalable phase not as a burden to endure but as a competitive weapon to deploy. Chesky still does host stays. Bezos still reads customer complaint emails. The best founders never fully stop doing things that don't scale — they just become more selective about which unscalable things are worth their time as the company grows. The principle doesn't expire. It graduates.
