Indie Hacker Portfolio: One Page for All Your Projects

If you have shipped more than two side projects, you have probably felt this: each one has its own site, its own X account maybe, its own domain, and there is no single place that shows the whole picture. An indie hacker portfolio fixes that. It is one page that lists everything you have built, what state each thing is in, and how to reach you.

This post covers what makes a good side project portfolio, how to structure it, and a few traps to avoid.

Why indie hackers need a portfolio at all

A developer portfolio is usually aimed at employers. An indie hacker portfolio has a broader audience:

• Users of one product who might like another one of yours
• Other makers deciding whether to collaborate with you
• Buyers browsing for small products to acquire
• Podcasts, newsletters and directories that want to feature you

What they all want is a quick read on your track record. Not your stack, not your CV. What you made and how it went.

What to include for each project

Keep every entry consistent. For each project:

• Name and logo. A favicon is fine if you do not have a logo.
• One-line description. What it does and for whom. "Invoice tool for freelance translators" beats "AI-powered productivity platform".
• Status. Active, Building, Acquired, On hold or Discontinued.
• Link. To the live product, or to an archive or write-up if it is gone.
• Tags. A few words like "SaaS", "Chrome extension", "open source" help people scan.
• Revenue, optionally. If you share it, prefer a verified number over a typed one.

That is it. Resist the urge to add a paragraph to every project. The page should scan in under a minute.

Writing one-line descriptions

The description is where most portfolios go wrong. A few rules of thumb:

• Lead with the user, not the tech. "Booking page for dog groomers" beats "Next.js scheduling app".
• Be specific. "Track invoices" is vague. "Chase late invoices by email automatically" is clear.
• Cut adjectives. "Simple", "powerful" and "modern" tell the reader nothing.
• Fit it on one line on a phone. Around ten words is a good target.

If a project is discontinued, change the description to the past tense and add a short reason: "Browser extension for saving recipes. Shut down after a year: people installed it but rarely used it." It turns a dead link into a useful story.

Tags do the rest. Two or three tags per project (for example "SaaS", "open source", "hardware") let a visitor scan for the kind of thing they care about without reading every line.

How to order your projects

Order matters more than design. A good default:

1. Featured project first. The one you most want people to look at, shown larger.
2. Other active projects, highest traction first.
3. Projects you are building, so people can follow along.
4. Acquired projects, which are a strong signal and deserve visibility.
5. On hold and discontinued, at the bottom, kept for the record.

Some makers prefer to group by type instead (apps, tools, open source). That works too, but status-first ordering answers the question visitors care about most: what is alive right now?

Include the failures

It is tempting to show only winners. Do not. An indie hacker portfolio with five discontinued projects and one success tells a better story than a single success with no history. It shows you ship, learn and keep going. If you want more on that, read building in public: sharing revenue and failures.

If a project is truly embarrassing, you can hide it. But "small and unprofitable" is not embarrassing. It is normal.

Where to host it

You have a few options, each with trade-offs:

• Your own site. Full control, but it is another project to maintain, and portfolio pages on personal sites tend to go stale.
• A GitHub profile README. Great for open source, less good for products with revenue or non-developer audiences.
• A generic link-in-bio tool. Quick, but most are built for creators and show a flat list of buttons with no status or revenue.
• A maker-specific page. Built around projects, status and revenue. Less flexible than your own site, much less work.

Whatever you choose, make sure the URL is short enough to put in every bio you have. If you want a custom domain on it, we cover subdomain and root domain setups in custom domain for your link in bio.

Keep it up to date

The biggest failure mode for any portfolio is going stale. A few habits help:

• Update status on the day it changes. Launched? Mark it Active. Shut down? Mark it Discontinued.
• Automate what you can. Revenue pulled from Stripe or Shopify updates itself. Favicons can be fetched automatically.
• Review monthly. Five minutes, once a month, is enough.

Measure what people click

If your portfolio has click stats, look at them. You may find that people click the project you have nearly forgotten about more than the one you are pushing. That is useful information about what to build next, or at least what to describe better.

An indie hacker portfolio on makerhandle

makerhandle gives you a page at makerhandle.com/yourname with all of the above: projects with status, tags, logos (auto-fetched if you do not upload one), featured cards, optional verified revenue and click stats per project. Free covers five projects; Pro is $20 a year for unlimited projects and a custom domain. See makerhandle for indie hackers or developers, or claim your handle.