DEV Community: Sébastien Doom

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.