DEV Community: Sébastien Doom

A Recruiter Googled My Name and Found a Portfolio I Forgot Existed

Sébastien Doom — Thu, 07 May 2026 11:28:39 +0000

The Portfolio That Wasn't Mine Anymore

A few months ago, a developer posted something in a Discord I'm in that stuck with me. He'd just wrapped a technical interview. It went well. The hiring manager mentioned she'd looked at his portfolio beforehand.

The problem: his portfolio still listed jQuery and Bootstrap as core skills. His last "featured project" was a to-do app from a bootcamp. Meanwhile, his GitHub was full of Go microservices, Terraform configs, and contributions to two open-source CLI tools.

He didn't get the role. The manager later told him she'd had concerns about his experience level based on what she saw online. His GitHub told one story. His portfolio told another. She saw the portfolio first.

The Gap Between What You Build and What People See

This is more common than most developers realize. Your GitHub profile is a living, timestamped record of your actual work. Every commit, every language breakdown, every contribution graph. It updates every time you push code.

Your portfolio, if you built it manually, reflects whoever you were the last time you had a free Saturday to update it. For most people that was six months ago. Maybe longer.

Recruiters and hiring managers Google candidates. They land on whatever comes up first. If your portfolio is what they find, and it's frozen in time, it becomes the lens through which they evaluate you.

Your GitHub doesn't lie. But it also doesn't present itself well on its own. The profile page wasn't designed to be a professional portfolio. It's a development tool.

What a GitHub-Synced Portfolio Actually Looks Like

The concept is simple: take the data GitHub already has about you and present it the way a portfolio should.

That means pulling in your real language distribution, not a manually typed skills list. Showing your actual contribution activity, not a static screenshot. Listing repos with their real star counts and descriptions, sorted by relevance.

With getfolio.dev, this sync happens automatically. You connect your GitHub, pick a theme, and the portfolio stays current without you touching it. New repo? It shows up. Language ratios shift because you've been writing more TypeScript than Python lately? The portfolio reflects that.

There are five themes (Terminal, DarkPro, Minimal, Glass, Editorial) and you can rearrange sections with drag-and-drop. But the core value is the sync. Your portfolio becomes a real-time reflection of your GitHub activity, not a snapshot you manually maintain.

Before and After, Practically Speaking

A manually built portfolio for a typical mid-level developer might show:

A skills section listing "React, Node.js, MongoDB" because that's what they knew two years ago
Three or four hand-picked projects with screenshots that may or may not still deploy
A contribution graph that's either missing or a static image from some past date
No analytics, so zero visibility into whether anyone actually visits

A GitHub-synced portfolio for the same developer would show:

Real language breakdown across all repos (maybe now it's 43% TypeScript, 28% Python, 15% Go)
Repos sorted by recent activity or stars, with live descriptions
A contribution graph that updates daily
Privacy-first analytics showing which pages recruiters actually view

The second version requires no maintenance. That's the point. Not that it looks fancier, but that it stays true.

Your GitHub Activity Is Already Your Best Portfolio Content

Developers often think they need to "create portfolio content." Write case studies. Design project cards. Record demo videos. And sure, that stuff helps. But most of the content already exists in your GitHub account.

Your commit history shows consistency. Your language stats show range (or focus, both valuable). Your starred repos hint at what you care about. Your open-source contributions prove you can work with other people's code.

All of that is sitting there, updating itself every time you work. The only missing piece is presentation.

Custom Domains and The Google Problem

One detail worth mentioning: when a recruiter Googles your name, what ranks? If your portfolio lives on a generic subdomain, it's competing with LinkedIn, social profiles, maybe some random forum posts.

A portfolio on yourname.dev or yourname.io with proper meta tags and clean structure tends to rank well. getfolio.dev supports custom domains on the Pro plan, and the generated pages are statically optimized, which helps with search visibility.

This matters because the developer from that Discord story? If his current, synced portfolio had outranked his old one, the conversation with that hiring manager would have gone differently.

Getting Started Takes About 60 Seconds

Connect GitHub. Pick a theme. Publish. The free plan covers the basics. Pro adds custom domains, analytics, and blog sync from DEV.to or Hashnode.

Your GitHub is already doing the work. Let it speak for you.

Originally published on getfolio.dev.

4 Ways to Keep a Developer Portfolio Current (Compared Honestly)

Sébastien Doom — Wed, 29 Apr 2026 16:24:17 +0000

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.

I Rebuilt My Portfolio's Backend Three Times Before Landing on This Stack

Sébastien Doom — Wed, 08 Apr 2026 10:00:00 +0000

The first version used a cron job. Every six hours, it would hit the GitHub API, pull repo data, and write it to a JSON file that got committed back to the repo. It worked for about a week.

Then I hit GitHub's rate limit. Then the cron silently failed for three days and nobody noticed. Then I realized the JSON file had grown to 4MB because I was storing every commit message for every repo.

I was building getfolio.dev, a service that generates developer portfolios synced live with GitHub. The whole point was that your portfolio would never go stale. Which meant the data layer couldn't be fragile. It had to actually work at scale, for hundreds of users, without me babysitting a cron tab.

So I rewrote it. And then I rewrote it again.

Version 1: Static JSON + GitHub Actions

The appeal was simplicity. GitHub Actions triggers on a schedule, fetches API data, commits a JSON file, Vercel rebuilds. Zero infrastructure.

Problems showed up fast. Rate limiting was the obvious one. But the deeper issue was latency. A user signs up, connects their GitHub, and then waits up to six hours to see their repos populate. That's not a product. That's a broken promise.

Version 2: Serverless Functions + Direct API Calls

Next attempt: call GitHub's API on every page load through a Next.js API route. Fresh data every time.

This solved the staleness problem and created a new one. GitHub's REST API isn't slow exactly, but when you're fetching repos, languages, contribution data, and pinned items, you're looking at 4-5 sequential requests. Page loads went from 200ms to 2+ seconds. Some users had 80+ repos. That made it worse.

I tried parallelizing the requests with Promise.all. Got it down to about 900ms on a good day. Still too slow for a portfolio that someone might bounce from in under three seconds.

Version 3: Firebase + Smart Caching (What Actually Shipped)

The solution that stuck uses Firebase as a caching and sync layer between GitHub and the portfolio.

When a user connects their account, we do a full initial fetch and store the processed data in Firestore. After that, we use a combination of webhooks (when available) and intelligent polling to keep things current. The polling interval adapts. If you pushed code today, we check more frequently. If your last commit was three weeks ago, we back off.

Page loads hit Firestore, not GitHub. Response times dropped back to ~150ms.

The schema looks roughly like this:

users/
  {uid}/
    github_profile: { ... }
    repos/
      {repo_id}: {
        name, description, stars, forks,
        languages: { TypeScript: 14500, CSS: 3200 },
        last_pushed: timestamp,
        pinned: boolean
      }
    sync_meta: {
      last_full_sync: timestamp,
      next_scheduled: timestamp,
      poll_interval_minutes: 60
    }

The adaptive polling was the part that took the longest to get right. Too aggressive and you burn through API quota across all users. Too passive and someone pushes a cool project and their portfolio doesn't reflect it for a day.

Current logic: base interval of 360 minutes. If last_pushed is within 24 hours, drop to 60 minutes. Within the last hour, drop to 15. It's simple and it works.

The Rest of the Stack

For anyone curious about the full picture:

Next.js 14 App Router for the portfolio rendering and the dashboard. Server components handle the data-heavy portfolio pages. Client components for the drag-drop editor and theme preview.
Tailwind + Framer Motion for styling and animations across the five themes (DarkPro, Terminal, Minimal, Glass, Editorial). Each theme is a separate component tree, not a CSS swap.
Stripe for billing. Pro plan unlocks custom domains and analytics.
Vercel for hosting. Edge functions for the custom domain resolution.

What I'd Do Differently

I'd skip version 1 and 2 entirely and start with the caching layer. The instinct to keep things simple by avoiding a database was wrong. The database is what made it simple. Without it, I was fighting the GitHub API's constraints on every request.

If you're building anything that depends on a third-party API as a primary data source, put a cache in front of it from day one. Not as an optimization. As architecture.

Getfolio launches soon. The early version is live at getfolio.dev if you want to see how your GitHub data looks across different themes.

What's a technical decision in your projects that you got wrong twice before finding the right approach? Curious what other people's version 1 → version 3 journeys looked like 🛠️

Originally published on getfolio.dev.

How to Build a Developer Portfolio That Updates Itself From Your GitHub Profile

Sébastien Doom — Wed, 01 Apr 2026 10:00:00 +0000

Your GitHub profile already tells a detailed story about you as a developer. The languages you use most, the repos you've contributed to recently, your commit frequency, the projects you've starred. All of it is there, structured and current.

The weird part is that most developer portfolios ignore all of this. They're static sites that repeat a fraction of what GitHub already knows, manually maintained, and quietly drifting out of date.

What if your portfolio just read from GitHub directly and kept itself current?

That's what this article walks through. The end result: a live portfolio that reflects your actual GitHub activity without you touching it after setup.

What "GitHub as Identity" Actually Means in Practice

Recruiters and hiring managers already look at your GitHub. A 2023 Stack Overflow survey showed that 85% of developers have a GitHub account, and many hiring processes include a profile review before or during interviews.

But GitHub's native profile page wasn't designed to sell you. It's a project management interface. There's no hierarchy telling a visitor "look at this project first" or "these are the languages I'm strongest in." And there's no way to add context like blog posts, contact info, or a personal statement alongside the code.

A portfolio that pulls from GitHub fills that gap. It takes the raw signal (repos, languages, contribution graphs, star counts) and presents it in a format that's designed for humans evaluating you. Not other developers browsing code.

Step 1: Decide What Data Should Be Live vs. Curated

Not everything from GitHub belongs on your portfolio. You probably want:

Live data: contribution graph, top languages by usage, star counts, recent activity
Curated: which repos to feature, what order they appear in, project descriptions rewritten for a non-technical audience

The live stuff keeps your portfolio feeling current. The curated stuff gives you editorial control. A good portfolio setup handles both.

Step 2: Connect GitHub and Generate the Base

You can build this yourself with the GitHub API, a static site generator, and a cron job. That works. It's also a side project you'll maintain for approximately two weekends before it joins the graveyard.

The faster path is a tool built specifically for this. Getfolio connects to your GitHub account, pulls your repos, languages, contribution data, and stars, then generates a portfolio from it in about 60 seconds. You pick a theme (there are 5, ranging from a terminal aesthetic to a clean editorial layout), and the data stays synced automatically going forward.

No cron jobs. No rebuilds. Push a commit to a featured repo on Tuesday, and your portfolio reflects it on Tuesday.

Step 3: Add the Stuff GitHub Doesn't Have

GitHub knows your code. It doesn't know your blog posts, your preferred contact method, or the two-sentence summary of why you built that CLI tool.

Getfolio has a drag-and-drop editor for arranging sections, and it syncs blog posts from DEV.to and Hashnode if you write on either platform. So the portfolio becomes a single page that combines your code activity with your writing and your contact info. All of it updating without manual intervention.

You can also connect a custom domain on the Pro plan, which matters more than people think. yourname.dev in a recruiter's browser tab reads differently than a subdomain on someone else's platform.

Step 4: Set It and Check Back Monthly

The whole point of a GitHub-synced portfolio is that you stop maintaining it as a separate project. Your real work updates it.

That said, it's worth checking in once a month to reorder featured repos if your focus has shifted, or to add a new blog post section. Five minutes, not five hours.

What This Looks Like Over Time

After 3 months of normal development work, a synced portfolio will show:

Updated language percentages as you pick up new tools
Fresh contribution activity proving you're actively building
New repos appearing automatically
Recent blog posts pulled in without copy-pasting

Compare that to a static portfolio from 3 months ago, which looks exactly like it did the day you deployed it. That delta is visible to anyone reviewing candidates.

The least interesting thing about your portfolio should be maintaining it. If your GitHub already represents what you build, let it do the heavy lifting.

You can try it free at getfolio.dev 🛠️

Your Portfolio Says React 16 But Your GitHub Says Next.js 14

Sébastien Doom — Wed, 25 Mar 2026 16:00:00 +0000

The tech stack credibility gap

Here's something that happens more often than anyone admits: a developer lists "React, Node.js, Express, MongoDB" on their portfolio because that's what they knew when they built it. Meanwhile, their actual GitHub activity from the last six months tells a completely different story — Next.js App Router, tRPC, Drizzle ORM, maybe some Rust creeping in on the side.

The portfolio becomes a fossil record of who you were, not who you are.

And the awkward part? Recruiters and hiring managers actually look at this stuff. They compare what you claim against what they can find. When your portfolio says one thing and your recent commits say another, it doesn't read as "oh, they just forgot to update it." It reads as inconsistency.

Why tech stack sections rot so fast

Developers pick up new tools constantly. That's literally the job. But updating a portfolio is a manual, disconnected process:

You learn TypeScript deeply over three months of real project work, but your portfolio still says "JavaScript" because you built the site before the switch
You move from REST to GraphQL to tRPC, but the skills grid hasn't changed since you copy-pasted it from a template
Your most-used language on GitHub shifted from JavaScript to TypeScript eight months ago, and your portfolio has no idea

The data already exists. GitHub tracks your languages by repo, by percentage, by recent activity. The contribution graph shows when and how much you code. Stars and forks signal which projects resonated with other developers.

None of that makes it to your portfolio unless you manually go update it. Which means it almost never happens.

What an honest tech stack section would actually show

Imagine your portfolio's tech stack section worked like your GitHub language breakdown — automatically weighted by actual usage, updated every time you push code. Not a self-reported list of logos you picked from a grid, but a real reflection of what you've been building with.

That's the core idea behind Getfolio. It pulls your GitHub data — languages, repos, contribution activity, stars — and keeps your portfolio in sync automatically. Your tech stack section reflects your actual recent work, not a snapshot from whenever you last had the energy to edit HTML.

Setup takes about 60 seconds. Connect GitHub, pick a theme, and your portfolio stays current from that point forward.

The real cost of an outdated tech stack section

This isn't just about aesthetics. Consider what happens in practice:

You undersell yourself. You've been writing TypeScript for a year, but your portfolio doesn't mention it. A recruiter searching for TypeScript developers never finds you.

You invite skepticism. A hiring manager sees "Node.js, Express" on your portfolio but your pinned repos are all Bun and Hono. Now they're wondering what else is inaccurate.

You miss the specificity that matters. Saying "React" is almost meaningless in 2024. Are you writing RSCs? Using Server Actions? Still on Create React App? Your GitHub knows. Your portfolio should too.

The low-effort fix

The developers who look most credible online aren't necessarily the best engineers. They're the ones whose public presence accurately reflects their current work. That's it.

The gap between "what I actually know" and "what my portfolio says I know" shouldn't require a weekend project to close. If your code is already on GitHub, the data is already there — it just needs to show up where people are actually evaluating you.

Five themes are available (including a Terminal theme that feels right for the DEV.to crowd 🖥️), plus custom domains and a drag-drop editor on the Pro plan. But honestly, the part that matters most is the sync. Update your portfolio by doing what you already do: writing code and pushing it.

Originally published on getfolio.dev.

Your GitHub is Your Portfolio — But It's Hard to Share

Sébastien Doom — Wed, 18 Mar 2026 15:59:32 +0000

Your GitHub profile is the most honest thing about you as a developer.

It's not a resume with buzzwords. It's not a cover letter optimized for HR keywords. It's code you actually wrote, decisions you made, problems you solved. The commit history, the languages you reach for, the projects you care enough to maintain — that's real.

And yet most developers still treat their portfolio like a separate project they'll "get to eventually."

The Problem With Portfolios

Here's what usually happens:

You build a portfolio site. Maybe it's a Next.js template, maybe you hand-code something beautiful. It takes a weekend.
You add your best projects. You write descriptions. You pick your favorite screenshot.
You deploy it. It's live. You feel good.
Three weeks later, you ship a new project on GitHub. Your portfolio is now out of date.
Six months pass. Your portfolio shows projects you don't maintain anymore. Your most interesting recent work isn't there. Anyone who looks at it sees a frozen snapshot from last spring.

Meanwhile, your actual GitHub profile keeps evolving. You're shipping things. You're learning new tech. You're contributing. But none of that automatically makes it to your portfolio.

So you end up choosing: keep the portfolio in sync (which means rebuilding it every time something changes), or let it become stale (which is what most developers do).

There's a third option, though.

What If Your Portfolio Stayed in Sync Automatically?

The boring fact is: you already have the data. GitHub knows what you've built. It knows your languages, your most-starred projects, the repos you care about, the ones that are active vs. dormant. It knows the graph of what you've actually done.

What if a portfolio didn't require separate maintenance? What if it lived off your GitHub data, updating automatically as you push code?

That changes the equation. Your portfolio becomes a window into what you actually build — not what you built once and froze in time.

Getfolio will do that. You connect your GitHub, pick a theme, optionally customize it, and your portfolio syncs live with your activity. Your top languages update. Your repo list updates. Your contribution graph is always current. You can add a blog if you want, or link one from DEV.to or Hashnode. You get a custom domain if you need it. But the portfolio itself — the signal, the proof of what you build — that's always live.

It's not about removing the work from your portfolio. It's about removing the wrong work: the busywork of keeping a separate site in sync, the anxiety about it being outdated, the pressure to make it "perfect."

Why This Matters

When someone lands on your portfolio, they should see you. Not a best-of reel from 2023. Not a polished version of you. You.

GitHub is honest because it's where you actually work. A portfolio that pulls from GitHub is honest too.

The setup takes about a minute. You can use the free plan right now if you want to try it. The idea is simple: show what you actually build, and let your portfolio prove it.