Paul Graham wrote "How to Get Startup Ideas" over a decade ago. It's still the best thing ever written on the topic.
But a lot has changed since 2013 — especially for developers. AI tools have made it easier than ever to build something. That same ease has made it harder than ever to build the right something. The traps PG described have gotten deeper. The good paths have gotten more valuable.
Here's my updated breakdown of his core ideas, with honest 2025 context added throughout.
The One Sentence That Changes Everything
PG opens with this:
"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."
This sounds obvious. It isn't. It contradicts almost everything the startup ecosystem encourages you to do.
Hackathons encourage you to think of ideas on demand. Accelerator applications ask you to pitch ideas. Twitter threads tell you to "brainstorm startup ideas in your niche." Notion templates exist for "idea generation sessions."
All of that is the wrong approach, according to PG. And based on what we've seen over the past decade, he's right.
The reason it's wrong is subtle but important: when you consciously try to generate startup ideas, you produce ideas that sound plausible but aren't. He calls these "sitcom ideas" — the kind a TV writer would invent for a character starting a company. Social network for pet owners. App for tracking restaurant wait times. A marketplace for Small Tech Startup Owners.
These ideas aren't obviously bad. That's exactly what makes them dangerous. You can waste months — even years — on an idea that was never real.
Why "Made-Up" Ideas Fail: The Pet Owner Trap
PG's pet owner social network example is worth dwelling on because it describes a failure mode that's everywhere in 2025.
The logic seems solid on paper: millions of people have pets, many spend a lot on them, surely some percentage would use a dedicated community platform. Run the math, it looks like a real market.
But when you ask actual pet owners if they'd use it, they don't say no. They say "yeah, maybe." And that's the tell.
"Maybe I could see using something like that" is not a user. That reaction, summed across millions of people, produces zero daily active users. People are being polite, not honest. They don't want it urgently. They just can't immediately think of a reason to say no.
In 2025, this pattern shows up constantly in AI products. Replace "social network for pet owners" with "AI writing assistant for Personal brands" or "AI-powered Writing for Solopreneurs." The same dynamic plays out: impressive demos, polite interest from potential users, and then flat retention curves after launch.
The test PG gives is sharp: who wants this right now, so much that they'll use a crappy version made by a two-person startup they've never heard of? If you can't name those people specifically, the idea probably isn't real.
The Well vs. The Pond: The Most Useful Mental Model in Startup Thinking
This is the most practically useful framework in the entire essay, and it's still underused.
PG describes two shapes of demand:
Broad and shallow (the pond): Many people are mildly interested. Your idea sounds appealing to a wide audience. But nobody needs it urgently.
Narrow and deep (the well): A small number of people need it desperately. They would use a terrible version. They would pay for it on day one.
Almost every good startup idea is a well, not a pond.
Microsoft's first product — Basic for the Altair — had only a few thousand potential users. But those users were programming in machine code without it. They needed it badly.
Facebook's first site was only for Harvard students. A few thousand people, but they were obsessed with it.
Stripe's early users were developers who were so frustrated with existing payment processing that they would have paid almost anything for something better.
The 2025 version of this: The best AI startup ideas right now aren't the ones with the broadest potential market. They're the ones where a specific group of people has a specific workflow that's genuinely broken, and AI can fix it in a way nothing else could. Narrow, deep, urgent. Not "everyone who writes" but "contract lawyers who review 50-page NDAs every day."
Ask yourself honestly: is my idea a well or a pond? Most ideas people are excited about are ponds.
Live in the Future, Then Build What's Missing
This is the central prescription of the essay, and it's the hardest one to actually do.
PG cites Paul Buchheit's line that people at the leading edge of a rapidly changing field "live in the future." His own synthesis:
Live in the future, then build what's missing.
What this means practically: if you're genuinely at the frontier of something — using it daily, pushing its limits, running into its walls — you will notice gaps that other people don't see yet. Those gaps are startup ideas. You don't have to go looking for them. They find you.
Dropbox didn't start with Drew Houston thinking "what's a good B2B SaaS idea?" It started with him forgetting his USB drive and thinking "this is absurd, files should just be everywhere." He was living in the reality where that was obviously missing.
Airbnb didn't start with market research into the travel accommodation sector. It started with two designers who couldn't afford rent and had an air mattress and thought "someone might pay to sleep on this."
In 2025, the most interesting "live in the future" positions are:
Building with frontier AI models daily — not writing about them, but actually integrating them into real workflows and running into their real limitations
Operating in industries that are 5-10 years behind software — legal, construction, agriculture, healthcare administration — where you encounter broken processes that software people haven't gotten to yet
Being at the intersection of two domains — PG notes this specifically: if you understand both programming and some other field deeply, you see opportunities that neither group alone can see
The point is: you can't shortcut your way to this. It requires actually being in the future, not reading about it.
The Verb Is "Notice," Not "Think Up"
One of the most clarifying lines in the essay:
"The verb you want to be using with respect to startup ideas is not 'think up' but 'notice.'"
This distinction matters enormously.
"Thinking up" ideas is a conscious, effortful, top-down process. You sit down to generate. You brainstorm. You run through frameworks. The result is almost always ideas that fit the shape of ideas rather than ideas that fit real problems.
"Noticing" is different. It's what happens when you're deep in some domain and you repeatedly run into the same friction. When you find yourself building a workaround for the fifth time. When you talk to people and they all describe the same pain. When something that should exist doesn't.
The best startup ideas almost always feel obvious in retrospect — but not because they were easy to see. Because once you were in the right position, they were hard to not see.
PG's advice on how to get yourself into noticing mode:
Work on hard problems driven by genuine curiosity
Keep a second process running that notices gaps and anomalies in whatever you're doing
Pay attention to things that chafe — annoyances are often signals that you're brushing up against something real
Build things that seem interesting, even if they don't immediately seem like companies
This last one is important. Many of the best startup ideas started as side projects that "just seemed cool." What you shouldn't do is pre-filter for "is this a big company idea?" Too early. That question kills good ideas before they have a chance to develop.
Turn Off Two Filters You Don't Know You Have
PG introduces two mental filters that prevent founders from seeing good ideas:
The Schlep Filter
This is the unconscious aversion to ideas that involve tedious, painful, or "unsexy" work. Stripe is his canonical example: thousands of developers knew how broken payment processing was. They all looked away, because dealing with payments seemed like a nightmare. So nobody built the obvious thing.
The schlep filter is especially strong for developers, because we prefer elegant solutions to messy real-world problems. We'd rather build a cool distributed system than deal with chargebacks and bank integrations.
But the schlep filter is often an illusion. The schlep that's keeping other people away from an idea is also keeping you away from competition. Stripe had comparatively easy user acquisition because no one else was trying.
The Unsexy Filter
This one keeps you from working on problems you find boring or distasteful. eCommerce seemed boring to the Viaweb founders (they built it anyway). Enterprise software seems boring to most developers. B2B SaaS for Hospitals doesn't feel like a startup story worth telling.
But unglamorous problems are often where the real money is, precisely because glamorous people avoid them.
In 2025, the strongest version of both filters is pointed at "boring businesses" — service businesses, regional markets, industries without a tech scene. These are exactly where AI can create disproportionate value, because the incumbents are weakest and the tools are newest. The founders who can turn off both filters and look honestly at what needs to be built — not what would make a good TechCrunch headline — have a real advantage right now.
Competition Is a Good Sign (Seriously)
This one is counterintuitive enough that it's worth stating directly.
When you come up with a startup idea and find that someone else is already working on it, most people's reaction is to feel late. PG says this instinct is almost always wrong.
A good idea should feel obvious — that's how you know you've found something real. And if it feels obvious to you, it should feel obvious to others too. Discovering a competitor usually means you're onto something.
What actually kills startups is almost never competitors. It's building something nobody wants. Or running out of money before finding product-market fit. Or founder conflict. Competitors are way down the list.
The one exception: if a competitor has genuine lock-in (a network effect, proprietary data, exclusive contracts) that would prevent users from switching to you even if you were better. That's worth being careful about. But a competitor simply existing? That's validation.
The 2025 addendum: In AI especially, there's a temptation to look for "white space" — areas with no competitors — as a signal of opportunity. Often it's the opposite signal. No competitors usually means no market. A crowded market means demand is real; your job is just to do something importantly different.
Google didn't avoid search because there were already search engines. They had a specific thesis about what everyone else was getting wrong.
The Recipe (When You Need an Idea Right Now)
PG is honest that the organic method — living in the future, noticing gaps — is the best approach. But sometimes you need an idea now. Here's his practical recipe for that situation:
Look for unmet needs, in this order:
Your own problems — What frustrates you daily? What workaround do you use that shouldn't need to exist? What do you wish someone would build?
Problems in your area of expertise — Not just "I'm a developer so I'll build dev tools," but specifically: what friction do you personally encounter in your domain that has no good solution?
Other people's explicit needs — Have honest conversations. Ask people what's tedious, broken, or missing in their work. Don't pitch ideas; just listen. What do they say they wish existed?
Industries that are dying or being disrupted — What's failing? Who's going to lose? And what kind of company would profit from that disruption? (Not a replacement, but something that comes in from the side.)
Waves you can ride — What technology is improving on a Moore's Law-like curve right now? Gene sequencing, AI inference costs, battery density — what becomes possible in 3 years that's impossible today? Who gets hurt and who benefits?
The filter you need when using this approach:
When you land on an idea consciously, be more skeptical than you would be with an organic idea. Organic ideas feel like inspirations. Consciously generated ideas can feel the same way — but more often than not, that feeling is misleading. The organic method has a built-in filter (you wouldn't notice something unless it was clearly missing). The conscious method doesn't. You have to supply the skepticism yourself.
The questions to ask every idea through:
Who wants this right now?
How urgently do they want it?
Would they use a bad version of it?
Is there a path from this initial group to a larger market?
What This Means for Developers in 2025
Most developers I talk to are thinking about startup ideas in exactly the wrong way.
They're trying to find the right idea, then build. The right order is almost the opposite: do work that puts you in the right position, then notice what's missing.
Concretely, that means:
Go deep somewhere real. Pick a domain — not "AI" as an abstract category, but a specific industry or workflow — and spend real time in it. Use the tools. Talk to the people. Run into the walls. You're looking for problems you can feel, not problems you can describe from the outside.
Build things that interest you, even if they don't seem like startups. The side project you build to scratch your own itch is more likely to become a real company than the idea you dreamed up in a brainstorming session.
Take the unsexy idea seriously. If an idea would make a good case study for a business school course on boring but profitable software companies — that's probably a better signal than if it would make a good TechCrunch launch post.
Stop worrying about being late. If you feel like someone else might build it first, that's a sign it's real. Move fast, but move because the problem is real, not because you're afraid of competition.
PG ends the essay with a deceptively simple line:
Live in the future and build what seems interesting.
That's still the recipe. Everything else is just commentary.
The original essay is at paulgraham.com — worth reading in full if you haven't. This post is my interpretation and update, not a summary.
What's a problem you keep running into that nobody's solved well yet? Drop it in the comments — would love to hear what people are noticing.
Top comments (0)