Build a web developer
portfolio from your resume.

The reviewer is standing inside your work sample

When a nurse manager reads a nursing portfolio, the page is a window onto the work. When an engineer reads your developer portfolio, the page is the work. They are watching it load, resize it, tab through it, and open the console, often without meaning to. A slow first paint, a layout that jumps on a phone, or a broken link is not a small blemish on the content, it is a live demonstration of how you ship. Build the site as if it were the interview task, because to the reviewer it is.

Lead with things that run, not things that describe

A deployed URL beats a paragraph every time. Three to five projects a reviewer can click, use, and break tell them more in thirty seconds than a page of prose about your responsibilities. Put the live link and the repository link together on each card so the reviewer can run it and read it in one motion. If a project no longer runs, take it down. A dead demo does more damage than a shorter list.

Name the stack in the reviewer's language

Hiring for web roles is often stack-matching. The reviewer has React or Vue or Next.js in mind and is scanning for it. State the stack plainly on each project: the language, the framework, the styling, any headless CMS, and where it is hosted. Do the same on the resume the same paste produces, in the exact terms a tracking system indexes, so JavaScript, TypeScript, Tailwind, and Node.js are present as written rather than implied.

Put a number on performance

Speed is a claim until you measure it. A Lighthouse score, a Largest Contentful Paint figure, or a before and after page-speed win turns "fast" into evidence. "Reduced LCP from 4.1s to 1.3s by lazy-loading images, splitting the bundle, and serving modern formats" reads as an engineer who profiles and improves, not one who guesses. Keep the figures current, since a screenshot from last year may not match what the reviewer sees when they run the tool themselves.

Accessibility is a signal, not a checkbox

WCAG work separates a developer who has shipped for real users from one who has only shipped happy paths. Semantic HTML, keyboard navigation, visible focus states, sufficient colour contrast, and honest alt text all read as maturity. Name the a11y work you did on each project, and make sure your own portfolio passes the same bar, because a reviewer who tabs through your site and hits a keyboard trap will notice.

Handle client work and secrets with care

You cannot show work you do not have permission to publish, and you must not expose a client login or an internal URL. Describe your contribution in words, name the stack and the outcome, and link a public rebuild or a side project that proves the same skill. Keep every credential out of the code you link. No API keys, tokens, or connection strings in a public snippet or repo. Use an environment variable and a placeholder, and say so in the README. A leaked secret in a portfolio repo is a hiring red flag on its own.

Frame freelance and employed work honestly

Label each project as personal, freelance, or built on the job, and be precise about your role. Claiming solo credit for a team build is the kind of thing that unravels in a technical interview. A reviewer reads clear scope as a good sign, so say what you owned, what the team owned, and what you shipped. Honesty about contribution costs nothing and buys trust that a polished screenshot cannot.

Keep it current, because code rots in public

A developer portfolio ages faster than most. Links break, dependencies go stale, and a framework you led with two years ago may now read as dated. Revisit the site before each job search: confirm every demo still runs, refresh the performance numbers, and swap in your newest project so the grid shows where you are now, not where you were. A portfolio that clearly reflects current work reads as a developer still shipping, which is the signal you want a reviewer to leave with.