Everyone says stop doing courses and build something, every idea I have is either trivial or impossible

The gap is real and it exists because you are looking for project ideas, which is the wrong search. Ideas that sound like products are either trivial or enormous. What works is much smaller and much less impressive.

Look for annoyances in your own week, not for products. Something you do by hand that a computer could do. The bar is deliberately low:

• Rename a folder of files to a consistent pattern
• Pull the numbers out of a monthly statement into a spreadsheet
• Tell you when a specific page changes
• Work out which of two things is cheaper, with your actual numbers
• Sort your photos by the date in the file rather than the date they were copied

None of these are portfolio pieces and that is not the point. What they have that a to-do list does not is that you know when they are correct, because you have the real data and you can check. That is the thing a tutorial cannot give you, and it is where the learning actually happens.

They are also naturally the right size: a few hours to a weekend, so you finish, which matters more than what you built.

The test for a good first project: can you describe what it does in one sentence, and would you actually use the result. If yes to both, build it.

The other route, and it works well for people who freeze at the blank page: rebuild something that already exists, then change it.

Pick something small and well understood, a URL shortener, a markdown previewer, a simple game, a command line tool you already use. You do not have to invent the specification, which removes the paralysis, and you can check your version against the real one at every step.

Then, and this is the part that matters, break it on purpose and change it. Add a feature the original does not have. Make it handle a case it does not. That transition, from following a known shape to deviating from it - is exactly the skill you are missing, and it is much easier to practise when you already have something working.

On getting stuck an hour in and losing the thread: that is not a sign the project was wrong. Getting stuck is the job. The difference between a course and a project is that a course removes the stuck part, which is why courses feel productive and teach less.

What helps concretely:

Write down the specific question when you get stuck, before searching. It slows the drift.

Timebox the search. Twenty minutes, then try something even if it is wrong.

Stop at a point where you know the next step, so tomorrow starts with typing rather than remembering.

One reframe that changed this for me: finishing is the skill, not building.

Almost everyone at your stage has three half-projects. The half you never do is the last twenty percent, the error handling, the case where the file is empty, the thing that happens when the network is down, making it work on someone else's machine. That part is boring, it is where all the real learning is, and it is what actually separates people who can build things from people who have done courses.

So choose the smallest project you can stand, and take it all the way to done. Done means: someone else could run it, it does not crash on obvious bad input, and there is a note saying what it is.

One finished trivial project teaches more than three abandoned ambitious ones. That is not a motivational line, it is about which parts of the work you are exposed to.

And on the second to-do list teaching you nothing: correct, because you already knew how to build it. The project has to contain something you cannot currently do, otherwise it is typing practice. One unknown per project is about right. Two is fine. Five is how you get stuck for a week and go back to a course.

Pick the annoyance, keep it small, and finish it.