Most project advice is structured wrong. You get a list of ideas, you pick one, you follow a tutorial, and a few weeks later you've got a half-finished repo you'll never open again. That's not a you problem. That's the advice being broken.

---

The skill-first trap

The standard approach goes like this:

1. You google "software engineer internship requirements"
2. You see React, Node, whatever
3. You google "React project ideas"
4. You find a tutorial
5. You follow along and build the same thing thousands of other people built
6. You lose interest halfway through, or you finish it and never touch it again

I call this skill-first thinking. You start with the technology and try to work backwards to an idea. On the surface it seems reasonable. You need to learn React, so you build a React project. What's wrong with that?

Quite a bit, actually.

You almost always end up in tutorial hell. When the idea came from a search, there's already a tutorial for it. So you follow along, copy what they write, and end up with a project you didn't really build and don't actually understand. You're reciting, not learning. A lot of classes work this way too, and it's not great there either.

You limit yourself before you even start. When you're anchored to a specific technology, there's a voice in the back of your head asking "can React even do this?" before the idea is fully formed. You unconsciously trim anything that feels too ambitious. But the most valuable stuff comes from overextending yourself and figuring it out anyway. Reading docs at 2am because you're stuck. Googling things you don't have names for yet. That's where the real learning is.

And you burn out. These projects feel like homework because they basically are. You have no personal stake in them. When you're juggling classes, clubs, and everything else, "I should work on my todo app" loses to literally anything every single time.

None of this means skill-first projects are worthless. You're still picking up the technology. But there's a better way to go about it.

---

The idea-first approach

Forget the tech stack. Completely. Don't think about it yet. Here's the order that actually works:

1. Identify your passion or the space you already exist in
2. Find the pain point inside that space - something broken, missing, or annoying
3. Define the idea without filtering for feasibility yet
4. Then pick your stack around the idea
5. Build it, share it, and take the feedback seriously

My example: I'm a huge D&D nerd. When I was deep in a campaign, the prep work was brutal. Writing an entire world, NPCs, plot hooks, all of it on the fly. At the time, GPT-3.5 had just dropped and it was kind of a piece of junk, but I thought: what if it could help me brainstorm ideas? Not write the story. Just help me think through it.

So I built it. My first version was a desktop .exe. Seemed logical at the time. Then two things happened.

First, I realized all my save data lived in a raw text file, which meant nothing synced between my laptop and desktop. Second, I sent it to my mom to show her. Windows Defender flagged it nine different times. She couldn't open it.

Neither of those problems would have shown up in any tutorial. But both of them forced me to actually learn things: why databases exist, how web apps share data across clients, why distributing software the way I did was a bad idea. I didn't follow a guide for any of it. I had a problem and had to figure it out.

That messy path is what the education actually looks like.

---

Why this works

When your idea is novel enough, there's no tutorial for it. That's the whole point.

Instead of finding someone who's already done what you're doing and copying their steps, you have to identify the actual concepts you need and learn those. There's a real difference between a code-along tutorial and a conceptual one. A code-along has you typing exactly what someone else typed. A conceptual one teaches you what an API is and how to implement one, without telling you what to build. The second one generalizes. The first one doesn't.

Going idea-first gives you a few things skill-first never does:

• Domain expertise. If you build a tool for a space you actually live in, you understand the problem at a level that someone who just picked a random project idea doesn't. You can sit in an interview and explain your decisions with real thought behind them.
• Real novelty. Recruiters have seen hundreds of todo apps. They probably haven't seen your specific weird idea. That gap matters more than most people think.
• Valuable failures. If you start with an idea and pick a tool that turns out to be wrong for it, that failure teaches you something no tutorial can: when to reach for what. Getting it right the first time every time means skipping a whole layer of understanding.
• Something you'll actually finish. When you're building something you want to exist, you'll push through the hard parts. Projects you don't care about die the second they get difficult.

---

The interview story changes too

If you build something you actually care about, there's a real chance other people want it too. Put it on Reddit. Post it in a relevant Discord. See what happens.

If you get users, even a handful, what you talk about in interviews changes completely. Instead of "I built this to learn React," you're talking about:

• Feedback you got from real people
• What broke when someone used it differently than you expected
• How you iterated on the design based on that
• What you'd think about if the user count kept growing

That's the full software development lifecycle. Recruiters know what it looks like. A polished tutorial clone doesn't give you any of that material.

---

How to actually execute

Consistency beats intensity. Two or three hours a week, every week, will get you further than cramming for a week and disappearing for a month. When you're learning new things, long breaks mean you spend the first hour of every session just getting back to where you were. Keep the thread going.

The general flow:

1. Learn concepts before you build. Not code-alongs where you copy line by line, but things that teach you what concepts are and why they exist. Get enough of a foundation so when you get stuck, you know what to search for and how to ask for help.
2. Break your project into features, write them down, and start building. If you're working with someone else, figure out who's owning what early.
3. Once something is working, put it in front of people. Post it somewhere real.
4. Take the feedback seriously and go back to step 2. That loop is where the growth actually happens.

On AI: be disciplined. For a learning project, having it write your code means you built nothing you actually understand. There's a difference between using it to help you debug or think through an approach versus using it to skip the part where you actually learn. The former is a tool. The latter leaves you with a repo you can't explain in an interview.

---

The short version

Find the space you're already in. Find the pain point inside it. Define the idea without filtering for feasibility. Pick your stack, build it, share it, take the feedback seriously.

The best project you can build isn't on any list. It's the one you actually finish.