Your portfolio does not need a framework, a build step or a monthly subscription. It needs three files, a folder structure you can explain out loud, and a weekend of focused work. Plain HTML for structure, CSS for layout and type, a few lines of JavaScript for the small interactions that make a page feel finished. The result loads quickly on a phone in a train tunnel, and you will still understand every line of it a year from now.
Most portfolio sites fail for a boring reason: they are organised around what the owner enjoys building rather than what a visitor came to check. A recruiter, a potential client and a fellow developer all arrive with the same three questions. What do you do, can you show it, and how do I reach you?
Answer those in the first screen and the rest of the page becomes supporting evidence. Before you open your editor, write one sentence describing who the site is for. “A portfolio for front-end roles at small product teams” is a usable brief. “A showcase of my journey” is not.
Four or five sections are plenty. Resist the urge to add more until the first version is live.
Write the copy in a plain text file first. Cutting weak sentences is easier there than inside a browser tab.
Semantic HTML is not decoration. It is what screen readers announce, what search engines index, and what future you reads when the design changes. A page built from header, nav, main, section, article and footer describes itself. A page built from nine nested divs describes nothing.
Give every project its own article element. Wrap the top of the page in a header with the navigation inside a nav. Put everything unique to that page in main and keep the footer outside it. That structure costs nothing now and saves a painful refactor later.
Use one main heading for the page — your name or the site name — then a second-level heading for each section, and third-level headings for anything nested inside. Never pick a heading level because it looks smaller. Style the size with CSS and leave the structure honest.
Two more habits worth building. Write alt text that describes what the image shows, not the file name: “Dashboard showing a weekly sales chart” beats “screenshot-2”. And use a link when something goes somewhere, a button when something happens. If the mobile menu is a toggle, make it a button element.
Start with the narrow layout because it is the hardest one to fit, and everything after it is easier. A single column, comfortable type around 1rem to 1.125rem, line height near 1.6 and generous space between sections will already look tidy on a phone.
Define a few custom properties at the top of your stylesheet — a background, a text colour, an accent, a small spacing unit — and reuse them everywhere. Change the accent in one place and the whole site follows. For the project grid, CSS Grid with auto-fit and a minimum card width gives you a responsive layout without a single media query. Add one breakpoint near 45rem for the two-column arrangements and stop there.
Fluid type is worth the three lines it takes. A clamped font size lets headings grow with the viewport between a sensible minimum and maximum, which removes a pile of breakpoints. Then drag the window from narrow to wide, slowly. Everything should stay readable at every width in between, not just at the two sizes you designed for.
Two small features cover almost everything a portfolio needs. The first is a menu toggle for small screens: a button with an accessible name, a class toggled on the navigation, and aria-expanded kept in sync so assistive technology knows whether the menu is open. The second is a theme switch that reads the visitor's system preference on load and remembers their choice in local storage.
Build both so the site still works when the script fails. On desktop the navigation should be visible with no JavaScript at all; a menu that only opens after a script runs is a fragile menu. Keep the whole file under fifty lines, add a comment above each block explaining what it does, and skip the scroll animations nobody asked for.
Before you deploy, tab through the page with the keyboard. Every link and button needs a visible focus outline. Check that text has enough contrast against its background, especially grey captions on white. Compress your screenshots; a portfolio that takes four seconds to load on a phone has already lost part of its audience.
Then the metadata you only miss when it is absent. The page title should carry your name and your role. A meta description of one or two sentences appears in search results and link previews. Add a favicon so the browser tab looks deliberate. Fix broken links, click the email link yourself, and open the finished site on a real phone over mobile data rather than in a desktop simulator.
Static sites are cheap to host because they are just files. GitHub Pages will serve your repository at no cost, and Netlify and Cloudflare Pages both offer free tiers that deploy from a Git repository. Pick one and resist switching every few months.
Keep the repository public. A readable commit history is itself a small piece of evidence that you finish things. Update the site when you complete a project, not on a schedule you will abandon in three weeks.
Give yourself a deadline you can hit: copy on Friday evening, markup and styles on Saturday, deploy and test on Sunday. Three projects, four sections, one stylesheet, one script file. The first version does not need to be complete — it needs to be online, because a live site you can improve beats a perfect one still sitting in a folder.
Once it is up, send the link to two people who will actually click it and ask them one question: what do you think I do? If their answer matches the sentence you wrote at the start, the page is working. Start there, then add the fourth project next month.
Photo: Helena Lopes / Pexels
A practical comparison of local coding meetups and online communities on feedback, networking, access and...
A practical guide to Advent of Code: how the December puzzle event works, how to handle its uneven difficulty, and...
Python 3.14's changes that actually touch beginner code: clearer errors, lazy annotations, t-strings, a tidier...
Fuel your passion for coding and development.
