Shipped and reachable beats impressive-sounding

The only test that matters

A portfolio is not a gallery and it is not a resume in HTML. It is evidence that you can take something from idea to working thing that other people can use. Most student portfolios fail that test not because the projects are bad but because the evidence is unreachable — a repo with no README, a demo that 404s, a screenshot of something nobody can run.

A live URL beats a repository. A reviewer who can click and immediately see the thing working has already given you more credit than a reviewer who has to clone, install dependencies, and guess at environment variables — which they will not do. Deploy it. Free static hosting and free tiers cover almost every student project, and a deployed toy outranks an undeployed system.

What a reviewer checks in 60 seconds

Notice that none of those seconds are spent on your design taste or your framework choice. They are spent establishing that the thing is real and that you can explain it.

Three strong projects, not ten weak ones

Ten shallow projects read as ten abandoned weekends. Three projects with depth read as someone who follows through. Depth means the boring parts are there: error handling, a test or two, a deploy, a README, commits spread over more than one day, and some evidence you dealt with a problem you did not anticipate at the start.

• Cut anything from a tutorial unless you extended it substantially, and say what you extended.
• Cut anything you cannot explain in an interview — every project on the page is fair game for a deep question.
• Cut anything with no users and no result, unless the technical difficulty itself is the point.
• Keep the one that is unusual. One weird, specific project is worth more attention than three competent CRUD apps.
• Keep the one with a number attached. Accuracy, latency, throughput, time saved, users — any honest metric anchors the whole page.

The README is the pitch

For most projects the README is the only documentation anyone will read, and for a hiring reviewer it is the case study. Setup instructions matter, but they belong below the explanation, not above it.

# Project name One sentence: what it does and who it is for. [Live demo](url) · 30-second screenshot or GIF ## Why The problem, in two or three sentences. ## How it works The architecture in a short paragraph, plus the stack. ## What was hard The real constraint, and what you decided. ## Results Numbers if you have them. Scope if you do not. ## Run it locally The commands, last.

A screenshot or a short GIF near the top does an enormous amount of work, because it lets someone understand the project without running anything. It is the cheapest credibility you can buy.

How to write a project case study

A case study is not a feature list. It is a decision narrative — you had a problem, you had constraints, you chose something, and something happened. The structure that reads well:

1. Context. What the problem was and why it was worth solving. One paragraph.
2. Constraints. Time, cost, data, hardware, skill. Constraints are what make the decisions interesting.
3. What you built. The architecture in plain language before any diagram, plus the stack and why.
4. The hard part. The one thing that did not work at first. This is the paragraph that separates a builder from a follower of tutorials.
5. The result. A number, or honest scope. "78% directional accuracy over 50+ sources per day" is a result; "successfully implemented" is not.
6. What you would change. Short, specific, unromantic. It signals you evaluated your own work.

Write the case study while the project is fresh. Reconstructing why you made a decision six months later produces vague prose, and vague prose is what makes a portfolio forgettable.

The portfolio site itself

• One page is enough. Who you are, three projects with links, contact. Depth lives on the project pages.
• Every project links to something clickable — live demo first, repository second, paper or write-up third.
• Fast and readable on a phone. A meaningful share of reviews happen on a phone between meetings.
• Real text, not images of text. Recruiters and search engines both read the page.
• Your email visible without a form. Contact forms lose messages and add friction to the exact action you want.
• Dates on things. A portfolio with no dates reads as stale by default.

The version of this that is easy to skip

Building the portfolio is the fun part; keeping it reachable is the part that decays. Deploys expire, free tiers sleep, links rot. Check every link on your portfolio the week before you start applying, and again mid-season. A dead demo link on an otherwise strong page is worse than no link, because it converts a positive signal into evidence you do not maintain your work.

The application side of this — which roles, which deadlines, what you sent and when — is what Apply OS handles, and the document that points at the portfolio is covered in the ATS resume guide.

Tools referenced in this guide

• Apply OS — free deadline radar and application pipeline, browser-only.
• Resume rebuild — the ATS-safe document your portfolio links from.
• ATS resume guide — how projects should be written on the resume itself.