Start with two or three small but complete projects that solve a real problem, each with a clear README, screenshots and a live link or easy run steps. Put them on a simple one-page site or a tidy GitHub profile. Depth and finish matter far more than the number of projects or a fancy design.
What people tell me
Everyone says I need a portfolio to get an internship or junior job, but I only have class assignments and a few half-finished tutorial projects. I do not know what counts as a good project, how many I need, whether I need a personal website or whether GitHub is enough. When I look at other portfolios they look so polished that I do not know where to begin.
A composite of the messages behind this question, with personal details left out.
Key takeaways
- Two or three finished projects beat ten half-built ones. Finished means deployed or runnable, documented and explained.
- Pick projects with a real user or a real problem, not another generic to-do app.
- The README is part of the project. Reviewers often read it before the code.
- A tidy GitHub profile is enough to start. A personal site is a bonus, not a requirement.
- Show your thinking: what you chose, what broke and what you would do next.
What a portfolio is for
A portfolio answers one question for a reviewer who has about two minutes: can this person build something that works and explain it? It is not an art gallery. A plain page with three strong, finished projects beats a beautiful site with ten links to broken demos.
What makes a project portfolio-worthy
| Weak project | Strong project |
|---|---|
| Tutorial clone with the same name and features | Started from a tutorial but extended with your own features |
| Only runs on your laptop | Deployed, or clear run steps that work on the first try |
| No README | README with problem, features, stack, screenshots, how to run |
| Everything in one giant commit | Commit history showing steady progress |
| "Built a website" | A specific problem for a specific user |
| No tests, no error handling | A few tests and sensible handling of bad input |
How many projects, and which kinds
Aim for three, built in this order:
- A small, complete tool (1 to 2 weeks). A command line app, a browser extension, a script that automates something you do by hand. Proves you can finish.
- A full application (3 to 5 weeks). Frontend plus backend plus database, with login or some real data. Proves you can connect pieces. The Full stack development roadmap shows the parts.
- A project with a real user or real data (3 to 6 weeks). For a society, a family business, a teacher, or built on a public dataset. Proves you can handle real requirements.
If you are aiming at data, AI or mobile, adjust the second and third project to that area, but keep the same idea: one small, one full, one real.
Ideas that are better than a to-do app
- A booking page for a local tutor or barber, with an admin view.
- A tracker for your university's timetable or assignment deadlines.
- A dashboard that pulls public data (weather, cricket scores, exchange rates) and shows trends.
- A tool that cleans or summarises spreadsheets someone you know works with every week.
- A small API with authentication and tests, documented so someone else can use it.
The README template
Every project should have a README with these sections:
- What it is: one or two sentences.
- Why: the problem it solves and for whom.
- Features: three to six bullets.
- Stack: what you used and one line on why.
- Screenshots or a short demo GIF.
- How to run it: exact steps.
- What I would do next: two or three honest improvements.
That last section is gold in interviews. It shows you can judge your own work.
Where to host it
- GitHub first. Pin your three best repositories and write a short profile README. The GitHub profile README guide shows how.
- A simple site, optional. A one-page site with your name, a two-line intro, the three projects and contact links. GitHub Pages hosts it free.
- Live demos. Use free tiers where you can. If a demo may sleep or break, add a short video instead.
A 6-week portfolio plan
| Week | Focus | Output |
|---|---|---|
| 1 | Small tool | Finished, README written, pushed |
| 2 to 4 | Full application | Core features working, deployed |
| 5 | Polish | Tests, error handling, screenshots, README for both projects |
| 6 | Profile | GitHub pinned repos, profile README, optional one-page site, resume updated |
Start the third, real-user project after this, and keep applying while you build it.
Turning a tutorial project into your own
Most beginners have tutorial projects. You do not have to throw them away. Make them yours:
- Change the domain. A tutorial blog becomes a recipe site for your family, or a notes app for your course.
- Add two features the tutorial did not cover, such as search, filters, user roles or an export button.
- Replace fake data with real data from a public API or a spreadsheet someone actually uses.
- Write tests for the logic you added.
- Rewrite the README in your own words, and say honestly which tutorial you started from.
Honesty matters here. Reviewers recognise popular tutorial projects instantly. Saying "started from X, then added Y and Z" earns respect; pretending you designed it from scratch does not.
Common mistakes
- Spending two weeks on the design of the portfolio site before any project exists.
- Listing every course exercise as a project.
- Broken demo links. Check them before every round of applications.
- Only frontend clones of famous sites with no logic of your own.
- Waiting until the portfolio is perfect before applying.
How reviewers actually look at it
In my experience, a reviewer opens your top project, reads the README, looks at one or two files and checks if the demo works. They are asking: is the code organised, are names sensible, does it handle errors, did this person make decisions? Make those two minutes easy for them.
If you are still stuck
If you keep starting projects and never finishing them, read When should I stop taking courses and start building things?. For more ideas worth studying, see GitHub repositories worth more than a star. To get feedback on your plan from someone who has seen many portfolios, join Sefism, where learning is free and you get credits on joining, then book a 1:1 session.
Was this answer helpful?
Read next
Your situation is not quite this one?
Members get written answers to their own questions, a roadmap built for them and feedback on their projects. Early access is open: sign up and your account is active shortly after. Prefer to talk? A free call works too.