How to Build a Web Developer Portfolio That Gets You Job Offers

Code is invisible on a CV. “Built responsive interfaces with React and TypeScript” describes roughly four million people. An engineering manager cannot judge how you structure state, name things, handle errors, or think about performance from a bullet point — and they will not open a PDF hoping to find out.

A live portfolio flips the burden of proof. Instead of claiming you can build, you hand over a working URL, the repo behind it, and one paragraph explaining the hardest decision you made. That is the entire trick. Everything below is just execution.

Having reviewed candidates from the other side of the table: the portfolios that got a yes were rarely the prettiest. They were the ones where I could click something within five seconds.

You do not need a custom-designed site with scroll animations. You need five sections in this order.

1. Hero — role + stack + one sentence

No “Hi, I’m John 👋” on its own. Lead with what you are and what you build with:

Frontend Engineer — React, TypeScript, Node.js. I build fast, accessible web apps.

A recruiter should be able to match you to a job title before they scroll. Add your location or timezone if you want remote work.

2. About — not a CV summary

Three questions, three or four sentences total:

• What kind of problems do you enjoy solving?
• What stack do you specialise in (and what are you deliberately not)?
• Which single project are you proudest of, and why?

Specific beats impressive. “I like performance work — cutting a 2.4s LCP down to 900ms is my idea of a good afternoon” tells a hiring manager more than a paragraph of adjectives.

3. Featured projects — the heart of it

Every project gets five things. No exceptions:

• Problem — what it solves, in one line
• Stack — the actual technologies, not a wishlist
• Live demo link — clickable, working today
• GitHub repo link — public, with a real README
• One technical challenge — and how you solved it

That last point is what turns a project into an interview. “Cursor positions desynced when two users edited at once, so I moved to an operational-transform buffer with a 50ms debounce” gives the interviewer their first question — and you already know the answer.

4. Technical writing / blog (bonus)

If you have written anything on Dev.to, Medium, or your own blog, link two or three pieces. Writing is a proxy for the thing every team complains about: communication. A developer who can explain a migration in 800 words can explain it in a design doc.

5. Contact — one click, no forms

Email, LinkedIn, GitHub. A contact form that emails a mailbox you check monthly is worse than nothing. Make replying to you the easiest action on the page.

Not another todo app. Not a weather widget with an API key in the client. Reviewers have seen both a thousand times, and both signal “I completed a tutorial.” A project earns its place if it hits at least one of these:

• It solves a real problem. Even a small, personal one — a CLI that renames your invoices, a dashboard for your climbing gym.
• It has actual users. Five real people using something is more impressive than zero people using something ambitious.
• It shows full-stack thinking. Auth, data modelling, deploys, error states — the unglamorous parts that prove you can ship.
• It demonstrates a niche skill. WebSocket, WebRTC, Canvas, WASM, workers, streaming. Anything that is hard to fake.

One caveat on clones: a Spotify clone is filler, but a Spotify clone with offline playback and a service-worker cache is a conversation.

A green contribution graph is not a portfolio. It proves you commit; it says nothing about what you commit. Assume a hiring manager spends less than 30 seconds on your profile — usually while three other tabs are open.

• Pin the right repos. Six slots. Use four. Pin the projects on your portfolio, not the coursework from 2023.
• Write real READMEs. One screenshot or GIF at the top, a one-paragraph description, setup instructions that actually work on a clean machine, and a short note on architecture decisions.
• Delete or archive the graveyard. Forty abandoned forks make the four good repos harder to find.
• Fill in your profile. Bio, location, link to your portfolio. Yes, people click it.

Think of GitHub as the appendix and your portfolio as the paper.

Always prefer live. A screenshot asks the reviewer to imagine the product working; a URL removes the doubt. Vercel, Netlify, Railway, Render and Fly.io all have free tiers that comfortably host a side project.

If the backend genuinely cannot stay online — paid APIs, heavy jobs, hardware dependencies — record a 60-second walkthrough. Screen capture, your voice, no intro. Show the flow that matters, then link the repo with local setup instructions. And check your links monthly: a dead demo is worse than no demo, because it suggests you do not maintain things.

Notice what is doing the work: numbers, a named constraint, and one decision with a reason. Copy the shape, not the content.

You could build the portfolio site itself — and if performance work is your pitch, maybe you should. But a hand-rolled site is another repo to maintain, and plenty of strong developers have a half-finished portfolio branch that has been sitting there since March.

1. Sign up and claim your handle: portfoliolink.id/u/yourname
2. Fill the hero with your role and stack sentence
3. Add three or four projects with demo and repo links
4. Drop in skills, writing links and contact
5. Publish — meta tags, schema and sitemap are generated for you

Then put that one link in your GitHub bio, LinkedIn headline, and the top line of your CV. If you want it to rank in search too, follow the SEO guide for portfolio websites. Comparing hosts first? See our comparison of the best free portfolio sites, or the step-by-step guide to building a portfolio online.