Build Projects You'd Actually Use (Then Make GitHub Show Them Off)

One question filters out most bad project ideas:

Would I actually use this every day?

If the answer is no, find something else. A project you don't use is just a tutorial with extra steps.

A four-step brainstorm

1. List your organizations. Clubs, teams, student orgs, Greek life, research labs, volunteer groups. Which of their processes are broken or manual?
2. List your daily frustrations. Scheduling, coordinating, tracking, searching, communicating. Any repetitive task that eats your time is a project.
3. Pick a skill you want to learn. React Native, ML, distributed systems. The project should stretch you toward something you'd use at work.
4. Find the overlap. Where those three meet is your project. You'll use it, you'll learn from it, and you'll talk about it with real energy.

Tutorial project vs. one that stands out

Todo apps, weather apps, e-commerce clones with no users, chat apps with no angle, calculators. Everyone has one, and the giveaway is that you can't explain why you built it and you never used it after.

A project that stands out solves your own real problem, has actual users (even five counts), forced you to make design decisions, can be demoed in two minutes, and is still deployed and working.

Idea starters

Adapt these to your own situation:

• Club leaders: a meeting scheduler that finds times across the exec board's calendars, QR check-in with an engagement dashboard, or one announcement that posts to Discord, email, and the website at once.
• Students: a study group matcher by class and time, a course review aggregator, or a dashboard that pulls Canvas deadlines into one prioritized view.
• Part-time workers: replace your manager's inventory spreadsheet, build a shift swap board with one-tap approval, or a tip splitter by hours worked.
• Athletes: a pickup game finder, a crowdsourced gym capacity tracker, or a practice scheduler with equipment checkout.
• Career-focused: an application tracker with conversion rates, spaced repetition for behavioral stories, or a networking CRM that reminds you to follow up.

If you want ideas tailored to you, I made a Claude Code skill, project-brainstorm. Tell it "help me brainstorm projects," it asks about your life, then gives you ideas with tech stacks and interview talking points.

Talking about it in an interview

A four-beat structure works well (example lines, not a real project):

1. The problem. "My club was wasting two hours a week coordinating schedules by hand."
2. A design decision. "I chose WebSockets over polling because members needed real-time updates."
3. The impact. Users, time saved, how long it's been running.
4. What you'd change. "If I rebuilt it, I'd use OAuth instead of email and password."

Now make GitHub sell it

Recruiters spend about 30 seconds on your GitHub. In rough order, they look at your profile README, your pinned repos, those repos' READMEs, recent activity, and commit messages. Actual code quality only matters if they click into a file, which is rare in 30 seconds.

Profile README

Create a repo with the same name as your username and add a README.md. Keep it scannable:

# Hey, I'm [Your Name]

## What I'm building
[One sentence about your main project or focus]

## Tech I work with
[Your main stack, not every language you've touched]

## Currently
- CS student at [University]
- Building [project]: [one-line description]
- Looking for [internship / SWE role]

## Connect
[Portfolio] · [LinkedIn] · [Email]

Pinned repos

You get six. Pin projects that solve a real problem, things you shipped and deployed, open source you're proud of, and repos with clean READMEs and screenshots. Show some range.

Don't pin school assignments, tutorial follow-alongs, forks you never changed, "hello-world" repos, or abandoned projects with no README.

Repo READMEs

Someone should understand the project in 10 seconds. A good README has a one-sentence summary, a live demo link, screenshots, the problem it solves, the tech stack, a few architecture decisions with reasons, run-locally steps, and what you learned.

Commit messages

Your history shows how you think. Use conventional prefixes:

The two-minute stuff

A real photo, a bio with your role and stack, location, a website link, a status, and your school. And please: no API keys or passwords in any repo.

About the green squares

Don't commit empty files to keep a streak or run auto-commit scripts. Recruiters care much more about what you ship than how often you commit. One well-documented project with a live demo beats 365 days of meaningless commits.