# Portfolio Website Structure > The five sections a developer portfolio site needs, in order, with the copy prompts for each one. **What this is:** A page-by-page and section-by-section plan for a portfolio site, plus the deployment steps to get it live for free. **Time needed:** A weekend, including deployment **You end up with:** A live portfolio site with a URL you can put on a CV. --- ## 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 moves in. Do not put your life story above your projects. ## The structure | Section | Purpose | Length | | --- | --- | --- | | 1. Header | Name, role, one line on what you build, links out | Fits on one screen | | 2. Projects | Two or three projects with evidence | The bulk of the page | | 3. About | Who you are and where you are heading | Two short paragraphs | | 4. Skills | Technologies, grouped by what you use them for | A compact list | | 5. Contact | One obvious way to reach you | Two lines | _Everything else — blog, 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." Avoid: a full-screen hero with a typewriter animation and no information in it, and any variant of "passionate about technology". ## 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, one line on what it does, the stack, a live link, a source link, and two or three lines on the interesting technical part. A screenshot or GIF for each one if you can. Two or three projects. Not eight. If you have eight, pick the three that best match the role you want and leave the rest on GitHub. Order them by strength, not by date. Your best project goes first even if it is a year old. ## 3. About Two short paragraphs, written in your own voice, in the first person. 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 is worth more than 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 reviewers, because a self-assessed "90% Python" tells them nothing and invites an awkward question. A workable grouping: Languages / Frameworks and libraries / Databases and infrastructure / Tools. List only what you would be comfortable being asked about. If you want to signal depth honestly, split into "Used in production or in a deployed project" and "Used in coursework and side projects". That is a distinction reviewers find genuinely useful. ## 5. Contact One obvious action. A plain email address is enough, and it is more reliable than a contact 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`. ## Before you publish - [ ] **Test on a real phone** Not a narrow desktop window. Check tap targets and that nothing scrolls sideways. - [ ] **Click every link** Especially the CV download and the live project demos. - [ ] **Run Lighthouse in Chrome DevTools** Aim for 90+ on performance and accessibility. Both are achievable on a simple site. - [ ] **Set the page title and meta description** "Priya Raman — Back-end Developer" beats "Create Next App", which is what most student sites still say. - [ ] **Add a favicon** A letter on a coloured square is fine. The default globe icon looks unfinished. - [ ] **Check it in a private browser window** Catches unpublished pages and assets that only exist in your cache. - [ ] **Ask one person to read it and tell you what you do** If their answer does not match your target role, the header is not working yet. ## Getting it live, free You do not need to pay for hosting. Push the project to GitHub, connect the repository to Vercel, Netlify or Cloudflare Pages, and it deploys on every commit. All three have free tiers that comfortably cover a portfolio site. 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. For a plain HTML/CSS/JS site, GitHub Pages works and needs no third-party account at all. ## Deploying with Vercel from the command line ```bash # from your project folder npm i -g vercel vercel login vercel # preview deployment vercel --prod # production deployment # after this, every push to main deploys automatically ``` > **What to skip** > > Custom cursors, page-load animations longer than about 300ms, particle backgrounds, horizontal scroll-jacking, and 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. --- Part of the free Developer Portfolio Toolkit — https://devproof.app/free-developer-portfolio-toolkit Free to use, copy and adapt for your own portfolio.