Ask ChatGPT whether your startup idea is good and it will almost always tell you yes. Not because the idea is good, but because the model is trained to be agreeable, and "this could work if you execute well" is a safe, plausible thing to say about literally anything. I learned this the expensive way, twice, before I started treating the model as something to argue with instead of something to agree with.
These days I don't ask an AI "is this a good idea?" I run every idea through six failure modes and ask it to prove the idea dies in each one. If it survives all six with honest answers, I let myself write code. If it dies in even one and I can't fix that one, I kill it before I've spent a weekend, let alone a quarter. Here's the framework.
Failure mode 1: The unit economics never close
The first question isn't "will people want this." It's "if everyone wants this, do I still make money." Plenty of products people love lose a dollar on every sale and try to make it up in volume, which is how you go bankrupt at scale instead of small scale.
The test is brutally concrete: what does it cost me to acquire one paying customer, and what is that customer worth over their lifetime before they churn? If I can't answer both with a real number — not a hope, a number — the idea isn't validated, it's just exciting. AI is genuinely useful here, but only if you force it to be pessimistic. I tell it to assume my acquisition cost is double my optimistic guess and my churn is worse than I think, then ask whether the math still works. Optimistic AI answers about "viral growth" and "word of mouth" are where founders go to die. Make it do the arithmetic with bad numbers.
Failure mode 2: The timing is wrong
Most failed startups weren't bad ideas. They were the right idea three years too early or two years too late. Being early feels exactly like being wrong — nobody buys, nobody cares, and you can't tell whether the market isn't ready or your product is bad.
So I make the model build the case that the timing is wrong. What had to become true for this to work now that wasn't true two years ago? Cheaper compute? A regulation change? A behavior shift? If the honest answer is "nothing changed, this was equally buildable in 2020," that's a red flag — it means either someone already tried it and it didn't work, or there's no tailwind pushing customers around it. Good timing has a specific cause you can name. If you can't name the cause, you're betting on luck and calling it strategy.
Failure mode 3: There's no distribution path
This is the one founders hate most because it has nothing to do with the product they're excited to build. You can build the best tool in a category and still die quietly because nobody ever finds it. Distribution isn't an afterthought you bolt on at launch — it's a constraint that should shape the product from day one.
The test: name the first 100 customers and exactly how each one hears about the product, without using the words "we'll do marketing" or "it'll go viral." If the answer is a specific channel — a subreddit where these people already complain about the problem, a search query they already type, a newsletter they already read — the idea has a path. If the answer is vague, the product is a hobby. I make the AI play a skeptical investor here and refuse to accept "content marketing" as an answer. Specificity is the whole game.
Failure mode 4: Founder-market fit is missing
People talk about product-market fit constantly and founder-market fit almost never, which is backwards, because founder-market fit comes first and predicts whether you'll survive long enough to find the other kind. The question is whether you, specifically, are the right person to build this — not whether the market is attractive in the abstract.
The best products usually come from founders who have been humiliated by the problem, not merely annoyed by it. There's a difference between "this would be a nice business" and "I have lived inside this problem for years and I understand it in my body." The first kind of founder quits when it gets hard, which it always does. So I ask: what do I know about this space that 90% of people building in it don't? If the honest answer is "nothing, it just looks lucrative," the idea isn't for me, even if it's a good idea for someone else. AI will happily validate a market you have no business being in. It won't tell you that you're the wrong person — you have to ask that yourself, and answer honestly.
Failure mode 5: The market is too small or too crowded
These look like opposite problems but they kill you the same way. A market too small means even total domination doesn't add up to a business worth your years. A market too crowded means you're the eleventh option in a category where customers are already exhausted by choice, and being slightly better than ten incumbents is not a wedge.
The useful framing isn't "how big is the market" — that number is always made up anyway. It's "who is the specific person with this specific pain, and how many of them are there, and what are they using today." If the answer to "what are they using today" is "nothing, they just suffer," that's a green flag — an unserved pain. If the answer is "five well-funded tools they're mostly happy with," you need a reason to exist that goes beyond "ours is cleaner." I ask the AI to list every existing alternative including the ugly ones — spreadsheets, hiring an intern, doing nothing — because the real competitor is almost never another startup. It's the status quo, and the status quo is free and already installed.
Failure mode 6: The technical feasibility assumptions are hiding the real work
The last one is the trap I personally fall into, because building is the fun part and it's easy to assume the hard technical thing is the whole job. It almost never is. The model working in a notebook is maybe 20% of the work. The other 80% is the unglamorous infrastructure around it: latency, cost per request, error handling, what happens when the API is down, what happens when a user feeds it garbage, how you keep quality stable as you scale.
So before I write a line, I make the AI list every assumption the product relies on that I'm treating as solved but haven't actually verified. "The model will be accurate enough." "The API will stay cheap." "Users will phrase their input the way I expect." Then I ask which of those, if false, kills the product. The ones that are both load-bearing and unverified are what I test first — with the cheapest possible probe, often a spreadsheet and twenty phone calls rather than code. The medium should serve the learning, not the other way around.
Why I run all six instead of trusting a gut feeling
None of these are clever. They're the obvious questions, which is exactly why founders skip them — they feel too basic to bother with when you're excited. But excitement is the problem the framework is solving. The whole point of forcing an idea through six specific ways it could die, and forcing the AI to argue for each death rather than against it, is to counteract the single strongest bias in early-stage building: you want it to be true, and so does the model you're asking.
An idea that survives all six honest interrogations isn't guaranteed to work. Nothing is. But it has earned the right to a few weeks of your life, which is more than most ideas can say. And the ones that die in the framework died for free — on a Tuesday afternoon, in a conversation, instead of eighteen months and your savings later. That trade has never once felt like a bad deal.
If you want to run this framework automatically, I built BizChecker AI for exactly this — it stress-tests startup ideas against all six failure modes and gives you a structured kill-score. Free to try.
Top comments (0)