The archive is the point
Draft — written from notes, not yet reviewed. Rewrite this in your own voice, then delete draft: true from the frontmatter.
My projects page lists everything I've built, and a good portion of it is tagged archived. Not moved to a subpage, not quietly deleted — sitting in the same list as the things that work, with a grey badge on it.
Every time I redesign that page I have the same instinct, which is to hide them. I've stopped acting on it. A portfolio of only the things that worked tells you almost nothing about the person who made it, because the survivors are the least surprising part of the record.
Shutting something down is a skill, and it's visible
If you build alone, your scarcest resource isn't ideas and it isn't hours. It's the number of things you can keep running at once. Every live product is a standing claim on your attention: support, dependency bumps, the API that changes under you, the customer who emails on a Sunday. Four abandoned side projects cost nothing. Four live side projects can end you.
Which means the decision to archive is not a failure to launch. It's the mechanism that makes the launches possible. Showing only the live ones hides the half of the process that does the real work.
What actually earns the badge
Three questions, and the honest answer to any one of them is enough:
Am I still using it? For a solo product this is close to definitive. The things I build for myself get fixed, because I hit the bugs. The things I build for a hypothetical person rot, because nobody reports anything.
Did I find the person, or just the capability? This is the one that gets me. I built an email intelligence tool that genuinely worked — embeddings over a Gmail account, real answers to real questions. I archived it because I never found someone whose problem was actually that shape. I had a capability and went looking for a use. That direction almost never works, and it took me far too long to admit that the technical satisfaction was doing the arguing.
Was it a question rather than a product? Some things get built to find out an answer. I built one app in an afternoon with a prompt-to-app tool purely to see how far that got me. It got further than I expected and not far enough to run on. That project succeeded completely — the answer arrived — and archiving it was always the ending. Marking it archived isn't a verdict, it's a full stop.
The one that stays for a different reason
There's a record-matching tool in that list, written in Python, that solved a real problem for exactly one person. It's archived because that person doesn't need it any more.
I keep it visible because it's the most honest thing in the portfolio. Not every piece of software should scale. Some of it is a favour with a build step.
What archiving is not
It isn't deleting. The repo stays, the write-up stays, and the badge is information rather than an apology.
It also isn't a maybe. The trap is the project that's neither live nor archived — no users, no roadmap, still technically running, still occupying a slot in your head. That's the expensive state, and it's the one that a portfolio without archives quietly encourages, because there's no honourable way for something to end.
Give things a way to end and they end sooner. That's the entire argument.
The version I'd defend
If someone looks at that list and reads six archived projects as six failures, they've read it correctly in one sense and completely wrong in another. Six things reached a decision. The number I'd actually be ashamed of is the opposite one: everything still live, nothing ever concluded, the whole list technically running and none of it maintained.
The archive is the part of the page that proves the rest of it is real.