Chapter 2 of 8 · 7 checks · 4 min
Projects
Projects are the evidence behind everything else on the site. Show three to five strong ones, each with the problem, your role, the stack and the outcome.
Show three to five of your strongest projects, not everythingMust
Why it matters and how to check
A portfolio is a selection, not an archive. Three to five strong projects make a clearer impression than fifteen small ones, and visitors rarely look past the first few anyway.
Choose projects that match the work you want next. If you want backend roles, lead with an API or data-heavy project, not a landing page. Put the strongest one first. To check, ask yourself whether each project shows something the others do not; if two are very similar, keep the better one.
Do
- Order projects with the strongest and most relevant first
- Pick projects that match the roles or clients you want
Avoid
- Grids of a dozen small exercises with no explanation
Give every project its problem, your role, the stack and the outcomeMust
Why it matters and how to check
Each project needs four short parts. Problem: what needed solving and for whom. Role: what you did, especially in a team. Stack: the main technologies. Outcome: what happened, such as users, a result, a grade, a client decision or what you learned.
Two or three sentences per part is plenty. For example: "Problem: our university society tracked event sign-ups in spreadsheets. Role: I built the backend and deployed it. Stack: Django, PostgreSQL, Render. Outcome: used for every event this year." Check each project card against the four parts and fill any gap.
Do
- Write problem, role, stack and outcome for each project
- Say exactly which part you built in team projects
Avoid
- Project cards with only a title, a screenshot and a list of logos
Link a working live demo for every project that can have oneMust
Why it matters and how to check
A live demo lets a visitor try your work in seconds, which is more convincing than any description. Host web apps on a free or low-cost platform, and for mobile apps link a store listing, an installable build or a short screen recording.
Demos break quietly when free tiers sleep, databases expire or API keys change. Open every demo link in a private window before you share the site and after any change. If a demo needs sign-in, provide a demo account or a guest mode, and say so on the card.
Do
- Test every demo link in a private window
- Offer a demo account if sign-in is required
Avoid
- Dead demo links or apps that need a reviewer to create an account
Link the source code, with a README that explains the projectMust
Why it matters and how to check
Developers and technical hiring managers often open the code. Link each project's repository and make sure the README covers what it is, how to run it, the stack and a screenshot. A repository without a README looks unfinished even if the code is good.
If the code is private because it belongs to an employer or client, say so on the card and describe the work instead. Check each link opens a public repository, not a 404, and that no secrets or API keys are committed.
Do
- Link public repositories with clear READMEs
- Explain when code is private and why
Avoid
- Links to private repositories that show a 404 to visitors
- Committed API keys or passwords
Add a clear screenshot or short video for each projectShould
Why it matters and how to check
A good image helps visitors decide which project to open. Use a real screenshot of the working product at a readable size, or a short looping video or GIF of the main flow. Mockups with fake data are fine as long as the app really works.
Compress images so they do not slow the page, and give each one alt text that says what it shows. Check the page on a phone: if screenshots are unreadable at that size, crop to the most important part.
Do
- Show the real working product
- Compress images and add alt text
Avoid
- Huge uncompressed screenshots or decorative stock images
Write a longer case study for your best projectShould
Why it matters and how to check
For your strongest project, go further with a short case study page: the problem, constraints, key decisions and alternatives you rejected, what you built, results and what you would change. This shows judgment, which is what experienced reviewers look for.
Keep it to a five-minute read with a diagram or two. Check that the case study can be understood without opening the code, and that it links to the code and demo for anyone who wants more.
Do
- Explain at least one decision and the alternative you rejected
- Include one thing you would do differently
Avoid
- Case studies that only list features
Remove unmodified tutorial clones or label them honestlyShould
Why it matters and how to check
Many portfolios include to-do apps, weather apps and course projects copied step by step from a tutorial. Experienced reviewers recognise them quickly, and they suggest you have not built anything on your own.
Either extend them with your own features and decisions, and say what you added, or remove them. If you keep one as a learning milestone, label it as a course project. Check each project by asking: what did I decide that the tutorial did not tell me to do?
Do
- Say what you added beyond the tutorial
Avoid
- Presenting a step-by-step course project as original work