How I Choose Projects to Work On

I have too many project ideas.

That is not a flex. It is mostly a problem.

AI coding tools make it easier than ever to start something. You can spin up an app, test a concept, generate a landing page, wire up a database, and get a rough prototype working way faster than you could a few years ago. That is a real advantage.

It also creates a trap.

When starting is cheap, it is easy to confuse motion with commitment. You can have five promising ideas, three half-built prototypes, a few domains, a notes app full of product names, and still not have one thing that is actually getting better every week.

I am trying to avoid that.

So I have been using a simple filter before I let a project become a real priority.

The four questions

The filter is intentionally plain:

Do I actually have this problem?
Will other people use it or find it helpful?
Does the problem affect a lot of people, or at least a meaningful group of people?
Would I be willing to work on it for a long time even if it never made money?

That is it.

Not a market-sizing spreadsheet. Not a pitch deck. Not a twelve-step startup framework. Just four questions that force me to slow down before I turn every interesting thought into a serious project.

The goal is not to kill ideas. The goal is to protect attention.

Do I actually have this problem?

This is the first question because it cuts through a lot of noise.

There are plenty of problems I can understand intellectually but do not feel personally. I can imagine the user. I can describe the pain. I can probably build something polished around it.

But if I do not actually have the problem, I am starting at a distance.

That does not mean every founder has to be the exact target customer. Plenty of great products are built by people who learned a market deeply. But for side projects, especially early ones, personal pain is a useful filter. It gives you taste. It gives you urgency. It gives you a reason to keep working after the initial excitement wears off.

If I am solving my own problem, I do not need to invent the first user. I am the first user.

That matters.

Will people actually use it?

Personal pain is not enough.

I can have a real problem that is too specific, too weird, or too solvable with a small script nobody else needs. That can still be worth building for myself, but it probably should not become the thing I go all in on.

So the second question is about usefulness outside my own head.

Would someone else understand the problem quickly? Would they care enough to try a solution? Would it save them time, reduce stress, help them make money, help them communicate, help them learn, or help them avoid a painful mistake?

This is where it is easy to lie to yourself.

“People would probably use this” is not the same as evidence. It is a guess. Sometimes that is fine at the idea stage, but I want to be honest about what kind of confidence I actually have.

The stronger version is: “I know people who have this problem, they already spend time or money trying to solve it, and this would make their life easier.”

That is a much better signal.

Does it matter to enough people?

The third question is about scale.

Scale does not always mean venture-scale. It does not have to mean millions of users. A project can be worth building if it deeply helps a smaller group of people.

But the group has to be real.

If a problem affects a meaningful number of people, the project has room to grow. There are more conversations to have, more workflows to understand, more distribution paths to test, and more chances that the work compounds.

If the problem only exists for me and three other people with the same exact setup, I might still build it. I just should not pretend it is bigger than it is.

This is where I want to be especially careful with AI.

AI makes it easy to build niche tools. That is good. But it also makes it easy to build tiny tools that feel like products because they have nice interfaces, generated copy, auth, billing, and a logo. A polished app is not the same as a meaningful problem.

The question is not, “Can I build this?”

The question is, “Is this problem worth building around?”

Would I keep going if it never paid off?

This is the question that catches the most ideas.

It is easy to be excited about a project when the fantasy is working. You imagine the launch. The users. The revenue. The tweet that does well. The clean product page. The feeling that you picked the right thing.

But most projects do not feel like that for very long.

They become debugging sessions, awkward positioning decisions, empty analytics dashboards, messy edge cases, unclear feedback, and long stretches where nobody seems to care yet.

So I want to ask the uncomfortable version early:

Would I still be willing to work on this if it never made money?

Not forever. Not in an unhealthy way. But long enough to learn from it. Long enough to make it good. Long enough to become the kind of person who understands the problem better than most people talking about it.

If the answer is no, that does not make the idea bad. It just means I should be careful about making it a major commitment.

The projects most worth doing are usually the ones where the work itself still feels meaningful.

One serious side project at a time

The other rule I am trying to follow is focus.

One serious side project at a time.

That is hard, because juggling projects feels productive. You always have somewhere to put your energy. If one project gets difficult, another one is fresh. If one idea loses momentum, a new one gives you the hit of starting again.

But that can also leave everything half-built.

AI makes this worse in a subtle way. Because the tools are so capable, it is tempting to believe you can seriously push two or three projects at once. And maybe you can for a short stretch. You can generate a lot of code. You can keep multiple repos moving. You can produce demos quickly.

But going all in on a project is not just code output.

It is taste. It is distribution. It is talking to users. It is noticing the small product decisions. It is coming back to the same problem after the exciting part is over. It is making the thing simpler, sharper, and more useful over time.

That kind of attention does not split cleanly.

So my current approach is simple: pick one serious project, apply the four-question filter, and give it a real shot. If it stops making sense, close the loop honestly and move on. But do not keep every idea half-alive just because AI makes it possible.

The point

I am not trying to create a perfect decision system.

I am trying to create enough friction that I do not chase every idea.

For anyone building with AI right now, I think that matters. The bottleneck is shifting. It is less about whether you can start and more about whether you can choose, focus, finish, learn, and keep improving the right thing.

So before I take a project seriously, I want it to pass the four questions:

I have the problem.
Other people would use it or find it helpful.
The problem matters to enough people.
I would still care enough to work on it without a guaranteed payoff.

If an idea passes that filter, it is worth a real shot.

If it does not, maybe it is still worth a weekend. Maybe it is still worth a prototype. Maybe it is still worth writing down for later.

But it probably should not become the thing.

And that distinction matters more than ever.