Session 12: Portfolio & Final Presentation

A portfolio answers one question: can this person do the work? Not whether they have studied it, not which tools they can name. The strongest evidence is a live, working thing — a URL someone can visit on their phone right now — because it cannot be argued with and it demonstrates the whole chain: planning, building, testing, deploying.

So quality over quantity, and live over described. Three finished, published projects with real content beat ten screenshots of unfinished work, and one genuinely good project beats three mediocre ones. A visitor forms an impression in about a minute, and a portfolio of half-finished things tells them you do not finish things, however skilled the fragments are.

Then the projects should be real. A site for an actual business, organisation or person — even one you did at low cost — carries far more weight than an invented demo, because it involved a real brief, real constraints and a real person to answer to. If you have no client work, build something for a real local business in exchange for permission to show it, which is also how the first paid work usually arrives.

The write-up is what separates a portfolio from a gallery, and it is the part almost everyone omits. Anyone can copy a layout; explaining why you made the choices you made is what demonstrates understanding. For each project, write what the problem was, what you decided, and why — including the alternatives you rejected.

The structure that works: the brief in one or two sentences. The decisions — why Flexbox here and Grid there, why you validated on blur rather than on keystroke, why you used a system font stack rather than a web font. The trade-offs, honestly stated, including what you would do differently. The result, with anything measurable: a Lighthouse score, a load time, a real user's reaction.

Stating trade-offs is the part that reads as professional. 'I used a system font stack because a web font would add a blocking request on the slow connections most visitors here have, at the cost of a less distinctive look' shows judgement. Claiming everything was optimal shows inexperience, because every technical decision trades something away and pretending otherwise is not credible.

Present in the order the listener thinks, not the order you built it. Start with the problem and who has it. Then show the thing working — live, on a phone, immediately, because a demonstration persuades where a description does not. Then one or two decisions and why you made them. Then what you would do next. Leave the technical detail for the questions.

The mistake is presenting the technology to people who care about the outcome. A client does not need to hear about Flexbox; they need to see that the site works on their phone and loads quickly. Lead with the outcome and keep the technique in reserve, ready for whoever asks — because someone technical usually does, and that is your chance to show depth.

Then prepare for the questions that always come: why did you choose that approach, what would you change, how long did it take, and what would it cost to add a feature. The last two are the ones people are least prepared for and the ones that decide whether you get paid work, so have honest answers ready rather than improvising.

Critique on technical work is unusually useful, because unlike subjective design feedback it is often checkable: the site does or does not work at 320px, the contrast does or does not meet 4.5:1, the console is or is not clean. Verify rather than argue — open the tools and look, which takes ten seconds and settles it.

The discipline is the same as anywhere: record it, do not defend it in the moment. The instinct to explain what you meant costs you exactly the information you came for. Afterwards, sort the notes into three: factually wrong and must be fixed, preference worth considering, and the critic's own context — they build large applications and you built a small static site, which makes some of their advice inapplicable.

When you give critique, be specific and be about the work. 'The navigation is not reachable by keyboard — tab stops at the logo' is useful and actionable. 'It needs work' helps nobody. And name what works, because knowing what to keep matters as much as knowing what to change, and feedback that is only negative produces someone who rebuilds rather than improves.

After this course you can plan, build, test and publish a working website, and explain the decisions you made. That is genuinely employable and genuinely useful, and it is more than most people who say they 'know some HTML' can demonstrate — the difference being a live URL and an articulated reasoning behind it.

The natural next steps branch by interest. A framework such as React is the usual next move and is what most job listings ask for, but it is far more valuable on top of solid fundamentals than instead of them — a framework is a way of organising the same HTML, CSS and JavaScript you now know. Backend work — a server, a database, an API — is what turns a static site into an application, and it is a substantial and separate discipline. Specialism in accessibility or performance is a smaller field with real demand and less competition.

Whichever route, two habits determine how far you get. Keep building and publishing, because the portfolio is what opens doors and it only grows by shipping. And read other people's code, which is the fastest way to learn how experienced developers solve problems you have not met yet — every open-source project is a free textbook, and most people never open one.