Be honest. How many to-do apps have you built?
I'm not judging. I've built one, and so has nearly everyone reading this. The problem is that a recruiter looking through a stack of student portfolios sees the same to-do app, weather app, and calculator dozens of times. They blur together, and none of them tell the reader anything about you.
The good news: you don't need a genius idea to stand out. You need a real problem, a finished result, and a clear story. This post covers what makes a side project impressive, a bunch of ideas you can start this week, and how to present them so people actually remember you.
1. Why Tutorial Clones Don't Land
Clones aren't bad for learning. I wrote a whole post about using them properly. But as portfolio pieces they have three weaknesses:
- Everyone has them, so they don't differentiate you
- You didn't make the important decisions, since the tutorial did
- They don't solve a real problem, so there's nothing to talk about in an interview
A recruiter's real question isn't "can this person follow a video?" It's "can this person figure out something new and finish it?" Your projects need to answer that.
2. Think of It Like a Science Fair
Picture a school science fair. Some kids bring the classic baking-soda volcano. It erupts, everyone claps, and nobody remembers it.
Then one kid presents a project on why the water in their own neighborhood tastes different from the next street over. They asked a real question, tested it, found something, and explained what they'd do next. That's the one the judges talk about afterward.
Notice what made the second project win. It wasn't fancy equipment. It was a real question, a clear method, and honest results. Your side projects should work the same way.
3. What Makes a Project Impressive
Aim for as many of these as you can:
- It solves a real problem. Ideally one you or people around you actually have.
- It has real users. Even five classmates using it beats zero. It proves someone wanted it.
- It's finished and live. A deployed link beats a screenshot every time.
- It shows decisions. Why this database? Why this approach? What trade-offs did you make?
- It's well documented. A clear README, screenshots, and a short "what I'd improve" section.
- It has something of your own. A twist, a feature, or an angle that isn't in a tutorial.
You don't need all six. But a project with real users, a live link, and a solid README will beat a technically fancier one with none of that.
4. Project Ideas That Work
Here's a list grouped by what each one shows. Adapt them to your own life so they're not copies.
Solve a problem near you
Problems you can see up close are the best source of ideas, and you can find real users easily.
- A college timetable and attendance tracker that reminds you of classes and calculates how many you can still miss
- A club event registration and attendance system with a simple dashboard for organizers
- A shared notes or past-papers site for your department
- A hostel or canteen menu app that shows what's for dinner
- A certificate generator that takes a list of names and produces personalized PDFs for an event (any club organizer would love this)
Work with data
- An expense tracker with charts that shows where your money goes each month
- A dashboard built on a free public API, like air quality, weather, or transport data for your city
- A small data analysis project about something local, with your findings written up as a short blog post
Automate something boring
- A script that renames, sorts, or backs up files the way you actually want
- A Telegram or Discord bot for your club or study group, like a reminder bot or a quiz bot
- A tool that pulls information you check every day into one place, such as deadlines, results, and announcements. If you scrape anything, respect the site's rules and terms.
Build a useful developer tool
- A command-line tool that scaffolds your favorite project setup
- A browser extension that fixes a small annoyance, like blocking distractions while you study
- A small library or package that other people can install and use
Use AI as a real feature
AI projects are trendy, so they can help you stand out, but only if they're more than a chat box glued to an API. A few sturdier ideas:
- A study helper that turns your lecture notes into quiz questions and flashcards
- A job application tracker that summarizes postings and highlights skills to mention
If you do this, show your work. Explain how you handle wrong answers, cost limits, and user privacy. That's what separates a thoughtful project from a demo.
Go full stack
- A booking or appointment system for a local salon, clinic, or coaching center
- A simple inventory or order manager for a small shop
- An app with login, a database, and deployment, even a small one, since it proves you can connect the whole chain
Contribute to open source
Fix a bug, improve the docs, or add a small feature to a real project. A merged pull request tells a recruiter you can read someone else's code and work with a team.
Do real work for a real person
A project you built for an actual client or organization, even a small one, is worth more than most personal experiments. My post on landing your first freelance client covers how to find one.
5. How to Choose Which One to Build
Run your ideas through these four questions:
- Do I or someone I know have this problem? If yes, motivation and feedback come free.
- Can I get a working version live in 4 to 6 weeks? If not, shrink it.
- Can I find five real people to try it? Classmates, club members, or family all count.
- Does it show a skill I want to be hired for? Databases, APIs, auth, deployment, testing, whatever your target roles ask for.
Pick the one that gets the most yeses. Don't wait for a perfect idea, since a good idea you finish beats a great one you never start.
6. Ship a Small Version First
The biggest project killer is scope. You imagine the full app with twenty features, build for three weeks, and abandon it.
Instead, define the smallest useful version: the single feature that makes it worth using. Build only that, put it online, and show it to real people. Then improve it based on what they actually say. Use GitHub issues to keep a short list of next steps, which also shows recruiters you plan and prioritize.
7. Present It Like a Pro
A brilliant project with a weak presentation gets ignored. Give every project:
- A clear README with what it is, the problem, screenshots, how to run it, and what you'd improve. My GitHub profile post goes deeper on this.
- A live demo link. Recruiters rarely clone and run your code.
- A short demo GIF or video that shows it working in thirty seconds
- A simple architecture diagram made in a tool like Excalidraw, showing how the pieces connect
- A "decisions and trade-offs" section explaining why you chose what you chose
- Real numbers if you have them, like "used by 30 students in my department." Only claim what's true, and never inflate the numbers.
Then write about it. A short blog post on how you built it, what went wrong, and what you learned doubles as content and as proof that you can communicate.
8. Using AI While You Build
Using AI tools to build is normal, and employers expect it. Just make sure you can explain every part of your project. If someone asks why a function works the way it does and you can't answer, the project hurts you more than it helps.
Be upfront in your README about where AI helped and what you reviewed or rewrote yourself. That reads as mature, not lazy.
9. Turn It Into an Interview Story
A project is only half the value. The other half is how you talk about it. Prepare a short version:
- The problem: what were you trying to solve, and for whom?
- The choices: what options did you consider, and why did you pick these?
- The challenge: what went wrong, and how did you fix it?
- The result: who used it, and what happened?
- The next step: what would you improve with more time?
That five-part story answers most interview questions about your projects before they're asked. My post on your first coding interview shows how to weave it in.
10. Common Mistakes
- Copying a tutorial and calling it yours. Add something original or don't list it.
- Never deploying. "Works on my machine" doesn't count.
- Going too big. Ambition is great, but unfinished projects tell a story too.
- Hoarding tech. Using seven frameworks doesn't impress anyone. Using two well does.
- Skipping the README. It's the first thing people read and often the only thing.
- Leaking secrets. Never commit API keys or passwords, as I covered in my Git post.
- Exaggerating. Fake numbers and inflated claims fall apart in the first interview question.
Your 30-Day Plan
Week 1: Pick one idea using the four questions. Write the smallest useful version in one sentence, and sketch the screens.
Week 2: Build the core feature. Ugly is fine.
Week 3: Deploy it, invite five real users, and collect their feedback.
Week 4: Improve based on feedback, write the README, record a short demo, and post about it.
One finished, used, documented project in a month puts you ahead of most of your batch.
Let's Connect
I'm Prayush Adhikari, currently grinding through computer engineering, leading an IT club, and building my own company on the side. I write about Linux, productivity, and the honest side of being a developer.
Tell me in the comments which idea you're picking, or share a problem you'd like to solve. I'll happily help you shape it.
- LinkedIn: linkedin.com/in/adhikareeprayush
- GitHub: github.com/adhikareeprayush
- Portfolio: prayushadhikari.com.np
What should I write next: how to build a career network when you don't know anyone in tech, or how to make your first open-source contribution?
Top comments (1)
The smallest useful version advice is the most useful part here. One tip I would add: write that one sentence version down, then also write a short not now list for every feature you cut. That makes it easier to stay small in week 2, because you are not deciding from scratch each time a new idea appears. It also gives you ready material for the what I would improve section in the README, since you already know what you left out on purpose.