Kartik Kant / All lessons Chapter 1 · Figuring out what to build
Lesson 1.2

Where good ideas come from

Something stops a lot of people before they've written a line: the belief that you need a brilliant, original idea first. Something nobody has thought of. A lightning bolt.

You don't, and waiting for one is probably the most common reason people never start.

The reframe that helped me most was this. Code doesn't exist to be clever. It exists to solve a problem that some real person, business, or team already has. If your idea solves a problem someone genuinely has, it doesn't need to be original at all. If it doesn't, no amount of good code will rescue it.

Ideas are cheap, and throwing them away is the useful part

Most people have this the wrong way round. They treat the idea as precious, guard it, spend six months building it, and then discover nobody wanted it.

People who do this repeatedly learn to flip it. They generate a lot of ideas and get very good at binning them fast. The idea was never the valuable bit. Knowing which ones to walk away from is.

So the question isn't really "is this good?" It's closer to "what would have to be true for this to be a waste of my time, and is it?"

Where the real ones actually come from

Almost never from sitting down to brainstorm, in my experience. Nearly always from noticing something you'd otherwise have ignored.

The most reliable source is a problem you personally have, because you already understand the pain without having to interview anybody. What do you work around? What do you do by hand every week that irritates you? Do you have a half-broken spreadsheet doing a job software should be doing?

Second best is a problem you've watched someone else have. A job you've done, a business a friend runs, a team you sat in. If you've heard somebody sigh and say "ugh, I have to do this again" more than once, that's worth paying attention to.

Third, and underrated: something that already exists but is bad. You don't need a new category. A lot of decent businesses are just "the popular tool, except it does this one thing everyone keeps complaining about."

None of those require you to be original. They require you to pay attention, which is a different and much more learnable skill.

Look for the hole, not the market

New builders tend to research like this: is the fitness app market big? It is. That fact will not help you. A big market means big competitors with money and patience.

The more useful question is narrower. What do the existing tools structurally not do?

Structurally is the word doing the work there. Not "their design is ugly," because they can fix that next quarter. Something the shape of their whole business prevents. Maybe every tool in a space is built for teams, so solo users are stuck paying for four seats they don't need. Maybe they all demand an account before you can try anything at all.

That gap is roughly where a small new thing can survive.

A good trick for finding these, and it costs nothing: read the one and two star reviews of the popular apps in whatever space interests you. People will explain in exhaustive, furious detail exactly what's broken. Their complaints are a feature list somebody wrote for you.

Three questions that kill bad ideas quickly

Before getting attached, it helps to be able to answer these.

Who exactly is this for? If the answer is "everyone" or "young people," you don't have an answer yet. "Freelance designers who invoice more than five clients a month" is an answer, because you could go and find one this afternoon.

What do they do about it right now? There's always something, even if it's a notebook, a group chat, or just quiet suffering. If you genuinely can't find what people do today, the problem usually isn't annoying enough to have provoked a workaround, which tells you something.

Does anybody pay for anything nearby? Money already moving in a space is the best evidence you'll get that a problem is real. If nothing adjacent to your idea makes money, you might be early. More often it means people don't care enough to open their wallet.

A quick story. I learned to code in college and built a lot of projects. Genuinely a lot. Most of them went nowhere, and for a long stretch I assumed that meant I needed to build better, or work harder.

That wasn't it. They went nowhere because they didn't solve anything for anyone. They were exercises. Fun to build, technically fine, aimed at no particular person's problem.

Once that landed, I stopped worrying about whether I could build something and started worrying about whether it was worth building. That question is much harder and worth considerably more.

What this means for you right now

If you already have an idea, you probably don't need a different one. You need to check whether it points at a real problem belonging to a specific person.

If you don't have one, you're not stuck, you just haven't looked in the right place. The right place is your own week, your own irritations, and the complaints of the people around you.

If you want to pressure-test an idea

Work this chapter with Claudea prompt to run on your own project
You're helping me think through a software idea. I'm new to this, so please skip the jargon and be straight with me. My idea: [describe it in a sentence or two] Please: 1. Rewrite my idea as a specific problem for a specific person, rather than a category or an audience. 2. Tell me what people most likely do about this problem today, without an app. 3. Give me three reasons this might be a bad idea, honestly. I would rather hear it now than in six months. Don't try to make me feel good about it. I want the real answer.
Open Claude ↗

If the answers make you a bit uncomfortable, the prompt worked. Far cheaper to feel that now than after a summer of building.


Next: Finding out if anyone wants it →

Go deeper: Chapter 2, Finding and Generating Ideas and Chapter 3, Market Research

Useful? Share this lesson