I have 47 repositories on GitHub. Maybe 12 of them are real projects. The rest are forks I never touched, tutorials I followed once, and abandoned experiments from 3am coding sessions.
If someone landed on my GitHub profile tomorrow, they'd see a wall of green squares and a list of repo names that mean nothing without context. They wouldn't know which projects make money. They wouldn't know which ones have users. They wouldn't know what problems I solve or what kind of developer I am.
That's the problem with treating GitHub as your portfolio. It's a code hosting platform, not a showcase. And the difference matters more than most developers realize.
What GitHub actually shows (and what it doesn't)
GitHub does one thing well: it proves you write code. Contribution graphs, commit history, pull request activity. If someone wants to verify that you're an active developer, GitHub does the job.
But here's what GitHub can't tell anyone:
What the project actually does. A repo named invoice-gen could be anything. A weekend experiment? A SaaS with paying customers? A code-along from a YouTube tutorial? Without context, nobody knows.
Who uses it. Star counts are vanity metrics. Forks are slightly better but still say nothing about whether real people depend on your work. GitHub doesn't surface revenue, user counts, or traction.
Your actual skills. A recruiter looking at your GitHub sees languages and frameworks. They don't see your ability to ship complete products, design interfaces, handle payments, or build things people want to pay for.
Your story. Why did you build this? What did you learn? What would you do differently? GitHub README files can cover some of this, but most developers leave them blank or write the minimum.
I realized this when I started building in public. I'd tweet about a product I shipped, someone would ask to see my other work, and I'd send them to GitHub. The response was always the same: confusion. "Which one should I look at?" "What does this one do?"
That's when I understood that a developer portfolio isn't about showing code. It's about showing what you've built and why it matters.
The portfolio problem nobody talks about
Most developer portfolio advice boils down to: buy a domain, pick a template, list your projects with screenshots.
Fine. That works for getting a basic page online. But it misses two things that actually move the needle for developers who want visibility.
Problem 1: Nobody finds your portfolio.
A static HTML page on yourname.dev is invisible unless you actively drive traffic to it. Google doesn't care about your single-page portfolio. Neither does anyone else. You put in the work to build it, and then it sits there generating zero impressions.
This is where most portfolio advice fails. It tells you to build but not how to be found.
Problem 2: Your portfolio doesn't prove anything.
Screenshots and project descriptions are easy to fake. Anyone can write "built a SaaS that generates $5k/month" on their portfolio. Without verification, it's just a claim.
The developers I respect most are the ones who back their work with numbers. Revenue, user counts, traffic, growth. If you say you built something meaningful, show the receipts.
This is especially true in the indie hacker world. Building in public has created this culture of transparency where showing real metrics is the norm. A portfolio that just lists projects without any proof feels dated compared to one that shows verified revenue and analytics.
What a good developer portfolio actually needs
After looking at hundreds of developer portfolios (and building a few myself), I've landed on what separates the ones that work from the ones that don't.
1. Projects with context, not just titles.
Each project on your portfolio needs to answer three questions: What does it do? Who is it for? What's the result? A project card that says "Invoice Generator" means nothing. A card that says "Automated invoice tool for freelancers, 200+ active users, $800/mo MRR" tells a story.
The context is what makes people stop scrolling.
2. Proof of traction.
Revenue charts. Analytics dashboards. Download counts. User testimonials. Anything that shows your project exists in the real world, not just on your hard drive.
I know not every project has revenue. Side projects, open source contributions, and learning experiments are all valid. But if you have metrics, show them. It separates builders from dreamers.
3. SEO value.
This is the one most developers overlook completely. Your portfolio should work for you even when you're not actively sharing it. That means it needs to be indexable, linkable, and ideally hosted on a domain with some authority.
When someone Googles your name or your project name, your portfolio should appear. If all they find is a LinkedIn profile and a GitHub link, you're leaving visibility on the table.
4. A single link that works everywhere.
LinkedIn bio. Twitter profile. Email signature. Conference speaker page. You need one URL that represents everything you do. Not a GitHub link, not a personal website that's been "under construction" since 2023.
One clean link. All your projects. Always up to date.
5. Low maintenance.
Here's the thing nobody tells you: most developer portfolios are abandoned within six months. The developer builds it, adds their current projects, and then never updates it again. Three years later, it lists technologies they don't use anymore and projects they've shut down.
A portfolio only works if keeping it current takes minimal effort. If updating it requires editing HTML, rebuilding, and redeploying, you'll stop doing it. It needs to be as easy as updating a Notion page.
The SEO angle nobody talks about
Domain authority matters for developers too, not just businesses.
Every time you list a project on your portfolio, that project gets a backlink from whatever domain your portfolio lives on. If that domain has decent authority (say, DR 20+), those backlinks pass real SEO value to your projects.
This is why where you host your portfolio matters. A subdomain of a high-authority platform gives your projects free link juice. A brand new domain with DR 0 gives them nothing.
I didn't think about this when I built my first portfolio. I just grabbed a .dev domain and threw up a template. It looked fine, but it wasn't doing anything for my projects' search rankings. The portfolio existed in a vacuum.
When I started paying attention to backlinks and domain authority across my 12 web properties, I realized the same logic applies to personal portfolios. The platform your portfolio lives on can either help your projects rank or not. Most developers choose "not" by default because they don't know this is a factor.
Platform options (what I've tried and what I think)
There are a few ways to build a developer portfolio today. Each has tradeoffs.
Self-hosted (your own domain + code): Maximum control. You can build anything you want. But you start with DR 0, which means zero SEO benefit. You also need to maintain it yourself. CSS breaks, dependencies update, hosting bills arrive. I've done this twice and abandoned both times.
Link-in-bio tools (Linktree, Bento): Quick to set up, but these are glorified link lists. No project details, no analytics worth mentioning, and Bento is shutting down in February 2026. They're designed for creators, not developers.
General portfolio platforms: Some look nice but charge monthly subscriptions for basic features. The $10-15/month adds up for something you might not update often.
Developer-specific platforms: This is the category that makes the most sense for builders. Platforms designed specifically for developers who want to showcase projects, track metrics, and get SEO benefits.
I ended up building VibeCoders because nothing in the market combined the three things I cared about: project showcasing, real analytics, and dofollow backlinks from a DR 26 domain. The closest competitor was IndiePage, but it didn't offer backlinks and the pricing was subscription-based.
What surprised me is how much the backlink angle mattered to other developers. When I launched VibeCoders, the feature people asked about most wasn't the themes or the analytics dashboard. It was the dofollow backlinks. Developers who run their own SaaS products understood immediately that getting a DR 26 backlink for every project they list is free SEO work they don't have to do themselves.
How to set up your portfolio (the actual process)
Whether you use a platform or build your own, here's the process I recommend:
Step 1: Pick your top 5-8 projects.
Not everything you've ever built. Your best work. Projects that are live, have users, or demonstrate skills you want to be known for. Quality over quantity. A portfolio with 5 strong projects beats one with 25 half-finished experiments.
If you have fewer than 5 projects, that's fine. Three solid ones with context and metrics will outperform fifteen with just titles and GitHub links.
Step 2: Write a one-liner for each project.
Not a paragraph. One sentence. "Automated backlink submission tool for SaaS founders." "AI habit coach that replaced my morning routine." "Open-source CLI for managing App Store Connect pricing."
Force yourself to explain the project in one sentence. If you can't, the project either does too much or you haven't figured out how to position it yet.
Step 3: Add metrics wherever possible.
Revenue, users, downloads, stars, anything. If a project makes money, show it. If it has users, quantify them. If it's open source with stars, include the count.
No metrics yet? That's okay. "Launched last week" is a valid status. "In development" is fine too. Just be honest about where each project stands.
Step 4: Include your tech stack.
Not for show. For searchability. When someone is looking for "developer who knows Next.js and Supabase," you want your portfolio to surface. Tech stack labels make your projects searchable and give visitors a quick read on your expertise.
Step 5: Add links that matter.
Live product URL. GitHub repo (if open source). Demo video if you have one. Each link should take someone deeper into the project, not to a dead end.
Step 6: Keep it current.
The best portfolios I've seen are the ones where developers update their projects monthly. New revenue numbers, new features, new launches. It takes ten minutes and keeps the portfolio alive.
Revenue tracking changes everything
This is a small feature that makes a big difference: showing real revenue on your projects.
In the indie hacker community, revenue is the ultimate social proof. It's one thing to say "I built a SaaS." It's another to show "$2,400/month MRR" next to it with a verified Stripe integration.
When I see a developer portfolio with revenue numbers, I immediately take them more seriously. It proves they didn't just build something. They built something people pay for. That distinction matters whether you're looking for collaborators, investors, job opportunities, or just credibility.
The leaderboard aspect is interesting too. On VibeCoders, there's a revenue-based leaderboard where developers compete based on their verified earnings. It creates this dynamic where people are motivated to update their metrics because they want to climb the rankings. I didn't expect the gamification angle to work as well as it did, but builders are competitive by nature.
The mistake I keep seeing
The biggest mistake developers make with portfolios is treating them as a one-time project instead of a living document.
You build it once, add your current projects, and forget about it. Six months later, your "latest project" is a product you've already shut down and your "current stack" is three frameworks behind.
A stale portfolio is worse than no portfolio. It signals that you're not actively building.
The fix is simple: choose a format that's easy to update. If adding a new project takes more than two minutes, you won't do it. If you have to redeploy your site every time you update a number, you won't do it. Pick a platform or build a system where updating is trivially easy.
Does it actually matter?
I used to think portfolios were vanity projects. Something you build once for fun and never look at again.
Then I started getting DMs from people who found my profile through search. Not through Twitter, not through GitHub. Through Google. They searched for something related to a project I built, landed on my portfolio, and reached out.
That changed my perspective. A portfolio isn't just a business card. It's a passive discovery channel. When it's set up right, with proper SEO, good content, and regular updates, it works while you sleep.
The developers who take their portfolios seriously tend to be the ones who take their careers seriously too. Correlation, maybe. But I think there's causation there. When you force yourself to articulate what you've built and why, you get clearer about what you want to build next.
If you're a developer building things, whether side projects, SaaS products, or open source tools, you should have a portfolio that does more than list your GitHub repos. You should have something that tells your story, proves your work, and helps people find you.
That's the whole pitch. Build a real portfolio. Keep it updated. Make sure it's doing something for you beyond looking nice.
I'm building in public as a solo founder running 14+ web properties. Follow me on X/Twitter for daily updates on what's working, what's failing, and what I'm learning along the way.