Paul Graham Was Wrong When He said “Do Things That Don’t Scale”

For all of you Y Combinator fans out there, let me start with this: I’m not really saying Paul Graham, the legendary Y Combinator co-founder, was “wrong”. In fact, the core insight behind his now-iconic article, “Do Things That Don’t Scale,” is incredibly important, especially for early-stage startups. The idea is to get your hands dirty, talk to users directly, and do whatever it takes to make your first users love your product. That kind of obsessive customer empathy can unlock powerful insights.

But here’s the catch: when founders take this advice too literally or too far, it can become a trap. The phrase has become a sort of dogma in startup circles — a rite of passage. And while the original spirit behind it is valuable, an overcommitment to unscalable efforts can quietly sabotage a startup’s ability to actually grow.

This post isn’t a teardown of Graham’s advice, but rather a cautionary perspective on how blindly worshipping the “unscalable hustle” can create serious strategic and organizational debt.

Why Focusing Too Much on Non-Scalable Tactics Can Derail Your OrganizationLet’s dig into the main risks of leaning too hard, for too long on unscalable processes.

Let’s dig into the main risks of leaning too hard, for too long on unscalable processes.

Opportunity Cost and Misallocated Capacity

Startups live and die by how they allocate their limited time and energy. When founders pour hours into personalized onboarding, manual outreach, or one-off customer support — especially beyond the initial learning phase — they are often doing so at the expense of building scalable systems, refining their product, or testing broader market opportunities. Every hour spent doing something that won’t scale is an hour not spent positioning the business for future growth.

Building Bad Habits (and User Expectations)

Over-relying on non-scalable processes can create a misleading sense of traction and progress. Founders get used to solving problems manually — hopping on Zoom calls, adjusting features for one specific customer, or offering white-glove support. But as user volume grows, these habits become liabilities. Worse, early users who were spoiled by the personal touch and direct access to the founder(s) may churn when the service inevitably shifts to a more self-serve experience.

Neglecting Scalable Infrastructure from the Start

Even at the earliest stages, startups benefit from thinking about scalability. That does not mean over-engineering, but it does mean laying the groundwork: reusable code, clean architecture, automated onboarding flows, or customer support tools that can handle increased volume. Ignoring this in favor of pure hustle can result in crippling technical and operational debt later — when scaling fast matters most.

Missing the Market Timing

Speed matters. In many markets, the first mover or fastest scaler often wins. If your startup is spending too long perfecting the experience for 50 users, you may miss the broader wave — and let your competitors with more scalable operating models increase market share.

Confusing Personalized Success for Product-Market Fit

Getting love from a handful of users you’ve worked hard to support feels amazing — but it can be dangerously misleading. That love might not come from the product itself, but from the personalized effort behind it. True product-market fit is when the product works without the founder constantly propping it up. Non-scalable efforts can mask the real work needed to get there.

Struggling to Shift from Scrappy to Scalable

Culture is sticky. If your early team gets used to doing everything by hand, it can be a real challenge to pivot into a systems-first, productized way of thinking. Startups that over-index on hustle early often struggle later to transition into companies that can scale — because the DNA to do things any other way is just not there.

Empire Building: Creating Unnecessary Overhead

Over-relying on non-scalable tactics can spur “empire building” across departments, where initial manual workarounds lead to the hiring of large teams to manage these unsustainable processes. This inflates operational costs, diverting resources from critical areas like product development and scalable infrastructure. Such team structures can also stifle innovation and create a misleading illusion of progress through sheer activity. Ultimately, this focus on manual efforts hinders a startup’s ability to achieve efficient and sustainable growth.

A Better Way: Strategic Use of Unscalable Tactics

Again, I’m not saying never do things that don’t scale. Early-stage startups should absolutely roll up their sleeves and learn directly from users. But there is the question of how and when to stop.

Here is a more balanced approach:

Use Non-Scalable Work to Inform Scalable Systems

Talk to users. Onboard them manually. Answer support tickets yourself — but treat every interaction as a data point. Ask: How could this be automated? What patterns are emerging? Then, build tools and processes that remove the need for manual effort.

Start Designing for Scale Early — Even if You’re Not Scaling Yet

Don’t wait until you’re overwhelmed. Begin with the mindset that every manual thing should eventually be automated. Think about infrastructure, documentation, onboarding flows, and internal tools early, so you’re not scrambling to catch up later.

Learn Fast, Then Shift Gears

Use high-touch approaches to gain deep insights early on — but set clear goals and milestones. Once you’ve learned what you need, start weaning off the hands-on tactics. Scale is the ultimate test of product-market fit, and you won’t know if you’re ready unless you let go.

Set Expectations — Internally and Externally

Be transparent with users and your team about what’s temporary and what’s part of the long-term experience. If early customers expect concierge-level support forever, you’re setting yourself up for pain. Create a culture that values learning quickly and evolving constantly.

Final Thoughts

Paul Graham’s advice isn’t wrong. It’s just incomplete if taken as gospel.

“Do Things that Don’t Scale” should be a tool, not a blueprint. When used wisely, it can help founders unlock powerful insights and build a product users love. But when it becomes a crutch or a comfort zone, it can quietly throttle growth and delay the hard — but necessary — work of building a business that can truly scale and grow.

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.

If you’re interested in digging deeper into what scaling really means — not just technically, but organizationally and strategically — I highly recommend the work of Professor Gad Allon from the Wharton School at the University of Pennsylvania. His research and teachings on operational scaling, growth models, and organizational design can be extremely valuable for founders looking to make the leap from early traction to sustainable success.

Understanding how to scale thoughtfully, not just quickly, might just be the difference between a startup that stalls and a category-defining company.