A personal website for software engineers

There is a particular way software engineers waste a weekend on their personal site, and it is worth naming because almost every engineer reading this has done it or is about to. You decide the site needs rebuilding. Not because the content is wrong — because the framework is stale. You pick something newer, spend Saturday on the build pipeline, Sunday on getting the dark mode toggle to persist across a page reload, and by Sunday night you have a beautifully engineered site with the same three paragraphs of text it had a year ago, because the paragraphs were never the part that felt like work.

That is not laziness. It is closer to the opposite problem: the site gives you an interesting technical project to do instead of an uninteresting writing project, and given the choice, engineers reliably take the technical project. The trouble is that the person reading the site afterward is, more often than not, another engineer — a hiring manager, a teammate doing due diligence before a referral, someone on a panel deciding whether to bring you in for a call — and that reader is going to open your GitHub in the next browser tab within about the first thirty seconds. Your framework choice does not compete with anything they will see there. Your explanation of what you built does.

What another engineer checks first

Picture the actual sequence. Someone lands on your site from a resume or a referral. They skim the top for what you do and where. Then, almost immediately, they go looking for evidence, and for an engineer that evidence lives in three places: recent commits, one repository they can actually read, and whatever you say about a decision you made.

Recent commits matter more than people admit, because they answer a question nobody states directly: is this person still building, or is this a page from two jobs ago that never got updated. A contribution graph with real activity in the last few months reassures a reader in a way that no amount of prose can. Silence for a year reads as a signal even when it isn't one — maybe you were heads-down on private work, maybe you had a baby, maybe the job didn't leave room for side projects — but the reader doesn't get that context from an empty graph, so consider linking to something that stayed active even if it is small.

One readable repository beats ten abandoned ones. This is the part engineers get backwards most often: the project grid at the bottom of the site links to everything, on the theory that more surface area looks more productive. It does the opposite. A reader who clicks through three half-finished repos with no README and a last commit from two years ago updates their opinion of you downward, and they update it fast. Pick the one or two repositories that are actually in a state a stranger can understand in five minutes, and either delete the rest from the front page or fold them into a smaller "other things" section that nobody has to click.

The third check is the one your site can do something no repository can: explain a trade-off. Code shows what you built. It rarely shows what you chose not to build, or why you picked the boring database over the interesting one, or what broke in production and what you learned from the postmortem. A hiring engineer reading three sentences about a real decision — the constraint, the option you took, the option you didn't — learns more about how you think than they learn from another hundred lines of well-formatted code. This is also, not coincidentally, the exact kind of writing that a rebuilt framework does not produce on its own. It has to be written.

The rebuild-my-blog-in-a-new-framework trap

None of this is an argument against learning a new framework by building something with it. That is a legitimate and common way engineers pick up a stack, and a personal site is a reasonable target for the exercise — low stakes, real deployment, a finished thing at the end. The trap is not the practice. It is mistaking the practice for the deliverable.

The realistic cost of a full site rebuild, done properly, is measured in weeks rather than the evening it feels like it should take: picking the framework, wiring the build and deploy pipeline, porting the content, then rebuilding the two or three things the old site did that you forgot you relied on until they broke. Multiply that by however many times you have done this — most engineers with a personal site have rebuilt it three or four times over a career — and the honest total is months of work whose output, to the reader on the other end, is indistinguishable from the version before it. The three paragraphs about what you built still say the same thing. The dark mode toggle is not the reason anyone hired you.

If you want the practice, take it — just don't let the site be the reason your actual work goes three years without a sentence written about it. The fastest fix for most engineers' sites is not a rebuild at all. It's writing the three paragraphs the current, unremarkable site has never had.

Link the proof, don't rebuild it

The other habit worth breaking is duplicating instead of linking. Engineers who do write project descriptions often re-explain the whole thing from scratch on the site — architecture diagram, tech stack list, screenshots — when the actual repository already does that better, because it has the README, the commit history, and the code itself as evidence. Re-hosting that content on your site doubles the maintenance burden and gives you a worse version of something that already exists somewhere more credible.

The better split: your site frames, GitHub proves. A sentence or two of context — what the project was for, what was hard about it, what you'd change — followed by a direct link to the repository, does more work than a paragraph reconstructing what's already visible one click away. The same applies to a package you published to npm, PyPI or crates.io: link it, mention the download count only if it's genuinely notable, and don't paste in the API docs that already live on the package page. A conference talk works the same way — link the recording and the slides rather than transcribing the talk into a blog post nobody asked for. Your site's job is to be the index that tells a reader which of these things is worth their next click and why, not a mirror of content that already has a canonical home.

Writing about a system you cannot show

The harder version of this problem is the system that matters most to your career and that you are contractually unable to show anyone — the payments pipeline behind a corporate firewall, the internal tool that never shipped as open source, the infrastructure work that by definition has no public URL. Most engineers respond to this by leaving it off the site entirely, which quietly removes the most substantial thing they've built from their own evidence.

The fix is the same move as the trade-off writing above, just applied to work you can't link. You can almost always describe the shape of a problem and the reasoning behind a decision without exposing proprietary code or data: the scale you were operating at, the failure mode you were guarding against, the option you rejected and why, what changed because of the choice. None of that requires a screenshot or a repository. A paragraph that says "we were seeing timeouts at a specific point in the request path, the fix was to change where a particular piece of state lived rather than add more hardware, and the reasoning was X" is more convincing to another engineer than a polished screenshot would have been, because it's the kind of detail you can only produce if you actually did the work.

When not to hand-roll it

All of this argues for spending your limited time on the writing rather than the build. It does not argue that you have to hand-build even the writing's container. If the site you would build for yourself is a weekend project standing between you and three paragraphs that matter, it's worth being honest about which part is actually valuable.

reach is built for exactly the part of this that isn't the interesting part: you upload a CV and a photo, answer a short form, and it composes a complete one-page site — the page itself is generated in about twenty seconds, and you can be live at a free subdomain in under two minutes. For an engineer, that removes the weekend entirely and leaves the part that was always the actual task: writing the sentence about the trade-off, and deciding which one repository is worth linking.

It has real limits for this audience, and they're worth stating rather than glossing over. There's no HTML export and no custom code or CSS field, so if the appeal of building your own site was the site itself — the chance to write your own component library, to control every pixel — reach removes that option along with the weekend it would have cost. It generates one page, not a multi-page site with its own blog or a writing archive; if you want a place to publish longer technical posts over time, that's a different and larger tool. And there's no built-in analytics, so you won't get traffic numbers on the page itself. For a single page whose job is to frame two links and three paragraphs before a reader goes to GitHub anyway, those trade-offs cost little. For an engineer whose site is meant to double as a technical blog or a demonstration of frontend skill, they cost a great deal, and the honest answer for that person is to build the thing by hand — reading how the wider field approaches this in personal websites by profession is a reasonable place to start, and the same logic in a very different field is worth comparing in a personal website for academics. For everyone else, the more useful comparison is closer to home: what actually belongs on the page next to your GitHub profile, and how much of it needs to be handmade to do its job.