Paul Graham Was Wrong When He Said "Do Things That Don't Scale"

Paul Graham's essay "Do Things That Don't Scale" is one of the most quoted pieces of startup advice ever written, and for good reason. The core idea, that founders should manually recruit users, deliver white-glove onboarding, and learn directly from early customers, is genuinely useful. But somewhere along the way the advice hardened into gospel. Founders started treating unscalable hustle not as a temporary learning phase, but as a permanent operating philosophy.

That's the problem. This isn't a teardown of Graham's advice. It's a cautionary take on what happens when you worship the hustle for too long: you quietly accumulate strategic and organizational debt that shows up right when you can least afford it. The advice was never wrong. It's just dangerously incomplete when taken as a blueprint instead of a tool.

Why Focusing Too Much on Non-Scalable Tactics Derails Your Organization

Doing things that don't scale is supposed to be a phase, not an identity. When it becomes the default, several failure modes compound at once.

Opportunity Cost and Misallocated Capacity

Startups live and die by how they allocate limited time and energy. When founders pour hours into personalized onboarding, manual outreach, and one-off support well past the initial learning phase, they do it at the expense of building scalable systems, refining the product, or testing broader market opportunities. Every hour spent on something that won't scale is an hour not spent positioning the business for growth. The cost isn't just the work you're doing, it's the leverage you're not building.

Building Bad Habits and User Expectations

Over-relying on non-scalable tactics creates a misleading sense of traction. Founders get comfortable solving problems by hand, hopping on Zoom calls, tweaking features for one specific customer, and offering concierge support. As volume grows, those habits become liabilities. Worse, early users spoiled by direct access to the founders may churn the moment the experience shifts to self-serve. You've trained your best customers to expect something you can never deliver at scale.

Neglecting Scalable Infrastructure from the Start

Even at the earliest stage, startups benefit from thinking about scalability. That doesn't mean over-engineering. It means laying groundwork: reusable code, clean architecture, automated onboarding flows, and support tooling that can absorb rising volume. Ignoring all of this in favor of pure hustle produces crippling technical and operational debt later, exactly when scaling fast matters most and you have the least slack to fix it.

Missing the Market Timing

Speed matters. In many markets the first mover or fastest scaler wins. If you spend too long perfecting the experience for 50 users, you can miss the broader wave and hand market share to competitors with more scalable operating models. Depth of care for a tiny cohort is no defense against a rival who reached ten times the market while you were still hand-holding.

Confusing Personalized Success for Product-Market Fit

Getting love from a handful of users you've worked hard to support feels amazing, and it can be dangerously misleading. That love may not come from the product at all. It may come from the personalized effort behind it. True product-market fit is when the product works without the founder constantly propping it up. Heroic manual effort masks the real work still needed to get there, and it can convince you that you've arrived when you haven't left the driveway.

Struggling to Shift from Scrappy to Scalable

Culture is sticky. If your early team gets used to doing everything by hand, pivoting to a systems-first, productized way of working is genuinely hard. Startups that over-index on hustle often struggle later to become companies that scale, because the DNA to operate any other way simply isn't there. The behaviors that won the first 50 customers become the constraint that blocks the next 5,000.

Empire Building and Unnecessary Overhead

Over-relying on non-scalable tactics quietly invites empire building. Manual workarounds lead to hiring teams to manage the workarounds. Those teams inflate operating costs and divert resources from product and infrastructure. They can also stifle innovation and manufacture an illusion of progress through sheer activity. This is the Linear Growth Trap in its earliest form: revenue that can only grow as fast as headcount, with manual work hardening into permanent org structure. Ultimately, this focus on manual effort undermines the very thing it was meant to enable, efficient and sustainable growth.

A Better Way: Use Unscalable Work to Build Scalable Systems

To be clear, I'm not saying never do things that don't scale. Early-stage startups absolutely should roll up their sleeves and learn directly from users. The real questions are how, and when to stop. Here's a more balanced approach.

Use Non-Scalable Work to Inform Scalable Systems

Talk to users. Onboard them by hand. Answer support tickets yourself. But treat every interaction as a data point, not a permanent job description. Ask constantly: How could this be automated? What patterns are emerging across customers? Then build the tools and processes that remove the need for the manual effort. Unscalable work should be a research instrument that feeds a system, not the system itself.

Design for Scale Early, Even If You're Not Scaling Yet

Don't wait until you're overwhelmed to think about scale. Start with the mindset that every manual thing should eventually be automated. Consider infrastructure, documentation, onboarding flows, and internal tooling early, so you're not scrambling to catch up when volume arrives. Designing for scale early is not premature optimization. It's refusing to build a business that can only run on founder heroics.

Learn Fast, Then Shift Gears

Use high-touch approaches to gain deep insight early, but attach clear goals and milestones to them. Once you've learned what you need, deliberately wean off the hands-on tactics. Scale is the ultimate test of product-market fit, and you won't know whether you're ready until you let go. Set the exit criteria before you start, so "temporary" doesn't silently become "forever."

Set Expectations, Internally and Externally

Be transparent with both users and your team about what's temporary and what's part of the long-term experience. If early customers expect concierge support forever, you're engineering future pain. Build a culture that values learning quickly and evolving constantly, so the shift from scrappy to scalable feels like the plan rather than a betrayal.

From Scrappy to Scalable Is the Real Job

Graham's advice isn't wrong. It's just incomplete if you treat it as gospel. "Do Things That Don't Scale" should be a tool, not a blueprint. Used wisely, it helps founders unlock powerful insight and build a product users love. Used as a crutch or a comfort zone, it quietly throttles growth and delays the hard, necessary work of building a business that can actually scale.

Startups succeed not just by being scrappy, but by evolving fast. So yes, do things that don't scale, but only long enough to figure out how to build something that does. The founders who win are the ones who know the difference between learning by hand and being trapped by it. That shift, from labor to leverage, is the whole discipline behind Product Led Revenue: using early, unscalable work to design the product and systems that carry growth without carrying headcount.

If you want a fast read on whether your own organization is already sliding from scrappy into structurally stuck, take the free Quick Test and see where your growth model is leaning on labor instead of leverage.