Your Portfolio: What Do You Have to Show at 18?

⚠️ Version note: the platforms named here (GitHub Pages, Notion, Google Sites, Behance) change their interfaces regularly. The steps describe what to look for. Last checked: 24 July 2026.

A CV claims. A portfolio proves.

A CV says "I built a data pipeline." Anyone can type that sentence. A portfolio says "here is the data pipeline, here is what it does, here is the code" — and the difference between those two is the difference between being believed and being tested.

At 18 you're competing partly against people with more experience. A portfolio is how you win anyway, because it moves the conversation from what you claim you can do to what you have already done. The second is much harder to argue with, and much rarer than it should be — most people never make one.

Here is the thing people get wrong and it's worth saying up front: you already have the material. A course project. A thing you built to solve your own problem. An analysis you did for a society. The portfolio is not "go and produce impressive work" — it's "show the work you already did, properly."

What you'll have at the end

• A published, linkable page — a URL you can put on a CV and in an email
• Three pieces, each with a short write-up that explains itself
• The write-up structure that turns "a thing I made" into evidence of how you think

Before building anything, inventory. Most people undercount badly.

List everything you've made that has an output:

• Course projects with a result — the essay that got a high mark, the coding assignment, the analysis
• Anything you built for yourself — a script, a spreadsheet system, a small tool, a website
• Work for a club, society, team, family business — a budget, a poster series, an event you organised
• Things you made while learning — the lesson outputs from this very platform count
• Writing, if it's relevant — a blog post, a well-argued piece, documentation

The bar is not "impressive". The bar is "real and finished". A small thing you actually completed and can explain beats an ambitious thing that's half-done and unexplainable.

Pick your three strongest. Fewer, better. A portfolio of three well-documented pieces beats ten thin ones — and a reviewer will only look at two or three anyway.

✅ Check: three real, finished pieces chosen, each with something you can point at.

This is the actual skill, and the reason most portfolios fail. People post the thing — a repo, a screenshot, a file — with no explanation, and a reviewer has no idea what they're looking at or why it's good.

The artefact shows what you made. The write-up shows how you think. The second is what's being hired.

Five short parts, per piece:

1. WHAT IT IS          one sentence. what it does, for whom.
2. THE PROBLEM         why it needed to exist. what was wrong before.
3. WHAT YOU DID        your specific decisions — not a feature list,
                       the choices and the reasons
4. THE RESULT          what happened. a number, a before/after, a
                       working thing someone can click
5. WHAT YOU'D DO NEXT  one honest limitation or next step

Part 5 is the one that separates a real portfolio from a brag. Naming a limitation signals judgement — that you can see your own work clearly — and reviewers read it as maturity, not weakness. Someone who thinks their project is perfect is someone who can't evaluate work, including yours.

An example, filled in:

Budget tracker for our society — a spreadsheet system that tracks a student society's spending against its termly grant.

The problem: the treasurer was reconciling receipts by hand every week and we twice nearly overspent a category without noticing.

What I did: built a categorised ledger with automatic per-category totals and a conditional- formatting rule that turns a category red at 90% of budget. Chose to keep it in Sheets rather than an app so the next treasurer could actually maintain it.

The result: reconciliation went from ~an hour a week to about five minutes; we finished the term under budget in every category.

Next: it doesn't handle multi-currency, which matters for the trip we're planning — I'd add a rate column next.

Notice what that write-up reveals that the spreadsheet alone wouldn't: a choice made for the next person (judgement), a real before/after (impact), and an honest edge (self-awareness). That's the hire signal, and none of it is visible in the artefact itself.

✅ Check: each of your three pieces has all five parts written, and part 3 contains a decision with a reason, not a list of features.

The best platform is the one you'll ship today. A live simple page beats a perfect page you never publish.

For technical work, GitHub is doing double duty: the code lives there and the README of each repo becomes the write-up. A good README is the portfolio for a developer — which is why the next step is about exactly that.

Don't spend three weeks building a custom site from scratch as your portfolio unless web-building is the skill you're showing. The meta-lesson of a portfolio is that you finish things; an unfinished portfolio-site actively argues the opposite.

✅ Check: a platform chosen because you can publish on it today.

If any piece is code, its README carries it. Reviewers look at the README first and often only — they will not read your source to figure out what it does.

A README that works:

# Project Name
One sentence: what it does and who it's for.

## The problem
Two or three sentences. Why this exists.

## What it does
- the key things, as outcomes not features

## How it works
A short paragraph on the approach and one interesting decision.
A screenshot or a GIF if there's anything visual — this matters more
than you'd think; most reviewers won't run your code.

## Running it
Exact steps. Assume nothing.

## What I'd add next
One honest limitation.

The screenshot or GIF is disproportionately important. A reviewer with forty tabs open will not clone and run your project — but they'll look at an image for one second and form an impression. A repo with a screenshot gets looked at; one without usually doesn't.

Commit history counts too. A messy but honest history of real commits reads better than a single "initial commit" dump — it shows the work happening. (This is TC-06.)

✅ Check: any code piece has a README a stranger could understand without opening the source, with a visual.

A portfolio nobody can reach isn't one.

• One clean URL you can paste into a CV, a LinkedIn bio, an email signature.
• Put it on your CV (CR-01) as a link near your name, and in your LinkedIn (CR-02).
• Check it works logged out / incognito. The number one portfolio failure: a Notion or Drive link that's private, so the reviewer hits a permission wall and moves on. Open it in a private window and confirm it loads.
• Lead with the strongest piece. Reviewers rarely reach the third. Order for a reader who stops early.

✅ Check: the URL loads for a logged-out stranger and opens on your best work.

Six common mistakes

1. Posting artefacts with no write-up. The write-up is the portfolio. The thing alone is a mystery.
2. A private link. The most common and most fatal — the reviewer hits a wall and leaves.
3. Ten thin pieces instead of three strong ones. Nobody reaches ten, and volume dilutes your best.
4. No screenshot on a code project. It won't get run, so it won't get seen.
5. Hiding limitations. They read as judgement. Concealing them reads as not having any — which is worse.
6. Building a custom site instead of shipping. An unfinished portfolio argues against you.

Exercise (60 min, verifiable output)

1. Inventory everything you've made with an output. Choose your three strongest, finished pieces.
2. Write the five-part write-up for each. Make sure part 3 has a decision-with-a-reason and part 5 has an honest limitation.
3. Pick a platform you can publish on today.
4. For any code piece, write the README with a screenshot or GIF.
5. Publish. Get one clean URL.
6. Open it in an incognito window and confirm every piece loads for a stranger.
7. Order it so the strongest piece is first.
8. Add the link to your CV.

✅ Finish check: a live URL, loading logged-out, with three pieces each carrying a five-part write-up, strongest first, and any code piece showing a visual in its README.

Summary card

• A CV claims; a portfolio proves. It moves the conversation from what you say to what you've done.
• You already have the material. The task is to show existing work properly, not produce impressive new work.
• Three strong pieces beat ten thin ones. A reviewer reaches two or three at most.
• The write-up is the portfolio. Artefact = what you made; write-up = how you think, which is what gets hired.
• Five parts: what it is · the problem · what you did (decisions, not features) · the result · what you'd do next.
• Naming a limitation signals judgement. Hiding it signals you can't see your own work.
• For code, the README is the portfolio — and a screenshot gets it looked at.
• Publish on whatever you can finish today. A live simple page beats a perfect unpublished one.
• Test the link logged out. A private link is the most common fatal failure.

Next lesson: CR-04 — Interviews: the STAR Method (L2) Related: CR-01 The CV That Gets Read · CR-02 LinkedIn · TC-06 Git and GitHub · TC-13 Building a Project End to End Path: Job Ready — 3/7