I've watched dozens of developers spend months building a personal website from scratch, choosing between Next.js and Astro, debating CSS frameworks, hand-rolling a CMS, implementing dark mode with system preference detection, adding view transitions, setting up a CI/CD pipeline -- and then never actually shipping it. Or they ship it once, write one blog post, and never touch it again because the maintenance overhead of their custom setup kills their motivation.
The best website is the one that's live. Let me walk through what actually matters and what's pure yak-shaving.
What a website needs to do
Strip away the technical decisions and a website has one job: communicate information to a visitor. That's it. The visitor arrives, finds what they're looking for (or doesn't), and leaves. The technology behind the page is invisible and irrelevant to them.
For a developer portfolio, the minimum viable site needs:
- Your name and what you do (above the fold, immediately visible)
- 3-5 project showcases with links to live demos or repositories
- A way to contact you (email link, social profiles, or a form)
- Proof of competence (the projects themselves, blog posts, open source contributions)
For a product landing page:
- What the product does (one sentence, above the fold)
- Why someone should care (the problem it solves)
- How to get started (a CTA button)
- Social proof if you have it (testimonials, user count, logos)
Everything else -- blog sections, about pages, fancy animations, newsletter signups -- is secondary. You can add them later. But having them without the core content is like decorating a house before building the walls.
The technology decision tree
Here's how I think about choosing a tech stack for a website:
Do you need dynamic content that changes per user? If yes, you need a server or serverless functions. Use Next.js, Nuxt, SvelteKit, or similar.
Do you need a blog or documentation? If yes, use a static site generator with markdown support. Astro, Hugo, 11ty, or Jekyll. These generate static HTML at build time, which means zero server costs, instant page loads, and no security vulnerabilities from a running server.
Do you need neither? Write plain HTML and CSS. Seriously. A single index.html file with some CSS can be a perfectly effective website.
<!-- This is a complete, deployable website -->
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="utf-8">
<meta name="viewport" content="width=device-width, initial-scale=1">
<title>Your Name - Developer</title>
<style>
body { font-family: system-ui; max-width: 640px; margin: 2rem auto; padding: 0 1rem; }
h1 { margin-bottom: 0.25rem; }
.subtitle { color: #666; margin-top: 0; }
a { color: #0066cc; }
</style>
</head>
<body>
<h1>Your Name</h1>
<p class="subtitle">Full-stack developer</p>
<h2>Projects</h2>
<ul>
<li><a href="https://project1.com">Project One</a> - Description</li>
<li><a href="https://project2.com">Project Two</a> - Description</li>
</ul>
<h2>Contact</h2>
<p><a href="mailto:you@example.com">you@example.com</a></p>
</body>
</html>
That's a deployable portfolio site. It loads in under 100ms. It scores 100 on Lighthouse. It works on every browser back to IE11. It has no dependencies to update, no build step to break, and no security vulnerabilities.
Is it fancy? No. Does it communicate the essential information? Yes. Ship this on day one and add complexity only when you have a specific reason.
What actually impresses visitors
I've reviewed hundreds of developer portfolios as a hiring manager and as someone who frequently evaluates tools and libraries. Here's what makes a portfolio stand out:
Working projects with live demos. Nothing else comes close. A link to a deployed, functional project tells me more about your skills than any amount of text. If the project has users, even better.
Clear writing. One well-written blog post about a technical problem you solved demonstrates communication skills, depth of understanding, and the ability to teach. These are the qualities that make someone a strong hire.
Performance. If your personal website takes 5 seconds to load, that's a statement about your priorities as a developer. A fast, accessible site shows you care about the user experience.
What doesn't impress: Complex animations, dark/light mode toggles, particle backgrounds, or a custom-built CMS. These demonstrate time spent, not necessarily skill or judgment.
Four common mistakes
1. Choosing tools for the resume, not the project. Using Kubernetes to deploy a static portfolio site because you want Kubernetes on your resume is backwards. The tech stack should serve the project. If you want Kubernetes experience, build something that needs Kubernetes.
2. Premature optimization. Setting up ISR (Incremental Static Regeneration), edge caching, and a CDN for a site that gets 10 visitors a day is time you could spend building something people actually use.
3. Not deploying. A website on localhost isn't a website. Deploy to Vercel, Netlify, GitHub Pages, or Cloudflare Pages. All are free for personal projects. The deploy takes 5 minutes.
4. Redesigning instead of creating. If you've redesigned your portfolio three times but haven't added any new projects, your priorities are inverted. The content matters more than the container.
When to use a website builder
There's no shame in using a tool that handles the design, hosting, and deployment for you -- especially when your time is better spent building the projects that go on the site rather than building the site itself. For getting a website live quickly without writing code, I built a website builder at zovo.one/free-tools/ai-website-builder that generates a complete, responsive site from a description.
The web development community sometimes conflates "building the website" with "having a website." They're different goals. If your goal is to have a website that showcases your work and helps your career, the fastest path to that goal is the right one, regardless of the technology involved. Ship something today. Improve it tomorrow.
I'm Michael Lip. I build free developer tools at zovo.one. 350+ tools, all private, all free.
Top comments (0)