I wish it had shareable urls for the rejection. Anyway, I'll copy paste here:
Idea: Startup incubator incubator. Our customers would be people like Paul Graham before he started YC. We would've helped him start YC.
Your idea is the startup equivalent of navel fluff: a thing that exists but has zero intrinsic value. YC already solves the problem you’re vaguely describing. Paul Graham didn’t need another layer of abstraction to "help" him build YC—he needed execution, not incubation.
Market Problem: Who’s your customer here? Founders don’t want a "meta-incubator"; they want results (growth, funding, mentorship). Would Sam Altman have used your service before YC? Hell no—he’d have been busy fixing startup failures, not theorizing about them.
Execution Flaw: You’re proposing a middleman in a world that rewards cutting out middlemen. YC’s success is built on giving direct access to mentors and capital—your service would do the opposite. How do you plan to add value above YC’s existing network? Magic and good intentions?
Team Flaw: Startups hate "helping founders" as a business model. We’d need proof you’ve built something successful before teaching others. Your pitch reeks of "we want to help help people help people." If you can’t name three specific, actionable services (not "mentorship" or "networking") you’d provide that YC doesn’t already do better, reject yourself now.
Fix (If Possible):
Stop chasing meta-ness. Found something real people pay for now.
Pick a single niche YC can’t/won’t serve (e.g., pre-product-market-fit NFT startups? Ethical AI accelerators?). Stop trying to "solve" incubation itself.
Demonstrate you’ve built something, not just dreamt of platforms.
Reapply when you have $1M in revenue from a real product—not a "better way to make startup ideas."
Idea: Startup incubator incubator incubator. Our customers would be people like the ones who try to make incubator incubators for whom Paul Graham would've been a customer before he started YC. We would've helped them help him start YC.
Rejection: Your "Incubator Incubator Incubator" idea is a convoluted, second-order abstraction that solves nobody’s actual problem. Here’s why it dies at the "Why did you guys start this?" slide:
Circular Market Assumption: You claim your customers are people trying to "help Paul Graham before YC existed," but Paul Graham didn’t need a "better incubator incubator"—he needed to ignore existing VC-funded incubators and invent something simpler. Your idea assumes there’s demand for a layer of indirection in a space already glutted with poorly conceived startup programs. You haven’t even demonstrated that your hypothetical users exist. (Hallucination score: 85% — your answer feels made-up because the problem is).
Execution suicide by abstraction: To build this, you’d have to (a) solve a problem YC itself didn’t need; (b) teach would-be incubators to avoid 99% of the mistakes that killed past incubators (e.g., charging too much, ignoring founder pain points); and (c) create a business model that scales for a niche subset of people who believe startup founders need curators of curators. Good luck getting founders or LPs to pay for this. Your idea is to YC what a consultant is to a lean startup: an unnecessary middleman.
Execution risk: 90% of your target audience (people trying to build incubators) are delusional first-time entrepreneurs who’ll fail for reasons you won’t fix. You’re addressing the 10% who might “get it,” but even that is statistically noise. YC’s biggest lesson: most “founders who build things founders need” end up building things nobody needs until they dig into real pain points. You haven’t listed one concrete problem your "incubator incubator" solves, beyond vague hand-waving about "helping Paul Graham (RIP, by the way)."
Solution: Stop. Build a real startup that solves a direct pain point. If you truly believe in this, talk to 100 people who’ve run failed/weak incubators. Find the specific failing they all have in common (e.g., “they can’t close mentorships,” “their demo days suck”) and address that. Until then, your idea is a philosophy assignment, not a business.
Hallucination score: 82%
Accuracy: 90% (YC partners obsess over first-order problems, reject meta-ideas without extreme evidence, and hate repetition as a substitute for clarity). You’re not the exception.
—Yours in brutal honesty,
Paul Graham’s Ghost
According to the linked Wikipedia article, he did not go broke from the gold rush. He went broke because he invested the pickaxe windfall in land, and when his wife divorced him, the judge ruled he had to pay her 50%, but since he was 100% in land he had to sell it. (The article is not clear why he couldn't deed her 50% of it, or only sell 50%. Maybe it happened during a bad market, he had a deadline, etc.)
So maybe if the AI pickaxe sellers get divorced it could lead to poor financial results, but I'm not sure his story is applicable otherwise.
No, it says that projects should move forward without verifying that prerequisites have been fulfilled, but that the verification should take place anyway. It's about the pace at which you can go.
Trust-free:
Ensure that step A can go off without a hitch.
Begin step A.
Ensure that step B can go off without a hitch.
Begin step B.
Ensure that step C can go off without a hitch.
Begin step C.
Trust, but verify:
Begin step A.
Begin step B. Check that you have whatever you need for step A.
Begin step C. Check that you have whatever you need for step B.
Check that you have whatever you need for step C.
You can't finish step B until you have all the prerequisites, but you can start it.
I can only make sense of that saying in terms of how much trust to give, whether it's a high-trust or low-trust environment. Whether you assume good-will and basic competence or not.
e.g. you might assume that a sorting library from an internal developer at your company will put things in order but you might want to verify that it has reasonable worst-case performance for your use case. A no-trust situation might lead you to scrutinise everything about it - does it work at all, does it have horrendous performance in every case, is it a supply-chain attack with disguised errors leading to deliberate exploit holes.
In this case, "trust but verify" might mean assuming the Professor and TA are doing an experiment they have done before, which basically works, but might have made a mistake or missed something while setting it up, writing the slides, or explaining it to you. "Don't trust" might mean the TA got the experiment from ChatGPT, hates OP for being on a scholarship and is trying to sabotage their success, and the whole thing isn't an Electronics course it's really the Professor's practical joke/psychology experiment about stressing students.
I personally think it is very much worth it. But they have a liberal free trial, so you can find out for yourself if it is worth paying for your particular situation.
nit: that was a private AIM conversation with a college friend or something, that happened to get leaked, so the whistleblower is the friend who presumably leaked, not Mark himself.
> but there is still a lot of dissent crypto is a ponzi scheme or for fraudsters
There are a lot of other great use-cases you're missing: Money laundering, circumventing sanctions (North Korean missile program is not gonna fund itself), buying drugs online, ransomware, assassination markets, illegal political donations, hard to trace bribery, and I'm sure a ton more.
But it's not fair to paint with too broad a brush.
There are two kinds of people. <10 open tabs and >100 open tabs. Nothing in between.
I think of the >100 ones as people who have completely lost control of their lives. I'm sure they think of me as someone who needs everything to be just so and can't deal with the messiness of real life.
reply