How to tell if an idea is worth building before you build it
Most of the cost of a bad idea is the months you spend building it. Here are the cheap tests that tell you whether to keep going, run in order from least to most effort.
You have an idea you cannot stop thinking about. The temptation is to open your editor and start. Resist it for a few days. The cheapest time to kill a bad idea is before you have written any code, and there is a short list of tests you can run first, ordered from almost no effort to a bit more.
The goal is not to prove the idea is good. It is to give the idea a fair chance to prove it is bad while that is still cheap.
Test 1: Say it in one sentence to a stranger
Try to describe what the thing does in a single plain sentence, no jargon, to someone who does not already live in your head. If you cannot, you do not understand the idea well enough yet, and neither will anyone you try to sell it to.
Watch their face, not their words. People are polite and will tell you an idea is nice. What you are listening for is the unprompted "oh, I have that problem." If nobody leans in, that is not a death sentence, but it is a flag.
Test 2: Check who is already solving it
New founders fear competition. They should fear its absence more. If nobody is working on this, the likely reason is not that you are the first person clever enough to see it. It is usually that people have tried and there is no money or no demand in it.
Go find the existing options. Read their reviews, especially the angry ones. Angry reviews are a gift. They are users telling you, in detail and for free, exactly where the current tools fail them. If you find a cluster of people frustrated by the same gap, you have found a place to enter. If you find nothing at all, ask why the silence is there before you read it as opportunity.
Test 3: Find out if anyone will raise their hand
Talking is cheap and people will agree with anything in a friendly conversation. So stop asking whether they like the idea and start asking for something small but real.
The simplest version of this is a single page that explains the thing and asks for an email address. You are not collecting addresses for a mailing list. You are running a test. Will a person who lands on this give you their email to hear when it is ready? That is a tiny commitment, but it is a real one, and it tells you far more than a hundred "sounds great" replies.
Put a number on it before you start so you cannot move the goalposts afterward. We aim for a few hundred genuinely interested email signups before writing the real product. If you cannot get a small group of strangers to care enough to type their email, the problem may not be your marketing. It may be the idea.
Test 4: Build the smallest embarrassing version
Only now do you build, and you build less than you want to. The first version should do one thing, the core thing, and do it for you. If you are not willing to use a rough version yourself, you have your answer.
A good rule: if the first version does not slightly embarrass you, you waited too long to ship it. Polish is what you add once you know people care. Before that, polish is just an expensive way to delay finding out.
The order is the point
You can run all of these, but the value is in the sequence. Each one costs a little more than the last, and each is a chance to stop before you spend the next, larger amount.
Most people skip straight to building because building is the fun part and talking to strangers is not. That is exactly why building first is so risky. You spend the most expensive resource you have, months of your life, on the test you should have run last.
Run the cheap tests first. Let the idea fail while failing is free. The ones that survive all four are the ones worth your year.