How to Make a Portfolio Website

Start with one page

A single well-made page beats a five-page site with three empty pages on it. Build one page with five sections, get it deployed, and only split it up later if a section genuinely outgrows the space.

The order below is not arbitrary. It is the order a reviewer’s attention actually moves in, and the most common mistake is putting your life story above your projects.

The five sections

Everything else — a blog, a timeline, testimonials, a hero animation — is optional, and none of it substitutes for the five above.

1. Header

The only job of the header is to answer “who is this and what do they build?” before anyone scrolls. Include your name, your target role, one sentence on what you build, and links to GitHub, CV and email. That is all.

Copy pattern: [Name] — [role]. I build [what] with [main technologies]. Currently [studying / looking for a placement / open to junior roles].

Worked example: “Priya Raman — back-end developer. I build APIs and data pipelines in Python and Go. Final-year computer science student looking for a summer 2027 internship.”

Twenty words, three facts. Compare it to what most student sites open with — “Passionate developer with a love for clean code” — which contains no information and describes several hundred thousand people.

Avoid a full-screen hero with a typewriter animation and nothing in it. A reviewer who has to scroll to find out what you do has already started forming an impression, and it is not a good one.

2. Projects

This is the section that gets you interviews. Give it the most space and put it directly under the header.

For each project, show:

• A name and a one-line description written for someone who has never seen it
• The stack, named explicitly — reviewers filter on these words
• A live link, or a demo recording if it genuinely cannot be deployed
• A source link
• Two or three lines on the interesting technical part
• A screenshot or GIF, if you can

Two or three projects, ordered by strength rather than by date. Your best project goes first even if it is a year old. If you have eight, pick the three that best match the role you want and leave the rest on GitHub.

3. About

Two short paragraphs, in your own voice, in the first person. Not a third-person biography.

Paragraph one: where you are. Course, year, what you have been building, what you are aiming at.

Paragraph two: something specific and human. What got you into this, what you are currently learning, what you do that is not code.

One concrete detail beats three sentences of adjectives. “I got into programming automating the rota at the pub I worked at” is memorable. “I am a passionate and detail-oriented developer” is not.

4. Skills

Group technologies by role rather than rating them. Percentage bars and five-star ratings are actively disliked by technical reviewers, because a self-assessed “90% Python” tells them nothing and invites an awkward question.

A workable grouping:

• Languages — Python, Go, SQL, TypeScript
• Frameworks and libraries — Django, FastAPI, React
• Data and infrastructure — PostgreSQL, Redis, Docker
• Tools — Git, GitHub Actions, Linux

If you want to signal depth honestly, split into “used in a deployed project” and “used in coursework and side projects”. Reviewers find that genuinely useful, and it costs you nothing in credibility.

List only what you would be comfortable being asked about for five minutes.

5. Contact

One obvious action. A plain email address is enough and it is more reliable than a form.

If you do use a form, test that it actually delivers and still show the email address as a fallback. A silently-failing contact form has cost people interviews.

Add your CV as a downloadable PDF here, named firstname-lastname-cv.pdf.

Which stack to use

Whatever you can finish and deploy this weekend. Do not learn a new framework to build your portfolio — that is how three weekends disappear.

Templates are fine. Using a well-made template and filling it with excellent content beats a hand-built site with placeholder text. Just remove every trace of the template’s demo content — an unedited “Lorem ipsum” or a leftover “John Doe” is a very visible failure.

Deploying it free

Push the project to GitHub, connect the repository to a host, and it deploys on every commit. All of these have free tiers that comfortably cover a portfolio site.

• Vercel — best fit for Next.js, works with anything static
• Netlify — similar, with a good forms feature on the free tier
• Cloudflare Pages — generous limits, very fast
• GitHub Pages — no third-party account needed for a plain static site

# from your project folder$ npm i -g vercel$ vercel login$ vercelPreview: https://portfolio-abc123.vercel.app$ vercel --prodProduction: https://portfolio.vercel.app# every push to main now deploys automatically

The failures you will hit, in the order you will hit them:

• A build that works locally and fails on the host. Almost always a case-sensitive import path. macOS and Windows do not care; Linux does.
• Missing environment variables. Set them in the host’s dashboard, not in a committed file.
• Broken image paths. Relative paths that worked from your file system will not resolve the same way.

Domain names

A custom domain is roughly €10–15 a year and worth it — yourname.dev on a CV reads better than a platform subdomain. It is not a blocker, though. Publish on the free subdomain today and add the domain later; all four hosts let you attach one in a few minutes.

What matters more than the extension is that the URL is clean. Avoid anything with a random hash in it — that is what a preview deployment looks like, and it suggests you have not set up production properly.

Before you publish

• Test on a real phone, not a narrow browser window. Check tap targets and that nothing scrolls sideways.
• Click every link, especially the CV download and the live demos.
• Run Lighthouse in Chrome DevTools. Aim for 90+ on performance and accessibility — both are easy on a simple site.
• Set the page title and meta description. “Priya Raman — Back-end Developer” beats “Create Next App”, which is what a surprising number of student sites still say.
• Add a favicon. A letter on a coloured square is fine.
• Check it in a private window to catch unpublished pages and cached assets.
• Ask one person what they think you do. If the answer does not match your target role, the header is not working yet.

What to skip

Custom cursors. Page-load animations longer than about 300ms. Particle backgrounds. Horizontal scroll-jacking. Anything that delays a reviewer seeing your projects.

A portfolio site is judged on clarity and speed. Reviewers open a lot of these, usually on a laptop between meetings, and the ones that get remembered are the ones where the work was easy to find.

The site is step seven of nine. If your GitHub is still a mess, fix that first — it is the thing a technical reviewer opens.