# The best Paul Graham startup essays, and how I apply them as an engineer
Eight Paul Graham startup essays that changed how a software engineer turned founder works, with how each one shows up in AISynq, InstinctGTM and an AI-native build.
- Author: Radwan Altaf (https://radwanaltaf.com)
- Published: 2026-10-08
- Topics: Startups, Engineering
- Canonical URL: https://radwanaltaf.com/writing/best-paul-graham-startup-essays
- Disclosure: Essay quotes are taken from paulgraham.com and Hacker News scores from the public Hacker News search API, both checked on 8 October 2026. Career and venture details are the ones on my CV and venture pages. No client detail is included.
---
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](https://paulgraham.com/ds.html) 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](https://paulgraham.com/articles.html), 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](https://hn.algolia.com/api) and kept the highest
score for each essay. These are the startup-building essays, by score:

1. [Founder Mode](https://paulgraham.com/foundermode.html), 1,330 points
2. [Do Things that Don't Scale](https://paulgraham.com/ds.html), 1,275
3. [How to Get Startup Ideas](https://paulgraham.com/startupideas.html), 914
4. [How to Start Google](https://paulgraham.com/google.html), 737
5. [Before the Startup](https://paulgraham.com/before.html), 703
6. [Schlep Blindness](https://paulgraham.com/schlep.html), 604
7. [Startup = Growth](https://paulgraham.com/growth.html), 586
8. [What I've Learned from Users](https://paulgraham.com/users.html), 519
9. [Maker's Schedule, Manager's Schedule](https://paulgraham.com/makersschedule.html), 383
10. [Default Alive or Default Dead?](https://paulgraham.com/aord.html), 322
11. [Ramen Profitable](https://paulgraham.com/ramenprofitable.html), 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](/writing/how-to-become-an-ai-native-software-engineer).

### 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](/ventures/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](https://ifrs18navigator.com) 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](https://www.ifrs.org/issued-standards/list-of-standards/ifrs-18-presentation-and-disclosure-in-financial-statements/),
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](/ventures/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](https://vibetribee.com), 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](https://paulgraham.com/growth.html) 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](https://paulgraham.com/foundermode.html) 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](/writing/how-to-become-an-ai-native-software-engineer).
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.