How to Tell if Your Startup Idea Is Actually Good

Stop asking 'is this a good idea' and start asking better questions

Almost every founder I talk to opens with the same line: I have an idea, do you think it's good? It feels like the right question. It isn't. Nobody, including you, can judge an idea in the abstract. An idea is just a sentence until someone tries to use it and pay for it.

The useful question is narrower. Who exactly has this problem? How badly do they feel it today? What are they doing about it right now? Would they pay to make it go away? Once you frame it that way, you stop debating opinions and start gathering evidence. That shift, from defending the idea to interrogating it, is the whole game.

The four things a good idea actually needs

Strip away the jargon and a workable idea sits on four legs. Knock any one out and the table falls over. Walk through these honestly before you fall in love with your own pitch.

• A real problem. Not a mild annoyance, not a problem only you have. Something people already spend time, money, or stress trying to solve.
• A reachable audience. You can find and talk to these people without a huge ad budget. If you can't describe where they hang out, you can't sell to them.
• Willingness to pay. Someone, somewhere, already pays to solve this in some clumsy way. Free problems rarely build businesses.
• Your ability to deliver. You, or a small team, can build a first version and actually get it into people's hands within a few months, not a few years.

Is it a real problem, or just an interesting one?

The most common trap is the vitamin disguised as a painkiller. A painkiller solves something that hurts now. A vitamin is nice to have but easy to skip. Founders love vitamins because they sound visionary. Customers ignore them because nothing forces a purchase.

Look for evidence the problem already costs people something. Are they paying for a half-working tool, hiring someone, juggling three spreadsheets, or doing tedious manual work every week? That existing effort is your proof. If the honest answer is that people just live with it and don't really mind, that is a yellow flag, no matter how clever your solution is. Reading up on problem validation vs solution validation helps you separate the two so you don't fall in love with a fix for a problem nobody has.

Talk to people before you trust your gut

Your gut is biased. You want the idea to work, so your brain quietly filters for reasons it will. The cure is boring and effective: go talk to the people who supposedly have this problem. Not your friends, not your co-founder, not your mum. Actual potential customers.

Keep the conversation about their life, not your idea. Ask what they did the last time they faced this problem, what they tried, what it cost them, and what made them give up or settle. The moment you pitch, people get polite and useless. If you want a structured approach, our guide on how to do customer interviews lays out the questions that get honest answers.

• Ask about past behaviour, not future intentions. 'Would you use this?' gets a yes that means nothing.
• Listen for emotion. Frustration, workarounds, and money already spent are the strongest signals.
• Talk to at least 10 to 15 people in your target group before you draw any conclusion.

Test demand with a small, honest experiment

Conversations tell you whether a problem exists. They don't prove people will pay. For that you need a demand signal, and you can get one cheaply long before you build anything. A simple landing page describing the offer, a sign-up form, or a pre-order can tell you far more than a hundred surveys.

The strongest signal is someone parting with money or doing real work to get access. A waitlist email is weak. A small advance payment, a booked call, or a card on file is strong. If you can get even a handful of people to commit something real, you have a far better answer than any opinion. Our walkthroughs on building a landing page to test demand and pre-selling before you build show how to do this without writing a line of backend code.

Run the idea through a few hard filters

Once you have some evidence, pressure-test it with a short checklist. None of these alone kills an idea, but a pile of red flags should make you pause. Be ruthless here. It is cheaper to kill a weak idea on paper than after you have spent six months and your savings on it.

1. Can you reach customers affordably? If acquiring each customer costs more than they will ever pay you, the unit economics are broken from day one.
2. Is the market big enough for your goal? A niche is fine for a lifestyle business, risky if you want to raise money and scale.
3. Why hasn't someone already nailed this? Sometimes the answer is timing or a new tool. Sometimes it's because the problem is genuinely hard to solve profitably.
4. Can you build a usable first version quickly? If the minimum viable product needs years of R&D, that is a different kind of bet.
5. Do you actually want to spend the next few years on this? Conviction matters when the early excitement fades.

Common signs your idea needs more work

Some patterns show up again and again in ideas that struggle. None are fatal, but each is a signal to dig deeper rather than charge ahead. The goal is not to find a perfect idea, it is to find one with fewer fatal flaws than the alternatives.

• Everyone says it's a great idea but nobody offers to pay or pre-order.
• You can't clearly name the one person who has this problem most painfully.
• Your only honest advantage is 'we'll work harder' or 'ours will be cheaper'.
• The problem is real but so small or rare that you'd need a huge audience to make any money.
• You keep widening the idea to please everyone, which usually means it serves no one well.

Good enough to start beats perfect on paper

Here is the part founders hate. You will never be certain. Plenty of now-obvious businesses looked silly at the start, and plenty of clever pitches went nowhere. The point of all this testing is not certainty. It is to lower your risk enough that taking the next concrete step is sensible.

If a problem is real, the audience is reachable, a few people have shown they'll pay, and you can build a first version in a reasonable time, that is a green light to start small. You don't validate your way to a finished company. At some point you commit, ship something rough, and let real usage teach you the rest. A good idea is mostly one you've de-risked enough to act on with a clear head.