A developer portfolio
that ships.
A developer portfolio is judged on what you have built, not how you describe yourself. It leads with two or three real projects, each with a live link, the repo, the stack, and the problem you solved, and it loads fast because a slow developer site is its own bad review. To build one, paste your resume into Portfolio, pick a clean, high-contrast design that reads well in a dark theme, and put your best project above the fold with the link and the code one click away. It is a better fit than a bare GitHub profile because it frames the work, and it ships as fast static HTML rather than a heavy single-page bundle.
Site, GitHub, or a link page.
Developers usually pick between a real portfolio site, their GitHub profile, and a link aggregator. Here is how the three read to a hiring engineer.
| What a hiring engineer wants | GitHub profile only | Link aggregator | Portfolio site |
|---|---|---|---|
| Context around the code | Just a README, if that | None, only links | Problem, stack, and result per project |
| Best work surfaced first | Buried by pinned repos and forks | Whatever you list | You choose the order and the framing |
| A live demo next to the repo | If you added a link | Rarely | Link and code side by side |
| Loads fast | Yes | Yes | Server-rendered static HTML |
| On your own domain | A github.io subdomain | Their domain | Your name, automatic TLS |
| A resume that passes screening | No | No | 48 layouts, live ATS scoring |
Keep the GitHub profile too; the portfolio site links to it. The site is the framing, the repos are the evidence, and they work together.
Projects, repos, stack, speed.
Four things carry a developer portfolio. Get them right and the design can be almost invisible, which is what most engineers want anyway.
A hiring engineer reads two projects closely and skims the rest. Pick the strongest two or three, ideally things you shipped that other people use, and cut the tutorials and half-finished experiments.
For each project, put a live link and the source one click apart. Reviewers open the demo to see it works and the repo to see how you write. Missing either one loses half the point of the project.
A short line on what it does, the problem it solved, and the stack you used. Name the languages, frameworks, and infrastructure plainly, because those are the terms a recruiter and an engineer both scan for.
A developer's own site is a performance sample. Portfolio ships static HTML, so there is no heavy client bundle to explain away. A fast page is a quiet argument that you care about the craft.
The same paste builds a resume with a live ATS score, so the stack keywords a recruiter searches are present in the document their software reads first.
Terms to keep in the resume.
The builder produces a resume as well as a site. Make sure the technologies a recruiter filters on appear in it, spelled the way the posting spells them.
Match the exact spelling in the posting, since some filters treat Node and Node.js as different tokens. Check the finished resume with the free ATS score checker.
Which of the 60 designs suit an engineer.
Of the 60 designs and 48 resume layouts, these read as an engineer built them, and these get in the way of the code.
Developers live in dark editors, and a legible dark theme reads as native to the audience. Portfolio renders every design in a light or dark theme, so pick a spare family and let it run dark.
If your work is architecture, data, or platform rather than front-end flourish, a quiet editorial family frames long project write-ups better than a decorative one and keeps the focus on the reasoning.
A photographer's full-bleed layout buries the links and the stack under hero images. Your evidence is text and code, so a design built for pictures fights you.
Choose one of the 48 layouts that lists languages and tools clearly and keeps one column, so a parser reads your stack in order and nothing scrambles into the wrong section.
Who a developer template is not for.
A project-led site helps most developers and a few not at all. Here is the honest split.
Build one if you
- +Have shipped work you can link to, whether an app, a library, an open-source contribution, or a service in production.
- +Are early in your career and want projects to stand in for a long work history.
- +Freelance or contract and want one link that frames the code better than a raw repo list.
- +Want the matched, ATS-safe resume the same paste produces, with your stack keywords in place.
Skip it if you
- −Have nothing public to show because all your work sits behind a company firewall and cannot be linked. Write about the systems instead, or lead with the resume.
- −Only apply through large internal portals where an external site is rarely opened. Fix the resume for the software first.
- −Want pixel-exact control of a hand-coded site and enjoy building it. A framework and your own hosting suit that better.
- −Have only tutorial clones to show. Ship one original thing first, then build the page around it.
Building a developer site.
The questions engineers ask before they put up a portfolio.
Do I need a portfolio if I already have GitHub?
They do different jobs. GitHub shows your code but not the story around it, and a hiring engineer scanning your profile sees pinned repos and forks with no framing. A portfolio site puts your two or three strongest projects first, each with the problem, the stack, and a live demo next to the repo, then links back to GitHub for the code. Keep both; the site is the framing and the repos are the evidence.
How many projects should a developer portfolio show?
Two or three, shown well, beats ten shown briefly. Reviewers read the first project closely, skim the second, and rarely reach the fifth. Pick things you actually shipped that other people use, give each a demo and a repo, and cut the tutorial clones and abandoned experiments that dilute the strong work.
Should a developer portfolio use a dark theme?
A dark theme reads as native to an audience that lives in dark editors, so it is a reasonable default, but a clean light theme is fine too. Portfolio renders every design in both, so the honest answer is to pick whichever is more legible for your content and let the reader's own preference decide. Legibility matters more than the palette.
What if my best work is closed source?
Describe the systems without exposing the code. Explain the problem, the scale, the stack, and the outcome at a level that breaks no agreement, the way you would in an interview. A short, well-written account of a hard closed-source system can be more convincing than a public toy project, and it still gives a recruiter the stack keywords to match.
Does the site need to be fast, or is that just vanity?
It matters, because a developer's own site is a performance sample. A slow, heavy page undercuts any claim that you care about the craft. Portfolio ships static, server-rendered HTML with no client bundle to explain, so the page loads instantly and quietly makes the argument for you.
Keep going.
Compare styles, test your resume, or read the full product.
Paste a resume.
Lead with what you shipped.
Start free. Portfolio drafts the page from your resume, then you put your strongest two or three projects first, each with a demo and a repo, on a fast static site. Connect your own domain with automatic TLS.