惯性聚合 高效追踪和阅读你感兴趣的博客、新闻、科技资讯
阅读原文 在惯性聚合中打开

推荐订阅源

量子位
雷峰网
雷峰网
博客园 - 三生石上(FineUI控件)
月光博客
月光博客
有赞技术团队
有赞技术团队
阮一峰的网络日志
阮一峰的网络日志
Last Week in AI
Last Week in AI
G
Google Developers Blog
腾讯CDC
B
Blog
Microsoft Azure Blog
Microsoft Azure Blog
酷 壳 – CoolShell
酷 壳 – CoolShell
Microsoft Security Blog
Microsoft Security Blog
人人都是产品经理
人人都是产品经理
博客园_首页
T
Tailwind CSS Blog
C
Check Point Blog
博客园 - 【当耐特】
MongoDB | Blog
MongoDB | Blog
A
About on SuperTechFans
Y
Y Combinator Blog
L
LangChain Blog
Engineering at Meta
Engineering at Meta
GbyAI
GbyAI

DEV Community

Authentication Security Deep Dive: From Brute Force to Salted Hashing (With Java Examples) Why AI Systems Don’t Fail — They Drift Spilling beans for how i learn for exam😁"Reinforcement Learning Cheat Sheet" I Replaced Chrome with Safari for AI Browser Automation. Here's What Broke (and What Finally Worked) How Python Borrows Other People's Work The $40 Architecture: Processing 1 Billion API Requests with 99.99% Uptime Vibe Coding: A Workflow Guide (From Zero to SaaS) Most webhook security guides protect the wrong side. The scary part is delivery. Headless CMS for TanStack Start: Build a Blog with Cosmic EU Age Verification App "Hacked in 2 Minutes" — What Actually Happened Comfy Cloud’s delete function does not actually remove files Running AI Models on GPU Cloud Servers: A Beginner Guide Event-driven media intelligence with AWS Step Functions and Bedrock I scored 500 AI prompts across 8 quality dimensions — here's what broke How to Call Google Gemini API from Next.js (Free Tier, No Backend Needed) The Portal Protocol: Reclaiming Human Connection in the Age of AI How to Fix Your Team's Scattered Knowledge Problem With a Self-Hosted Forum Intro to tc Cloud Functors: A Graph-First Mental Model for the Modern Cloud Designing Multi-Tenant Backends With Both Ownership and Team Access I Built a Neumorphic CSS Library with 77+ Components — Here's What I Learned PostgreSQL Performance Optimization: Why Connection Pooling Is Critical at Scale Cómo construí un SaaS multi-rubro para gestionar expensas en Argentina con FastAPI + Vue 3 🚀 I Built an Ethical Hacking Scanner Tool – Open Source Project I Replaced /usage and /context in Claude Code With a Single Statusline A Pythonic Way to Handle Emails (IMAP/SMTP) with Auto-Discovery and AI-Ready Design I Collected 8.9 Million Polymarket Price Points — Here's What I Found About How Markets Really Move EcoTrack AI — Carbon Footprint Tracker & Dashboard Everyone's Using AI. No One Agrees How. 5 self-hosted ebook managers worth trying in 2026 Building Your First AI Agent with LangChain: From Chatbot to Autonomous Assistant
4 Ways to Keep a Developer Portfolio Current (Compared Ho...
Sébastien Do · 2026-04-30 · via DEV Community

Most developers I know, myself included, built a portfolio once and then let it quietly rot. Six months pass, you've shipped a bunch of stuff, learned a new framework, contributed to three open source projects. Your portfolio still says you're "currently exploring TypeScript."

The problem isn't laziness. It's that keeping a portfolio updated is a chore that never feels urgent until you actually need it.

So what are the realistic options? I wanted to lay out four approaches I've either tried or watched other devs try, with honest trade-offs for each.

1. Manual Updates (The Classic)

You build a portfolio site with Gatsby, Hugo, plain HTML, whatever. You deploy it. You tell yourself you'll update it every month.

Pros: Total control over every pixel. No vendor lock-in. You can show off your design taste.

Cons: Nobody actually updates monthly. The friction is just high enough that it never happens. After a year, your "recent projects" section is older than some of your npm packages.

Best for: Designers who treat the portfolio itself as a showcase piece and enjoy tweaking it regularly.

2. GitHub Profile README as Portfolio

GitHub profile READMEs got popular fast. You can embed stats, pin repos, add badges. Some people have turned theirs into genuinely impressive pages.

Pros: Lives where your code already lives. Free. Some dynamic elements with GitHub Actions.

Cons: Still needs manual editing when you want to change the narrative. Limited layout options. Recruiters who aren't technical may not find it or know how to read it. No custom domain, no analytics, no way to know if anyone actually looked at it.

Best for: Developers whose audience is primarily other developers who are already on GitHub.

3. Builder Platforms (Notion, Polywork, Read.cv, etc.)

These give you a nice-looking page fast. Some have integrations. Most are drag-and-drop or form-based.

Pros: Quick to set up. Look polished without writing CSS. Social features on some platforms.

Cons: Your portfolio doesn't reflect your actual coding activity. You still have to log in and manually add projects, update skills, change descriptions. Many are generic and not really built for developers specifically. Some lock features behind paywalls that feel steep for what you get.

Best for: People who want something live today and don't mind periodic manual maintenance.

4. Auto-Synced Portfolio (GitHub as Source of Truth)

This is the approach I ended up building getfolio.dev around, so I'll be transparent about my bias. The idea: your portfolio pulls live data from your GitHub profile. Contribution graphs, repo stats, language breakdowns, stars. When you push code, your portfolio reflects it without you doing anything.

Pros: Zero maintenance once set up. Your portfolio is always accurate because it mirrors real activity. Themes designed specifically for developer work. Custom domains, privacy-first analytics, blog sync from DEV.to or Hashnode. Setup takes about 60 seconds.

Cons: You're trusting a third party with your portfolio's uptime. If your GitHub activity has gaps (contract work in private repos, for instance), your portfolio might look sparse in ways that don't represent you fairly. Less visual customization than building from scratch. You're trading control for convenience.

Best for: Developers who want an accurate, maintained portfolio without adding "update portfolio" to their task list ever again.

What I Actually Recommend

There's no single right answer. I've seen devs do well with a beautiful hand-built site they actually keep fresh. A GitHub README can be surprisingly effective if your audience knows where to look.

But for most working developers, the honest reality is that manual updates just don't happen. If your portfolio has been stale for 6+ months, the best approach is whichever one removes the friction that caused it to go stale in the first place.

That's why I built getfolio around GitHub sync. Not because the other approaches are bad, but because I kept watching the same pattern repeat across dev communities. Great portfolio goes live, gets attention for a week, then slowly becomes a fossil.

Pick the approach that matches your actual behavior, not your aspirational behavior.

Originally published on getfolio.dev.