Paul Graham is an essayist, programmer, and investor who co-founded Y Combinator in 2005 with Jessica Livingston, Robert Morris, and Trevor Blackwell. Earlier he co-founded Viaweb, an early software-as-a-service company that Yahoo acquired in 1998 and turned into Yahoo Store, and he created Hacker News. He stepped back from his day-to-day role at Y Combinator in February 2014, handing the president role to Sam Altman, and continues to publish widely read essays at paulgraham.com.

What can founders learn from Paul Graham?

Founders model four moves from Graham: make something people want (real demand is the only durable moat), do things that don't scale (manual, unscalable work in the early days is how you find the real problem), treat equity in something big as worth more than a salary, and standardize the boring parts (the SAFE removed weeks of financing negotiation) so your team can focus on the product. The common thread is staying close to users.

What are Paul Graham's most influential essays?

Two come up most among founders. 'How to Make Wealth' (2004) argues that a startup lets founders compress a working life into a few years by combining measurement and leverage, with equity as the vehicle. 'Do Things That Don't Scale' (2013) argues that early founders should recruit users one by one and deliver the service by hand to find the real pain point. Both still show up verbatim in how founders explain their decisions.

Is Paul Graham still involved with Y Combinator?

Not in a day-to-day operating role. He stepped down and handed the president role to Sam Altman in February 2014. His influence continues through the standards he set (the 'make something people want' motto, the SAFE, and the early-stage advice in his essays), which founders still quote, and through Hacker News, which runs under Y Combinator.

Paul Graham: The Founder Playbook

Paul Graham is the essayist and investor who co-founded Y Combinator, and more founders quote paul graham than any other single voice in early-stage startups. Before Y Combinator, he co-founded Viaweb (an early software-as-a-service company that Yahoo bought in 1998 and turned into Yahoo Store), built Hacker News, and started publishing essays at paulgraham.com that now draw roughly 25 million page views a year. He handed the president role at YC to Sam Altman in February 2014, but the standards he set still run through the way tech founders build. This playbook pulls the principles he wrote down and shows how founders in our knowledge base actually run them.

His profile is where he still argues in public, but the durable material is the essays. Read them as operating instructions, not inspiration.

Make something people want: demand is the only moat

The Y Combinator motto Graham set is four words: make something people want. It sounds obvious until you watch how often founders skip it and optimize everything else first. Graham's point is that demand is the one thing you cannot fake your way past, and it is still the sentence founders reach for when they explain why their company survived.

In Harshil Mathur: AI Is Compressing Every Moat, Razorpay co-founder Harshil Mathur puts it plainly: "The only thing that you kept us going is like there were enough customers. As YC says, make something people want." A YC Root Access guest says the same thing in This AI Startup Is Taking Over Phone Sales: "The tagline of YC is make something people want." Two very different companies, one rule underneath.

So what: in an AI market where models and features get copied in weeks, real demand is the moat that lasts. Before you tune your prompts or your pricing, get five users who would be genuinely upset if your product disappeared. If you cannot find them, no amount of engineering fixes that.

Do things that don't scale: the manual work finds the real problem

In "Do Things That Don't Scale" (July 2013), Graham argued that early founders should do the manual, unscalable work: recruit users one at a time, deliver the service by hand, sit inside the problem. The instinct to automate too early hides the thing you most need to learn.

In Emergent: How Six Months of Tinkering Led To A $100M ARR Company, the founder ties this directly to Graham's essay: "Doing things that don't scale really helps you get close to the customer, understand the real pain point." That closeness is what a $100M ARR path was built on, not a clever growth loop.

So what: AI makes it tempting to ship an agent and let it run before you understand the workflow. Resist that at the start. Onboard your first users by hand, watch where your agent fails them, and treat every manual save as a spec for what to automate later. The unscalable phase is where you learn what to build.

Compress a working life into a few years: equity over salary

In "How to Make Wealth" (May 2004), Graham argued that a startup lets founders compress a whole working life into a few years by combining measurement (a small team where output is visible) and leverage (technology), with equity as the vehicle that captures the upside. It is a case for owning something, not renting your time.

The essay does real work on real decisions. In Why Two IIT Engineers Turned Down $550K Jobs To Build A Startup, a YC founder credits it for the leap: "I read Paul Graham's essay on how to do wealth. It essentially boils down to doing a company and having or like doing equity in something big." That essay talked two engineers out of $550K salaries.

So what: AI has lowered the cost of building enough that a very small team can now reach the measurement-and-leverage combination Graham described. If you are choosing between a comfortable salary and equity in something you believe people want, run his math honestly. The point is not to romanticize the grind; it is to own a real share of real value.

Standardize the boring parts so founders can build

Graham's YC did not only write essays; it removed friction. The SAFE, introduced under Graham-era YC in 2013 (our base credits Graham and Jessica Livingston with introducing it), replaced weeks of financing negotiation with one standard document. That is a first-principles move: find the repetitive tax every founder pays and delete it.

In Stanford CS153 Frontier Systems | The AI Native Company, YC's Garry Tan describes the moment: "Into that mess stepped um Paul Graham and Jessica Livingston and introduced a new standard for how capital should be allocated. And that was called the SAFE." He does not undersell it: "The arc of Silicon Valley would have looked very different without that one document."

So what: look at your own company for the SAFE-shaped problem. What negotiation, doc, or setup step does every customer or hire grind through? Standardize it once so your team spends its attention on the product, not the paperwork. For the deeper version of building lean, see our review of The Lean Startup.

Stay close to customers, wherever you are

Read across Graham's essays and the base founders who follow him and one habit sits underneath everything: proximity to users. Make something people want assumes you know what they want. Do things that don't scale is a method for getting there. The essays keep pointing back to talking to real people and building the feedback loop tight.

So what: this is the operating habit that makes the rest work, and it is exactly where solo and small AI teams have an edge, because there is no layer between the builder and the user. If you build alone or lean, our guide on how to build like a team shows how to keep that customer loop tight without more headcount. For the wider Y Combinator playbook, see our YC hub.

What to copy this week

Write down the one sentence a real user would say about the problem you solve, then find five people who agree; if you cannot, you have not made something people want yet.
Pick one thing you were about to automate and do it by hand for your next ten users; log where it breaks so you know what to build.
Run Graham's wealth math on your own situation: what is the equity worth if you actually make something people want, versus the salary you would trade away.
Find the SAFE-shaped tax in your company (a doc, a negotiation, a setup step every customer repeats) and standardize it once.
Put one recurring hour on your calendar to talk to users directly, and treat it as the input that decides the week.

AI Operating System for Startups