Most developer portfolios are a digital business card: headshot, a wall of logos, links to GitHub and LinkedIn. A hiring manager glances and bounces. The ones that get callbacks do the opposite of listing skills. They show the work.
A senior engineer looking at your portfolio wants three answers: can you build real things, do you write code someone else can maintain, and do you understand the whole stack from database to deploy. Prove all three and you have already beaten most applicants, because most portfolios prove none of them. They assert skills; they do not demonstrate them. The gap between "proficient in React" on a list and a running app you can click into is the entire game.
Build around three projects, not ten
Pick three to five projects, no more. Quantity past that dilutes; a hiring manager skimming ten repos assumes none is worth their attention, while three sharp ones invite a real look. For each project, give one line on what it does, the stack, your specific role, a live link, the repo, and the hardest problem you solved. That last item matters most. "Built a chat app" is a category; "handled message ordering and reconnection when a client drops mid-conversation" is evidence of an engineer who has met reality.
Curate the set deliberately. At least one project should use your target role's stack, so the match is obvious. At least one should be more than a CRUD app, because anyone can wire a form to a database and the interesting signal lives past that. And at least one should be a project you would happily spend twenty minutes defending in an interview, since the strongest projects become the conversation that gets you hired. If you write at all, link two or three technical posts; the ability to explain a decision clearly in prose reads as a senior signal, because that is half of what senior engineers actually do.
What to cut is just as important. Tutorial clones, the to-do app, the weather widget, the Netflix UI copy, prove you can follow instructions, not that you can build something nobody handed you the steps for. A bare list of technologies with nothing behind them reads as keyword stuffing, the same way it does on a resume. And a green GitHub contribution graph means only that you pushed commits, not that the code was good or the projects mattered. None of those belong center stage.
Match the portfolio to the role
The strongest portfolios are aimed, not generic. A backend-focused one might show a job queue in Go doing 10K tasks a minute with exactly-once delivery, a real REST or gRPC API with auth, and a merged pull request to a project people have heard of. A full-stack portfolio shows one genuinely end-to-end app, database through deploy, paired with a short architecture write-up explaining a decision you made and the trade-off it cost. An early-career portfolio leans on a capstone or personal project that solved a real problem plus visible, ongoing contributions. In every case the portfolio says one thing the resume can only claim: I can build, and here is the thing I built.
Where to host
You do not need anything fancy. The platform matters far less than the projects on it.
| Option | Cost | Best for |
|---|---|---|
| GitHub Pages | Free | Simple, code-based static site |
| Vercel / Netlify | Free | React/Next.js portfolios + custom domain |
| Custom domain | ~$15/yr | A professional, memorable address |
A yourname.dev domain is cheap and quietly signals you take this seriously; it costs less than a couple of coffees a year and makes you easier to remember than a github.io subdomain. Whatever you choose, your resume and portfolio should reinforce each other rather than repeat. The resume claims "built a distributed task queue handling 10K tasks/min"; the portfolio links that exact project with the detail, the diagram, and the hard part. Summary and evidence, working as a pair.
Key takeaways
- Show the work; do not list skills. Most portfolios assert, the good ones demonstrate.
- Three to five documented, original projects beat ten tutorial clones every time.
- Aim the set: one matches your target stack, one is genuinely hard, one you can defend at length.
- A custom domain is cheap professionalism; link the portfolio from your resume so the two reinforce each other.
FAQ
How many projects should a portfolio have?
Three to five, each well-documented. Depth beats volume: one job queue with exactly-once delivery and a clear write-up of the hard part outweighs ten tutorial clones, and a tight set invites a real look where a sprawling one gets skimmed past.
Are tutorial projects bad for a portfolio?
As a centerpiece, yes. To-do apps, weather widgets, and streaming-site clones show you can follow steps, not that you can build something independently. Replace them with original projects that solved a real problem, even a small one.
Do I need a custom domain?
It is not required, but a yourname.dev domain costs around $15 a year and signals professionalism while being easier to remember. Free hosts like GitHub Pages, Vercel, or Netlify work perfectly well if you would rather not pay.
What should each project include?
One line on what it does, the stack, your specific role, a live link, the repo, and the hardest problem you solved. That last detail is what separates a real engineer from someone who completed a tutorial, so lead with it when you can.
Make sure your resume drives people to that portfolio: check it on PassTheBot and add the link where recruiters see it.