After reviewing hundreds of resumes, a pattern becomes clear. The “Projects” section is almost always one of two things: a list of tutorial clones (Netflix clone, Twitter clone, e-commerce app built following a YouTube series), or one interesting project buried under five that are not.

Here is what separates the side projects that make hiring managers stop and want to ask questions.

Why Most Side Projects Do Not Help

The most common mistake is building something that proves you learned a technology. A “MERN stack blog app” proves you watched a tutorial. A “React weather app using OpenWeather API” proves you can follow documentation. These are fine exercises. They are not differentiators.

A hiring manager reviewing 50 resumes has seen 40 weather apps and 35 todo apps. The bar for “interesting” is not high, but you do have to clear it.

The second mistake: the project exists only on GitHub with 2 commits and no README. “I built this” with no evidence of it working or being used signals that you started but did not finish - which is actually worse than not listing it.

What Makes a Side Project Stand Out

It Solves a Real Problem

Real means: you or someone else actually uses it. Not “I built a budgeting app” but “I built a tool that parses HDFC/ICICI bank statements (because their PDF format is terrible) and categorizes expenses - I use it myself and a few hundred other people do too.”

The problem can be small. It does not need to be a startup idea. It just needs to be genuine.

It Is Actually Live

A URL you can click. Something deployed. The difference between a project on your machine and one on the internet is the difference between “I was going to” and “I did.”

Free deployment options (Vercel, Fly.io, Railway, Render) mean there is no cost barrier. A live URL on your resume says more than all the “designed and implemented” language you can write.

It Has Real Usage Signals

Even 50 daily active users is meaningful. 200 GitHub stars on an open source project is meaningful. A Hacker News post that got traction is meaningful. “150+ users” or “featured in [newsletter]” gives hiring managers something concrete to attach to your claim.

The README Is Good

This is underrated. A well-written README - clear problem statement, architecture decisions explained, known limitations acknowledged, screenshots or a demo link - shows communication skills, not just coding skills. Hiring managers often look at your README more than your code.

A Framework for Picking What to Build

Ask these three questions:

  1. Is there a problem you encounter regularly that has a bad or missing solution?
  2. Is there a domain you care about where you could build something useful?
  3. Is there an existing tool you use that you could build a specific feature for or improve on?

Answer yes to any one of these and you have a project worth building. The intersection of “I care about this” and “someone else would use this” is where good side projects live.

Scope to Finish, Not to Impress

The most common failure mode is starting with too large a scope. You want to build “a social platform for indie hackers” and you have 2 hours a week. That project will never be finished.

Pick something you can ship in 4-6 weekends. The constraint forces good prioritization. MVP means literally minimum - what is the single thing this needs to do to be useful? Build that. Ship it. Iterate if people use it.

A finished small project is worth more than an impressive unfinished one every time.

The Stack Question

Use what you know. This is not the time to learn three new technologies simultaneously. If you know TypeScript and Postgres, build it with TypeScript and Postgres.

The exception: if you are explicitly trying to break into a new area (say, moving from frontend to backend), then yes, a project in that area makes sense. But still minimize the number of new things you are learning at once.

What To Write in the Resume Entry

Format that works:

[Project Name] - [One sentence describing what it does and who uses it] | [Tech stack] | [Live link + GitHub link]

  • [Specific interesting technical challenge you solved]
  • [Usage or impact metric if you have one]

Example:

StatementParser - Parses HDFC/ICICI bank PDFs into structured spending data. Used by 300+ people. | TypeScript, Node, Postgres | [live link] [github]

  • Built a regex-based extractor for 6 different bank statement formats with 99.2% parse accuracy
  • Automated category detection using keyword matching, reducing manual labeling to under 5% of transactions

That is a project entry that prompts a question.

Bottom Line

One finished, used, live project is worth more to your candidacy than ten tutorial clones. The bar is lower than it feels: a real problem, a real deployment, a real README. Do not aim for impressive. Aim for finished. The finished constraint is what makes a project genuinely impressive.