The best Paul Graham startup essays, and how I apply them as an engineer

In this article I will go through the Paul Graham essays on building startups that changed how I work, what each one actually says, and where I have applied it: in my engineering career, in my AI consultancy AISynq, in InstinctGTM, in the two companies I am a technical partner in, and in the AI-native way I now build software. Where I have not managed to follow one, I will say so.

To begin with, the problem.

Engineers read Paul Graham and hear the parts that flatter them. He was a programmer, he writes about hackers with obvious affection, and his essays are full of people building things. It is easy to finish one feeling that the job is to build something great and the rest will follow.

He says the opposite, and he says it to engineers directly. In Do Things that Don't Scale he explains why founders resist recruiting users one at a time: "One is a combination of shyness and laziness. They'd rather sit at home writing code than go out and talk to a bunch of strangers and probably be rejected by most of them." The next sentence is the one that matters: "But for a startup to succeed, at least one founder (usually the CEO) will have to spend a lot of time on sales and marketing."

For most of my career, that sentence did not apply to me, because somebody else had already done the selling. On the work I did at DHL, at AT&T and DIRECTV, and on the Singapore Government portal I built features for as an Accenture contractor, the requirement arrived already sold, and my job was to turn it into software. That is a real job, and I still do it. It is a different job from the one these essays describe.

What are Paul Graham's startup essays?

Paul Graham's startup essays are the pieces on paulgraham.com, most of them written since he co-founded Y Combinator in 2005, that explain how startups get ideas, find users, make money and grow. In simple words, much of what they say is advice YC gave founders in person, written down once so it did not have to be repeated.

They are different from his essays on writing, programming languages or society, although some people read all of them as one body of work. They are also different from most startup advice, because they are short on frameworks and long on what actually happened to particular companies.

There is no official list of the best ones, so I used the closest thing to a vote. I pulled every Hacker News submission of a paulgraham.com essay through the Hacker News search API and kept the highest score for each essay. These are the startup-building essays, by score:

1. Founder Mode, 1,330 points
2. Do Things that Don't Scale, 1,275
3. How to Get Startup Ideas, 914
4. How to Start Google, 737
5. Before the Startup, 703
6. Schlep Blindness, 604
7. Startup = Growth, 586
8. What I've Learned from Users, 519
9. Maker's Schedule, Manager's Schedule, 383
10. Default Alive or Default Dead?, 322
11. Ramen Profitable, 264

It is important to note that votes measure what one community liked, and older essays were submitted when Hacker News was much smaller. Ramen Profitable scoring 264 probably says more about 2009 than about the essay. I will use eight of these below, in the order they became useful to me rather than the order they scored.

The eight essays, and what I did with each

1. How to Start Google: get good at something by building your own things

This is the most recent of the eight, a 2024 talk to 14 and 15 year olds, and it is the one I would hand an engineer first. He says you need three things to start a successful startup: "You need to be good at some kind of technology, you need an idea for what you're going to build, and you need cofounders to start the company with." To the question of how to get good, he gives one answer: "work on your own projects."

The line I return to is what happens once you are good: "when you look at the world you see dotted outlines around the things that are missing."

What it meant for me. I started as a freelance developer on Upwork in 2015, building HTML and jQuery templates for paying clients, and in 2016 I built my first iOS game in Swift. Nobody asked for the game, which is what made it a project of my own in his sense. The dotted outlines came much later, after years inside payment flows, logistics apps and streaming apps, and the clearest recent example is in how I run AI agents. Claude Code runs on my own server in long sessions, sometimes overnight for nine hours or more. The missing piece was control: something that let agents deploy to staging on their own while a production deploy waited for my approval. I built an ops layer for it, which holds the encrypted credentials and the task queue and makes production wait for me. I doubt I would have seen that outline without years of shipping to production the old way.

How to apply it. Pick one technology that interests you and build one complete thing with it every year, outside work, from idea to something a stranger can use. If you are an engineer moving into AI, make that thing an agent workflow you run yourself, end to end, on infrastructure you control. I wrote about that shift in How to become an AI-native software engineer without getting slower.

2. How to Get Startup Ideas: build what you need yourself

His opening line is "The way to get startup ideas is not to try to think of startup ideas. It's to look for problems, preferably problems you have yourself." He calls ideas that grow out of a real problem "organic", and ideas invented to sound like a startup "made-up" or "sitcom" ideas.

What it meant for me. InstinctGTM is the most organic idea I have. Running AISynq meant doing my own go-to-market with no marketing team, and the way I put the problem on InstinctGTM's site is that a founder working alone can keep about two channels going while the rest go dark. InstinctGTM writes content for each channel, watches for signals that a company is ready to buy, and drafts outreach that I approve before it sends. It is in closed beta, and I use it on my own companies before I sell it to anyone else. In other words, the first user is me, which is what Paul Graham means by a problem you have yourself.

IFRS 18 Navigator came the other way. The problem was not mine. The idea came from an executive at an accounting firm, and I built the first version of the product as a technical partner with a 10% stake. That is still an organic idea in his sense, because it came from someone who works next to the problem rather than from a brainstorm. The lesson I took is that if you do not have the problem, you need a partner who does, and you should be honest about which of you that is.

How to apply it. Write down every problem you hit at work for two weeks, including the boring ones. Keep the ones you would pay to have fixed. If none of them are yours to solve, find the person with the problem and build with him or her rather than for an imagined market.

3. Schlep Blindness: the boring problem is the opportunity

A schlep is "a tedious, unpleasant task", and Paul Graham's point is that our dislike of schleps is mostly unconscious: "Your unconscious won't even let you see ideas that involve painful schleps." His example is Stripe's idea. "For over a decade, every hacker who'd ever had to process payments online knew how painful the experience was," and when those same hackers started companies, "they decided to build recipe sites, or aggregators for local events."

What it meant for me. I have spent years inside exactly that schlep. My engineering work in payments has included e-wallets, remittance, eKYC identity checks, QR payments, FPX bank transfers and Plaid. None of it is glamorous and all of it is regulated. Having done it, I no longer read "integration with a regulated provider" as a reason to avoid an idea. I read it as a reason fewer people will compete.

IFRS 18 Navigator is a schlep business too. The IFRS 18 standard, issued in April 2024, replaces IAS 1 and is effective for annual reporting periods beginning on or after 1 January 2027. Every company reporting under IFRS has to work out how each line of its income statement is presented under the new rules. Thus, the work is tedious, the deadline is fixed, and the people who have to do it cannot avoid it. That is about as clear a schlep as exists.

How to apply it. Make a list of the integrations, compliance tasks and data migrations that engineers on your team avoid or complain about. Each one is a problem that somebody has, that somebody pays for, and that most founders will not even consider.

4. Do Things that Don't Scale: do the selling by hand

This is the essay that names the engineer's habit, and the one with the most practical examples. The most common unscalable thing founders must do, he writes, "is to recruit users manually". The Airbnb founders went "door to door in New York, recruiting new users and helping existing ones improve their listings." The Collison brothers did not send beta links. When someone agreed to try Stripe, they said "Right then, give me your laptop" and set it up on the spot.

What it meant for me. AISynq is where I learned this. I run the whole cycle myself: the outreach, the sales call, the scoping, the build and the launch. Through my own outreach I have delivered over $90K of software projects so far. That figure is not large next to a funded startup, and I am not presenting it as one. It is evidence of the one thing this essay says engineers avoid, which is finding the customer yourself.

The engineering version of the "give me your laptop" move is doing the setup for the customer. At VibeTribe, a health programme company where I am a co-founder and technical partner with a 5% stake, I built the web platform and a React Native app, and I wrote a WordPress plugin so the existing site renders cleanly inside the app. It is not the architecture you would design for a million users. It meant the content already in WordPress could appear in the app without being rebuilt natively, which is a thing that does not scale and did not need to yet.

How to apply it. Find ten people with the problem and talk to them this month, by name, before you build the next feature. If one says yes, set it up for him or her yourself, on a call, the same day.

5. Startup = Growth, and Ramen Profitable: be honest about what you are building

Startup = Growth opens with a definition, "A startup is a company designed to grow fast", and then rules most companies out: "A barbershop isn't designed to grow fast. Whereas a search engine, for example, is." Ramen Profitable adds the warning most relevant to me. The biggest danger of early profitability "is that it might turn you into a consulting firm", because "consulting just can't scale the way a product can." He also says "It's ok to do a little consulting-type work at first."

What it meant for me. By his definition, AISynq is not a startup, and I do not call it one. It is a consultancy. It pays, and it is where I learned to sell. InstinctGTM is the startup bet, because it is a product that could serve many founders without me in the room.

Keeping the two separate matters, because without the definition it would be easy to describe consulting revenue as startup traction, and he names exactly that trap: "telling yourselves you're a ramen profitable startup, when in fact you're not a startup at all."

How to apply it. Write down, for each thing you run, whether it is designed to grow fast. If it is not, that is fine, and it may be the thing that funds the one that is. The mistake is reporting one with the numbers of the other.

6. Default Alive or Default Dead?: know your own runway

The question is simple: "Assuming their expenses remain constant and their revenue growth is what it has been over the last several months, do they make it to profitability on the money they have left?" He says half the founders he asks do not know the answer, and the essay links a calculator by Trevor Blackwell so you can work it out.

What it meant for me. I will be plain about this. I still work full time as a senior software engineer, and my ventures run alongside that job. Thus, they are default alive in the least glamorous way possible, because my living costs are covered by a salary rather than by them. That takes the pressure off, and it is also a real cost, because a part-time founder almost certainly moves more slowly than a full-time one. I would rather know which of those I am than pretend otherwise.

How to apply it. Before you quit anything, put your own numbers into the calculator: monthly costs, monthly revenue, recent growth. If the answer is default dead, you know what the next six months are for.

7. Maker's Schedule, Manager's Schedule: give the agents the night shift

The essay explains why programmers hate meetings: a maker works in units of at least half a day, and "a single meeting can blow a whole afternoon". Paul Graham's own fix, back in his first startup, was to "program from dinner till about 3 am every day", then do business work in the day, so that "in effect I had two workdays each day, one on the manager's schedule and one on the maker's."

What it meant for me. AI agents changed this essay for me more than any other. The maker's half of the day can now run while I am asleep. My Claude Code sessions sometimes run overnight for nine hours or more, against a written task, and every build runs against a regression list so that a bug fixed once does not come back. The agents test first, and then I test by hand. The work that needs a person, the calls, the selling and the decisions, stays with me.

It is important to note that this only works because the work was specified before I went to sleep. An agent on the maker's schedule with a vague task does nine hours of the wrong thing very efficiently.

How to apply it. Write tomorrow's build task tonight, with a definition of done and a command that proves it. Give it to an agent before you stop for the day. Use your daytime hours for the parts that need a person.

8. Founder Mode: decide where autonomy ends

Founder Mode is the highest-scoring startup essay in the list, and it is about why founders were told to "hire good people and give them room to do their jobs", and why that advice damaged their companies. He does not argue for no delegation. He says: "Where the borders of autonomy end up, and how sharp they are, will probably vary from company to company. They'll even vary from time to time within the same company, as managers earn trust."

What it meant for me. I read that sentence as a description of how to run AI agents, which is not what he wrote it about, and I think it fits better than most writing about agents does. My borders are explicit. Agents deploy to staging on their own, while a production deploy needs my approval through the ops layer, and agents get read-only access, only to data that is not sensitive. InstinctGTM follows the same rule for outreach: it drafts, and nothing sends until I approve it. In my view the borders should move only as an agent earns trust on a particular kind of task, which is the same thing he says about managers.

How to apply it. For every agent or automation you run, write down three things: what it may do alone, what needs your approval, and what it may never touch. Review the list monthly and move the borders only on evidence.

The idea in one sentence

Paul Graham's startup essays are mostly instructions for doing the parts of the job that engineers avoid, and AI agents make them more relevant rather than less, because code is now the cheap part.

When writing the code was the expensive part, an engineer had a respectable reason to stay at the keyboard. That reason has largely gone. Agents can produce the code overnight, so the scarce work is the work in these essays: finding the problem, finding the user, selling, and deciding where autonomy ends. Thus, the "shyness and laziness" he describes in Do Things that Don't Scale are harder to excuse in 2026 than they were in 2013.

It is important to note that cheap code is not the same as cheap software. Checking what an agent produced still costs real time, which is the whole argument of the AI-native engineering piece. Even so, the time saved on writing is time an engineer can now spend on users, and the essays say that is where it should go.

How to apply them this week

In order of leverage, for an engineer who wants to build a company:

1. Talk to ten people with the problem before writing more code. This is Do Things that Don't Scale, and it is the one most engineers skip.
2. Name your problem honestly. Is it yours, or a partner's? If neither, it is a made-up idea.
3. Separate the consulting from the startup in your own numbers, even if you run both.
4. Work out whether you are default alive with real figures.
5. Write down the borders of autonomy for every agent and automation.
6. Give the agents the maker's schedule and keep your daytime for people.
7. Build one project of your own in a technology that interests you, and finish it.

How engineers misread these essays

Reading them as permission to keep building. Every one of them pushes the other way. If an essay leaves you wanting to write more code, read it again.

Automating outreach before doing it by hand. Do Things that Don't Scale is about learning what works by doing it yourself. An agent sending messages you have never sent manually is scaling a process you do not understand yet.

Calling consulting revenue startup traction. Ramen Profitable names this trap directly.

Treating "live in the future" as permission to ignore the present. The line in How to Get Startup Ideas is "Live in the future, then build what's missing." The second half requires somebody who is missing it now.

Copying Y Combinator advice for a company that is not trying to be a YC company. Much of this advice assumes venture-scale growth. If you are building a good service business, some of it does not apply, and Paul Graham says as much when he writes that most people should not try to start startups.

The limits of these essays, and of my own record

I would rather be straight about the limits, including my own.

They are written from the winners' side. Paul Graham's evidence is Y Combinator's portfolio. In What I've Learned from Users he says that once you have advised a hundred startups you rarely see a problem you have not seen before. That is real pattern recognition, but it comes from companies that got into YC and, in the famous examples, survived. The founders who followed the same advice and failed are much less visible.

Most of them assume full-time founders. I do not work on my ventures full time, and I cannot yet tell you what that costs in speed. I suspect it is a lot.

I have no growth numbers for InstinctGTM yet. It is in closed beta. By Paul Graham's own definition, I do not know whether it is a startup until it grows, and I am not going to claim that it does.

Technical partner roles are not founding in his sense. At VibeTribe and IFRS 18 Navigator I hold 5% and 10% stakes and do the technology and advising. The founders carry the company. The lessons above apply to my part of the work, not to theirs.

Applying Founder Mode to agents is my reading, not his. He wrote about people. I think the borders-of-autonomy idea transfers well to software agents, but nobody has tested that, including me, beyond my own setup.

Frequently asked questions

What are the best Paul Graham essays for startups? Measured by Hacker News votes, the most read startup essays include Founder Mode, Do Things that Don't Scale, How to Get Startup Ideas, How to Start Google, Before the Startup, Schlep Blindness and Startup = Growth. For a working founder I would add Default Alive or Default Dead?, Ramen Profitable and Maker's Schedule, Manager's Schedule, because they deal with money and time rather than ideas.

Which Paul Graham essay should a software engineer read first? Do Things that Don't Scale. It names the engineer's habit directly, that founders would rather sit at home writing code than go out and talk to strangers, and it explains why a startup needs at least one founder to spend a lot of time on sales and marketing.

What does "do things that don't scale" mean? It means doing work by hand at the start that you could never do for a million users, such as recruiting users one by one or setting the product up for them yourself. Paul Graham's examples are the Airbnb founders going door to door in New York and the Collison brothers installing Stripe on a prospect's laptop on the spot.

Is a consultancy a startup, according to Paul Graham? No. In Startup = Growth he defines a startup as a company designed to grow fast, and in Ramen Profitable he warns that the biggest danger of early profitability is turning into a consulting firm, because consulting cannot scale the way a product can. He adds that a little consulting-type work at first is fine.

What is schlep blindness? It is Paul Graham's name for the way people fail to even notice good startup ideas that involve tedious, unpleasant work. His main example is Stripe's idea. For years every hacker who processed payments online knew how painful it was, and almost nobody tried to fix it.

Do Paul Graham's essays still apply now that AI agents write code? More than before. Most of his startup advice is about the work that is not code, such as finding users, selling, and deciding what to build. AI agents make code cheaper to produce, which removes the engineer's usual reason for avoiding that work.

Start with the one you are avoiding

Pick the essay above that made you most uncomfortable, and do its "how to apply it" step this week. For most engineers, including me for most of my career, that is Do Things that Don't Scale.