DEV Community: Dipen Dedania

The Internet Lied to You About Portfolio Websites

Dipen Dedania — Mon, 07 Sep 2026 11:25:50 +0000

Here's what I found: most of the advice floating around is either outdated, wrong, or only applies if you're trying to impress other developers instead of getting hired.

Let me break down the three biggest lies.

Lie #1: "Your Portfolio Needs a Modern Stack"

This is the most pervasive myth. Every tutorial tells you to spin up Next.js, add TypeScript, configure Tailwind, set up MDX, deploy to Vercel, and hook up a CMS.

Wrong.

When I sorted the 148 profiles by GitHub stars, something interesting happened. The top performers weren't the most technically complex. They were the ones with the clearest message and the fastest load time.

Here's the real tech stack distribution I found:

Vanilla HTML/CSS/JavaScript — Clean, zero-dependency sites that load in under a second
React/Next.js — The most common framework choice, but far from the only path to a great portfolio
Hugo/Jekyll/11ty — Static site generators that are boring, reliable, and fast
Vue/Svelte — Less common, but the ones that use them tend to have distinctive designs
GSAP/Three.js — The "impressive" stack — but often overkill for a portfolio

The portfolios that stood out didn't stand out because of their stack. They stood out because of clarity.

Take Brittany Chiang's v4 — React, Gatsby, styled-components. Nothing groundbreaking. But the design is so clean, the information so well-organized, and the personality so present that it became one of the most referenced developer portfolios on the internet.

The lesson: Pick whatever you're comfortable with. A portfolio built in plain HTML by someone who understands design will always outperform a Next.js monstrosity built by someone who doesn't.

Lie #2: "More Features = More Impressions"

LinkedIn is full of portfolio showcases with parallax scrolling, 3D models, particle effects, custom cursors, page transitions, and easter eggs. And sure, they get screenshots shared on Twitter.

But here's the data that nobody talks about: the portfolios that actually convert visitors into opportunities are boring.

Not boring as in ugly. Boring as in predictable. You land on the page, and within 3 seconds you know:

Who this person is
What they do
What they want you to do next

The most common pattern among high-performing portfolios in my collection:

Hero section — Name, role, one-liner
About section — Short bio, maybe a photo
Projects/Work — 3-6 showcased projects with links
Contact — Email, GitHub, LinkedIn

That's it. No 3D globe. No particle system. No page that takes 4 seconds to load while a CSS animation plays.

One developer I analyzed — Tania Rascia — runs a blog-first portfolio built with React and Gatsby. No fancy animations. No interactive elements. Just well-written content and a clean layout. Her portfolio drives more traffic than most "impressive" portfolios because it's useful.

The lesson: Every feature you add is a feature that can break, slow down, or distract from your actual message. The best portfolios are the ones where you can't find anything to remove.

Lie #3: "You Need to Build It From Scratch"

This one keeps so many developers from ever launching a portfolio at all. They think they need to write every line, design every component, and craft every animation from nothing.

You don't.

Some of the best portfolios in the collection are forked templates that were customized:

Adeola Adeoti forked a template and made it his own with TypeScript, GSAP, and Next.js. The result is polished, professional, and completely "his."
DeveloperFolio by Saad Pasta is a template that dozens of developers have forked. Each fork looks different because each person customized the content, colors, and sections.
gitprofile by Arif Szn is a GitHub-powered portfolio that pulls your repos and stats automatically. Zero content management required.

The developers who get this right understand something important: a portfolio is a tool, not an art project. Its job is to communicate who you are and what you do. How you build it is irrelevant to the person viewing it.

The fork → customize → deploy workflow works because:

The design decisions are already made
The responsive layout is already handled
The deployment is already configured
You just need to add your personality

The lesson: Fork a portfolio template today. Customize it this weekend. Ship it Monday. Perfect is the enemy of deployed.

What Actually Works (From 148 Real Portfolios)

After analyzing all of these profiles, five patterns emerged that separated the best from the rest:

1. Speed Wins

Every top-performing portfolio loads fast. Not "acceptable" fast. Actually fast. Under 2 seconds, ideally under 1.

This isn't just a technical nice-to-have. It's a first impression. A slow portfolio tells a recruiter: "This developer doesn't care about user experience." Harsh? Yes. True? Also yes.

2. Personality Beats Polish

The portfolios that get remembered aren't the most polished. They're the most personal. A developer who writes "I build things that make people's lives slightly less annoying" in their hero section will always be more memorable than one who writes "Passionate full-stack developer with 5+ years of experience."

3. Projects Need Context

Listing project names and links isn't enough. The best portfolios explain what the project does, what problem it solves, and what technologies were used. One sentence per project can make the difference between "cool" and "I want to hire this person."

4. One Clear CTA

"What do you want me to do?" If a visitor has to think about this, you've already lost them. The best profiles end with exactly one clear action: email me, check my GitHub, download my resume. One. Not five. One.

5. Content > Container

A beautiful portfolio with nothing interesting to say is still empty. The portfolios that perform best are the ones where the content — the projects, the writing, the personality — does the heavy lifting. The design just gets out of the way.

The Portfolio That Gets You Hired

Here's the uncomfortable truth: nobody hires you because your portfolio has a dark mode toggle or a typing animation. They hire you because your portfolio made them believe you can do the job.

That belief comes from:

Seeing your work (real projects, real code)
Understanding your thinking (project descriptions, technical decisions)
Feeling your personality (writing style, design choices)
Trusting your professionalism (it loads fast, it works on mobile, the links aren't broken)

Everything else is decoration.

I Built a Tool to Make This Easier

Creating a portfolio from scratch is overwhelming. Even with inspiration, you're staring at a blank editor wondering where to start.

That's why I built Awesome GitHub Websites — a free, curated gallery of GitHub-hosted profile websites.

Here's what makes it different from every other "portfolio inspiration" list:

148 real, working portfolios — Not mockups. Not dribbble shots. Live sites you can visit, inspect, and learn from.
Filter by style — Find minimal designs, creative showcases, or blog-first setups in seconds.
Multiple views — Browse as a gallery, flip through a book, or swipe through cards like Tinder.
Direct source code links — Every portfolio links to its GitHub repo. Fork it, customize it, ship it.
Setup guide — Step-by-step instructions for publishing your own portfolio on GitHub Pages.

I built this because I was tired of seeing developers waste months on their portfolio when they could have spent 30 minutes forking a template and shipping something real.

Browse the gallery →

The 30-Minute Portfolio Challenge

You don't need a week. You don't need a tutorial series. You don't need to learn a new framework.

You need 30 minutes and a decision.

Browse the gallery and pick a portfolio that matches your style
Fork the repository (every template links to its source code)
Customize three things: your name, your bio, and your projects
Enable GitHub Pages in your repository settings
Push and deploy — your portfolio is live

That's it. Your GitHub profile URL becomes your portfolio URL. When someone Googles your name, your work shows up.

No excuses. No "I'll do it next month." Do it now.

The Bottom Line

The internet will keep telling you to use the latest framework, add the flashiest features, and spend weeks perfecting every pixel. The internet is wrong.

The best portfolio is the one that's live. The one that clearly communicates who you are. The one that makes it easy for someone to say "I want to talk to this person."

Build that one. Ship it today. Improve it tomorrow.

Stop planning. Start shipping.

Resources

Awesome GitHub Websites — Free curated gallery of 148+ GitHub portfolio websites
GitHub Pages Docs — Official guide to hosting on GitHub Pages
GitHub Profile README — How to create a profile README

Think I missed a myth? Found a portfolio that proves me wrong? Open an issue or drop a comment below — I'll add it to the gallery.

I lost 40 minutes to an AI agent that had already crashed. So I built a nervous system for all of them.

Dipen Dedania — Tue, 21 Jul 2026 12:04:43 +0000

I gave Claude Code a gnarly refactor, hit enter, and switched to something else. That's the whole promise of agentic coding, right? Fire and forget.

Forty minutes later I tabbed back to check on it.

It had died in the first ninety seconds.

A transient error, a half-printed stack trace, and then… nothing. The terminal just sat there, cursor blinking, looking exactly like an agent deep in thought. I had spent forty minutes "letting it cook" while it was stone cold.

And here's the part that actually stung: I wasn't even sure which agent I'd left it running in. Claude Code? The Cursor pane? The Codex tab I'd opened that morning? I now have seven of these things installed — Claude Code, Cursor, Copilot, Codex, Kiro, Antigravity, Grok — and checking on them had quietly become a full-time tab-hopping job.

I was paying an alt-tab tax on every single agent run. And the tax kept going up.

So I built the thing I wanted: Agent Pulse — ambient, glanceable awareness of every AI coding agent on your machine, in a floating frosted-glass bubble that lives on your desktop.

The idea in one sentence

Your agents already emit lifecycle events. Nobody was listening. Agent Pulse listens — and turns them into a single, ambient heartbeat you can see from across the room.

A soft pulsing glow means working. A calm breathing effect means idle. A red shake means your agent just died — so you find out in two seconds, not forty minutes.

That's it. That's the whole pitch. Everything below is the fun part: how it actually works, and the genuinely strange things I found out trying to make seven very different tools speak the same language.

Part 1: Seven tools, seven dialects, one schema

Every one of these agents can tell you what it's doing. The problem is they all do it differently:

Claude Code fires PreToolUse, Stop, and friends and can POST them over HTTP.
Cursor, Copilot, Codex, Kiro, and Antigravity run shell hooks — they shell out to a script on lifecycle events.
Grok's runtime blocks HTTP hooks (SSRF protection), so it needs a command hook writing to a dedicated file.

None of them agree on event names. None agree on payload shape. Some don't even agree on where their config lives.

So the core of Agent Pulse is boring in the best way: a tiny local HTTP bridge on localhost:4242 that ingests everyone's events and normalizes them into one schema:

// The entire vocabulary. Every tool, every event, collapses into this.
type AgentState = "working" | "waiting" | "idle" | "error" | "dead";

PreToolUse → working. Stop → idle. A non-zero exit → dead. One-click install writes the right hook into the right config file for each tool (~/.claude/settings.json, ~/.cursor/hooks.json, .kiro/hooks/…, and so on), and one click removes it again. No manual JSON surgery.

The bubbles are just a thin, pretty layer on top: React 19 + Tailwind 4 + Framer Motion, always-on-top, draggable, glassmorphic. The hard part was never the glow. It was getting seven vendors to agree on what "busy" means.

Part 2: The rabbit holes nobody warns you about

This is the section I'd have killed to read before starting. If you're building anything that observes AI agents, save yourself the weeks:

🕳️ Copilot's logs don't contain token counts. At all. VS Code Copilot's hooks give you lifecycle state and sometimes a model name, but no real token usage — not even in the transcript. Every tool that shows you "Copilot tokens" is re-tokenizing the text and estimating (a common heuristic is ~0.25 tokens/char plus a tool-call fudge factor). I went looking for ground truth and found there wasn't any.

🕳️ Codex over-reports if you're naive about it. Codex tokens live in a rollout file as cumulative diffs. If you just sum the tail like a reasonable person would, you overcount by ~5%. You have to read the cumulative-diff structure.

🕳️ Cursor's real usage is behind a cookie you have to reconstruct. The only source of truth for Cursor usage is cursor.com/api/usage-summary — authenticated with a session cookie you rebuild from the access token sitting in Cursor's local state.vscdb.

🕳️ "Learned limits" are a trap. Some tools guess your rate limits from usage history. I decided early: never guess billing. Agent Pulse polls real quota APIs (Anthropic's OAuth usage endpoint, Codex's usage backend, Cursor, Antigravity) — and all cost figures are clearly labeled estimated API list prices, never your actual subscription bill. Trust is the whole product.

The meta-lesson: the ecosystem is wildly inconsistent, and most "analytics" you see are educated guesses wearing a suit. Being honest about that turned out to be a feature.

Part 3: The part that surprised even me

Once you have a reliable signal for "is this agent working or idle," you can build things that felt like sci-fi a year ago.

A self-running backlog. There's a Kanban board where you queue tasks. Define a scheduler window (say, "weeknights 8pm–11pm"), and Agent Pulse feeds queued cards to your agents while you're asleep. Execution tasks run in an isolated git worktree and hand you back an uncommitted diff — with an optional QA gate that runs your tests/lint/typecheck and auto-retries once before flagging the card as blocked. You wake up to a stack of reviewable diffs, not a mess.

Attention that finds you. When an agent sits in the waiting state past a threshold, Agent Pulse escalates: intensifies the bubble, raises an OS notification, and can ping Discord or Slack with the task summary and how long it's been stuck. Your agent needs you? You'll know — even away from your desk.

A local timeline. Every normalized event lands in a local SQLite DB (no telemetry, all on your machine). That gives you a GitHub-style activity heatmap, an hour-of-day rhythm chart ("apparently I pair with agents most at 11pm, cool, cool"), a tool-mix breakdown, and estimated-cost analytics.

None of this needed a new API. It all falls out of listening to signals that were already there.

Why this resonates (and why I think you'll feel it too)

We crossed a line recently and barely noticed. We stopped having one AI assistant and started running a fleet. But our tooling still assumes one agent, one terminal, one tab.

Managing a fleet by alt-tabbing is like monitoring a server farm by SSH-ing into each box every few minutes to run top. At some point you build a dashboard. Agent Pulse is that dashboard — but ambient, so it fades into your peripheral vision until something actually needs you.

You don't check on it. It taps you on the shoulder.
It's local-first. No account, no telemetry, no cloud. The bridge is loopback-only.
It's open source (AGPLv3), cross-platform (Windows / macOS / Linux), and adding a new tool is a documented, welcomed contribution.

Try it (2 minutes)

git clone https://github.com/Dipen-Dedania/agent-pulse.git
cd agent-pulse
npm install
npm run rebuild:native   # for the local SQLite timeline
npm start

Or grab a prebuilt installer from the Releases page — Windows .exe, macOS .dmg, Linux .AppImage.

Then open Settings, click Install hook next to whichever agents you use, and watch the bubbles come alive.

I want to hear from you

Two questions, and I'll reply to every comment:

How many AI coding agents are you running right now? Be honest. I bet it's more than you think.
Which tool should I add support for next? Open a request or drop it below.

If this saved you even one "wait, it crashed 40 minutes ago?!" moment, a ⭐ on the repo is the best thank-you — it's genuinely what decides whether the next person finds it.

Now go check on your agents. One of them is probably lying to you about being busy. 👀