Portfolios age in public

Portfolios age in public.

That is the annoying part of having a personal site. Old work keeps talking after the context disappears. A project from five years ago might still be technically true and still say the wrong thing about what you care about now. A screenshot may show a UI you would no longer ship. A paragraph may describe a role with the vocabulary you used before you learned better words. A demo may be broken because the API changed. A link may point to a dead service. A claim may be missing the constraint that made it reasonable at the time.

None of that means the work was fake. It means the artifact is aging.

A personal site needs pruning for the same reason a codebase needs maintenance. The old stuff does not stay neutral.

old work needs context

I do not like pretending everything old is current.

If a project was built for a class, say that. If it was a weekend prototype, say that. If it was an early-career piece, say that. If it solved a narrow problem with constraints that no longer apply, say that too.

Context makes old work more useful, not less.

The bad version of a portfolio is a museum where every artifact is lit like a masterpiece. The better version is a notebook with enough honesty that a reader can understand what the work meant at the time and what it says now.

I would rather see:

built in 2021 as a prototype to explore X
still useful as an example of Y
I would now change Z

That is stronger than silently leaving the piece to impersonate current judgment.

pruning is not hiding

People get weird about deleting portfolio items.

I get it. Work took effort. Removing it can feel like pretending it did not happen. But the site is not an archaeological record. It is a public surface with a job.

Some old work should stay because it shows a real progression. Some should move to an archive. Some should get a note. Some should disappear because it is no longer useful to anyone.

The pruning question is not “am I still proud of this?” That is too emotional and too vague.

Better questions:

• does this still represent my judgment?
• does it need context to be fair?
• does it distract from stronger work?
• does it show a skill or pattern that still matters?
• is the link or demo still functional?
• would I want to discuss this in an interview or technical conversation?
• is it here because it is useful or because I never removed it?

Those questions make pruning less dramatic. It becomes maintenance.

screenshots can lie

Screenshots age especially badly.

They freeze a visual state without the constraints behind it. Maybe the layout was built before the design system changed. Maybe the data was fake. Maybe the app worked only on desktop. Maybe the screenshot hides the empty state, loading state, or error path. Maybe the interesting part was the backend, and the screenshot makes the project look like a UI exercise.

Screenshots are still useful. They need captions with enough context.

For older work, I like captions that answer:

• what was built
• what part mattered
• what was real
• what was mocked
• what I would change now

That last part is underrated. A portfolio can show growth without apologizing for every old decision. “I would do this differently now” is often the most interesting sentence on the page.

broken demos need decisions

A broken demo is worse than no demo.

If the project depends on an old API, auth flow, hosting provider, dataset, or build tool, the site needs a decision:

• fix it
• replace it with a video or screenshots
• archive it with a note
• remove it

Leaving it broken asks the reader to do emotional labor. Maybe it used to work. Maybe it is temporarily down. Maybe the project was never finished. The site should not make them guess.

This is where personal sites feel like infrastructure. Links rot. Dependencies age. Domains move. Build scripts break. A portfolio item is a tiny production system if it is publicly linked.

the archive can be honest

Not everything needs to sit on the front page.

An archive is useful when it has a clear meaning. It can hold old projects, experiments, talks, posts, and prototypes without pretending they are the strongest current work.

The archive should still be maintained enough to avoid embarrassment. It does not need polish everywhere, but it should not contain broken nonsense, missing assets, or claims that no longer make sense.

I like the idea of an archive note:

This is older work. I keep it here because it shows the path, not because it represents the current version of my thinking.

That gives old work a place to live without letting it steer the whole site.

writing ages too

Technical writing ages in a different way.

A post may be tied to a release, a tool, a model, a framework version, or a moment in the industry. Some posts should be updated. Some should be left as timestamped reactions. Some should get a note at the top. Some should be deleted because they were shallow, duplicated, or wrong.

The key is to avoid silent drift.

If a post is historical, let it be historical. If it is meant as guidance, keep it current. If it has been superseded by a better post, link forward. If the conclusion changed, say so.

The worst state is a post that sounds timeless but was really a reaction to a narrow moment.

maintenance should be scheduled

Portfolio pruning works better as a recurring pass than as a panic rewrite.

Once or twice a year, I would review:

• homepage projects
• resume links
• case studies
• old demos
• screenshots
• post categories
• dead links
• claims that need dates
• work that should move to archive
• work that deserves a better writeup

This is not vanity. It is source control for a public identity.

A personal site is often the surface someone checks before deciding whether to talk to you, hire you, collaborate with you, or trust your judgment. The site does not need to be perfect. It does need to avoid letting stale artifacts speak louder than current work.

Portfolios age in public. The fix is not to hide the aging. The fix is to keep enough context around the work that age becomes part of the story instead of a slow leak of credibility.