Is my startup idea good, or am I just excited?

Because confirmation bias does not feel like bias. Confirmation bias is the habit of noticing evidence that agrees with you and brushing off evidence that does not. Once you are excited, you remember the three people who said "I'd use that" and forget the ten who changed the subject.

The stakes are real. In CB Insights' report The top 9 reasons startups fail (5 March 2026), poor product-market fit appeared in 43 percent of 385 failed investor-backed startups. That counts only failures where the causes could be identified. Product-market fit means enough people want what you built to pay for it or keep using it. Failures could have several causes at once. That study covers investor-backed companies only, not every small project.

Clear answers to four questions, none of which ask how the idea feels:

1. Is the market real? Do people already spend money or painful amounts of time on this problem?
2. Is there a wedge? A wedge is a narrow first group you can actually reach and win. "The market is huge, so a sliver is enough" is not a wedge.
3. Why now? What changed recently that makes this possible or urgent?
4. What is the riskiest assumption? This is the single belief the whole idea depends on.

Every idea has a riskiest assumption. If you cannot name yours, that is your first finding.

Demand means people want the thing badly enough to act. To judge it, rank the evidence you have. The nommi Evidence Ladder is our own way of ordering evidence, from weakest to strongest. It is a nommi framework, not an outside study:

1. praise ("love it");
2. stated future intent ("I would use that");
3. the same problem described by several people;
4. a small commitment, like joining a waitlist;
5. a bigger commitment of time, like a long call or a trial;
6. money, like a preorder or a deposit;
7. real use of something you built;
8. repeat use, people coming back without being asked.

Most early excitement sits on the bottom two rungs. Friends' encouragement usually does too, as the piece on friends saying they'd use it explains.

Test the riskiest assumption, and nothing else first. Building tests everything at once, so it tests nothing cleanly. Most first tests cost time, not money: ten conversations with people who have the problem, a simple page describing the offer, or asking for a small deposit or preorder.

Our plain advice: find a few people willing to pay before you build. Payment intent comes first and the product second. To find those people, see whom to talk to and where.

Some ideas can only be judged by using them, like a game or a new kind of social app. For those, conversations can mislead in both directions. A tiny working version may be the honest test.

The missing fact is whether people can judge the value without trying it. If they cannot, build the smallest version that tests the one belief and measure what people do with it.

You describe the idea, who it is for, and where you are: just an idea, building, or already live. Idea Validator returns one of three verdicts, Build it, Sharpen it or Kill it. It gives the reasoning and how confident it is, and names the riskiest assumption and a test for it. When it cannot confirm a fact, it is designed to say so rather than invent one.

Sharpen it is not a soft yes. It means there is a specific test to run before you build. Kill it means something structural is against you, and the next step is finding a better idea, not spending more on this one.

Here is an illustrative example, not a real founder or a real tool run. Say your idea is a browser extension that turns design files into website code, sold as a monthly subscription.

The market is real, and that is the problem. If established tools already do most of this, some of them free, your wedge is weak. A useful test: message fifteen people who use the existing options. Ask what they would pay a solo builder for that those tools do not already do. If nobody names a specific gap, consider releasing the work free to build your reputation instead.

A read like this will not help once you have revenue and want to grow it. It also does not replace talking to the people you think will pay. It makes sure those conversations test the right belief.

Write your riskiest assumption as one sentence. Under it, write the cheapest test that could prove it wrong within seven days. Run that test before you write another line of code.