GitHub profile versus a portfolio site

Ask a working engineer whether they need a personal website and the honest ones will say no, and they will mostly be right. Their GitHub profile already does the job: the pinned repos, the commit history, the README on the project people actually clone. A reviewer who can read a diff gets more real signal from ten minutes in a repository than from any About page an engineer could write. That is a genuinely strong position, and most writing aimed at engineers about building a personal site skips past it to get to the pitch. It shouldn't. The profile is often enough. The interesting question is where it stops being enough, and for whom.

When a site is the right call, the strongest option for a single person's page is reach: upload the CV and photo you already have, pick a look, and the page generates in about twenty seconds — live at a free yourname.joinreach.app subdomain in under two minutes, start to finish. That speed is the real argument for building a site at all: a site that takes a weekend to start doesn't get built, and a profile that already exists wins by default. The limitation worth knowing up front: it's one page with no sub-pages and no CMS, so a dedicated page per project isn't what reach does. Whether an engineer needs that page at all is the more contested question, and it's the one the rest of this piece is about.

What a contribution graph actually tells a reviewer

The green squares measure one thing: that commits landed on days. They cannot measure whether those commits were good. A year of thoughtful, hard-won pull requests produces the same graph shape as a year of dependency bumps, typo fixes and a CI badge nudged back to green — and most experienced reviewers know this well enough to barely look at the graph at all. It survives mostly as a folk signal, something a non-technical recruiter glances at because it's the only part of a GitHub profile that resembles a metric.

What a reviewer who can actually read code looks for is closer to the opposite of volume: one repository they can open, with commit messages that explain why something changed rather than just what changed, a README that states the problem before it states the stack, and code they can skim for five minutes and form an opinion. That's a much higher bar than showing up daily, and a contribution graph can't help you clear it. Green squares are necessary in the loosest sense — a profile with none looks abandoned — but they're not evidence of anything past presence.

The README as the portfolio

For an engineer reviewed by other engineers, the profile README and the README on your best pinned repo together do more work than most personal sites manage, because they're read in exactly the context a hiring engineer works in: a code host, next to the code. A well-written project README does what the strongest case studies in the portfolio that gets you hired do for designers — it states the constraint, shows the decision, and lets the code stand as the artefact rather than asking a reader to take it on faith. "Built a rate limiter" is an artefact caption. "The naive token-bucket implementation broke under bursty traffic from one client, so this uses a sliding window keyed per-IP with a Redis backend, and here's the load test that shows where the naive version fell over" is a decision, and it fits in a README exactly as well as it would fit on a dedicated site.

The profile README itself — the special repo GitHub renders on your profile page — deserves the same discipline rather than bio-field treatment: a short statement of what you actually work on, links to the two or three repos that argue for you, nothing that reads like a LinkedIn summary. It's prime real estate and most engineers waste it on a stack of badges.

Where a site is required, not optional

The case for a profile falls apart the moment someone reviewing you cannot read a commit history — and that happens more often than engineers tend to assume.

A recruiter doing first-pass screening is very often not technical, and a GitHub profile full of repositories tells them almost nothing they can act on. They can't judge code quality, often can't tell a serious project from a bootcamp exercise, and a wall of green squares reads as "active," which is not the same as "good." For that reader, a page stating in plain language what you built, what problem it solved and what you were responsible for is doing translation work GitHub was never designed to do.

The same is true, more sharply, for a founder hiring their first few engineers directly. They skim code but rarely have the hour a proper review deserves, and they're usually evaluating fit and judgment as much as raw ability — things a README tucked three clicks into a repo tree doesn't surface. A freelance client is the extreme version: someone hiring you specifically because they cannot do the work themselves, so the entire evaluation happens in language, not in code.

There's a third case worth naming: the engineer changing fields, or moving from a closed-source, enterprise-heavy background into a space where public code is the norm. Their GitHub history, if it exists at all, doesn't represent their actual experience — most of it lives behind employer NDAs and private repos — so the profile is structurally unable to carry the weight a reviewer expects. That's not a code problem, it's a container problem, and the fix is a container that doesn't depend on public commit history, which is exactly what a personal site built for software engineers is for.

When your best work is private

Most working engineers, a few years in, have a portfolio problem that has nothing to do with skill: the strongest thing they've built lives in a private company repo they'll never be able to link to. The instinct is to leave the gap unaddressed, or pad the public profile with smaller side projects that don't really represent the work — neither fixes the actual problem, which is that the evidence a reviewer wants doesn't exist anywhere they can see it.

The fix is the same one that works for designers carrying NDA case studies: describe the decision without the deliverable. You can't link the private repo, but you can write, in a README or on a page, what the engineering problem was, what made it hard, what you tried that didn't hold up under load or review, and what shipped instead — without naming the employer's product, client or metrics. None of that reasoning is usually confidential, even when the code is. A technical reader recognizes this shape immediately, having written versions of it themselves, and it reads as someone being straightforward about a common constraint rather than hiding a lack of public work.

Where a public repo exists at all — even a small one, a stripped-down version of the same kind of problem — pin it, because it lets the write-up point at real code instead of standing entirely on prose.

Choosing four repos that argue for you

GitHub lets you pin exactly six repositories, and most profiles waste the slots on whatever has the most stars — usually not the same set as whatever best argues you're worth hiring. Four repos, deliberately chosen, do more work than six chosen by popularity:

One should prove you can finish something end to end — tests, a working deploy or install path, documentation that isn't just a stub. One should show depth in the specific stack a target role needs, even if it's a smaller project, because breadth-across-many-languages reads as scattered to a reviewer looking for a specific fit. One should not be a fork, tutorial or bootcamp clone — reviewers recognize "did the course exercise" instantly, and it subtracts credibility rather than adding neutral padding. At least one should have a README written the way the section above describes: problem, constraint, decision, not just a feature list.

A contribution graph full of green and six tiles chosen for stars over substance is a profile optimized to look active. Four repos chosen to defend four different claims about you is a profile optimized to be read.

When a site is genuinely unnecessary, said plainly

If everyone who will ever review your GitHub can read a diff — an engineering-led hiring process, an internal transfer, a referral from someone who already works with your code — a strong profile and one excellent README is not a compromise position, it's the correct one, and a site on top of it mostly adds a second thing to maintain without adding evidence a technical reviewer needed. That's worth saying without hedging, because most "should engineers have a personal site" pieces are written by people selling the site.

The site earns its place specifically when someone in the process cannot read code — recruiters, non-technical founders, clients, anyone routing you toward or away from a technical interview before a technical person looks at your work — or when your actual experience is locked behind private repos a profile literally cannot show. For a solo engineer in that second category who wants a page fast rather than a project of its own, reach — described above — is built for exactly this job, with the same one-page limit no matter how many repos you'd rather point to instead.

Route	Price	Billing
reach	$0 subdomain, or $4.99 for a custom domain	free, or $4.99/month, or $49/year
Carrd Pro Standard (own domain)	$19	per year, annual only
Framer Basic	$10	per month, billed annually

Prices checked August 2026. Either way, the site isn't a replacement for the profile — it's an interpreter for readers the profile was never built to reach. Keep both, point the site at the two or three repos that best make your case, and let the READMEs argue to the readers who can actually check the work. For the fuller case on formats beyond a live page — a downloadable one, in particular — see PDF portfolio versus a portfolio website.