Your Dead Side Project Is Your Next Job Interview
Close out one dead repo this week. Walk into your next interview with three stories you didn't have this morning.
Hey there,
We opened our GitHub dashboard last Sunday and counted 14 dead ones.
The recipe app that died at authentication. The workout tracker has a landing page and no backend. The Chrome extension whose last commit says wip, will finish tomorrow. Sixteen months ago.
Every developer we know has 5 to 15 of these.
Everyone feels like evidence of failure you’d rather not explain.
Here’s what we figured out.
That folder isn’t shameful. It’s unclaimed evidence.
Every dead project answered a specific technical question before you quit. It proved you could scaffold auth from scratch, integrate a payments provider, parse a weird API, or ship a UI that looked decent.
You did that work.
You just never told anyone about it.
So we wrote this with 3 goals:
show you why the graveyard is worth more than your next fresh idea
hand you a skill that turns any dead repo into three interview-ready artifacts
walk one archetypal dead project through the whole flow.
Two things before we start:
Run
/graveyardon one repo this week. Just one.Send this to any dev updating their LinkedIn on a Sunday night.
Yesterday, building an n8n workflow meant opening the docs, dragging nodes, debugging connections, and hoping it would work.
Today it means: describing what you want in plain English and getting a complete, ready-to-deploy workflow in minutes, with a full guide so you actually understand what’s running.
Autom8n just went live.
The gap between “I have an automation idea” and “it’s running in production” just got a lot smaller.
1. A dead side project is a completed experiment.
Not a failed product.
You set out to learn whether a specific idea, stack, or workflow was worth your time. You found out. That’s the entire point of a side project.
The output was never supposed to be a running SaaS with paying customers. The output was the answer to a question.
Once you have the answer, the project’s job is done. Whether or not the code deploys.
Treating the graveyard like a pile of failures hides the evidence at exactly the moment you need it most.
2. Three things it’s costing you.
Cost 1: interview answers you’re not giving.
A recruiter asks about a tricky technical tradeoff. You freeze. You reach for the production codebase you get paid to work on.
Meanwhile, that dead recipe app answered exactly this. NextAuth over Clerk on day one. 2 am session-handling discovery. Abandonment two weekends later.
That’s a three-minute story with a setup, a decision, a consequence, and a lesson.
You never wrote it down.
Cost 2: your portfolio page is a lie.
Two pinned repos (the ones that work). Fifteen hidden.
A working to-do app in Tailwind isn’t evidence of range. A dead Chrome extension that scraped competitor pricing is. So is a dead Discord bot that ran a fantasy league. So is a dead Electron app with a working event loop.
The filter you apply to your own profile is the one recruiters then have to work around.
Cost 3: unclosed means unlearned.
Six months later, you’ll start the same doomed project. Same scope creep. Same “I’ll do the auth part in a weekend” delusion.
We’ve watched engineers start the same project three times across two years, each time convinced it was different.
It wasn’t. They’d just never closed out the previous one, so the pattern stayed invisible.
3. The /graveyard skill.
We packaged the closing flow into a Claude Code skill.
Install once:
claude install-skill https://github.com/Ship-With-AI/skills/tree/main/graveyard
Then, pointed at any dead repo:
/graveyard
Two questions: target job or use-case + the honest reason you stopped.
Then three artifacts in one pass.
4. What the skill produces.
Artifact 1: the portfolio story.
2 to 4 sentences. Past-perfect active voice. “I built X using Y to answer Z, and I learned W.”
Not the apologetic “tried to build” voice most developers default to.
Optimized for five-second scanning. Because that’s how long a recruiter spends on each project.
Artifact 2: three rehearable stories.
STAR+Reflection format. Each is grounded in a real commitment.
The skill maps the project’s actual technical work to the questions you get asked in every behavioral round:
"Tell me about a tradeoff you made and later reconsidered."
"Walk me through a time you scoped a feature incorrectly."
"What's a project that didn't go the way you expected?"
Three prepared stories mean every round has at least one differentiated answer. The same three cover a year of “so what are you working on?” conversations.
You walk out with three stories you didn’t have this morning.
Artifact 3: the closing commit.
A new README section (## Status: closed out on [date]) with:
A one-paragraph postmortem (what you set out to do, how far you got, why you stopped).
A What This Repo Is Evidence Of bullet list.
A Would I Revive This verdict (no, and the reason is still true / yes, under these specific conditions).
Plus a commit message draft. Nothing pushed automatically. Human always in the loop.
5. One dead project, walked through.
The archetype: a Next.js + Postgres + NextAuth recipe sharing app from eighteen months ago. Landing page works. Sign-up works. Stuck on “magic-link sharing to a friend.” Last commit: wip: magic link generation, session invalidation issue.
Portfolio story Claude produces:
Built a Next.js recipe sharing app with Postgres and NextAuth to evaluate whether passwordless magic-link flows could replace traditional account ownership for a family-scale product. Shipped landing, sign-up, and recipe CRUD. Hit a session invalidation edge case between NextAuth and the magic-link layer that required more custom middleware than the feature justified. Closed out after validating that off-the-shelf auth wasn’t sufficient, a data point that redirected two later side projects toward Supabase from day one.
Three rehearseable stories Claude produces:
“Tell me about a technical tradeoff you made and later reconsidered.” → NextAuth vs. Clerk on day one. Supabase eighteen months later. Real code snippet to pull up.
“Describe a time you scoped a feature incorrectly.” → Magic-link sharing looked like one weekend. Two-minute story: “I realized the invalidation step needed to reach across two auth contexts.”
“Walk me through debugging a session-state issue across two auth providers.” → You already did the debug work.
README edit Claude produces:
## Status: Closed out on 2026-04-22
This project started as a family recipe sharing app to evaluate whether
NextAuth's magic-link flow could replace password auth for a small-scale
consumer product. Landing page, sign-up, and recipe CRUD shipped.
It closed at magic-link sharing, where session invalidation between
NextAuth and the magic-link layer required custom middleware that didn't
fit the project's scope.
### What this repo is evidence of
- Next.js 14 app router + Postgres + Prisma schema work
- NextAuth integration including custom providers and session callbacks
- Full sign-up / sign-in / recipe CRUD with RLS-style authorization
- A documented decision about when off-the-shelf auth stops being worth it
### Would I revive this?
No. The session invalidation constraint is still true. If I rebuilt this
today I'd start on Supabase for first-class magic-link handling. This repo
now exists as evidence of the decision path, not as a product to ship.
Commit:
chore: close out project, document postmortem and evidence
Three artifacts. One evening. One dead repo now worth linking.
6. Three mistakes to avoid.
1. Deleting the repo instead of closing it out.
The first instinct is to delete the evidence of failure, which destroys the exact signal you need later.
Archiving is cheap and reversible. Deleting is neither. If in doubt, archive.
2. Writing apology READMEs.
A close-out describes what the project proved. Not what it failed to become.
If the paragraph uses the word “sorry,” delete it and start over.
3. Reviving instead of closing.
The skill makes the project look tantalizingly close to shippable. One more weekend, you tell yourself.
This is almost always a lie. The reason you stopped is still true. The session invalidation bug is still there. The auth provider is still wrong.
Revive only if the original blocker is genuinely no longer true. Not because the closing summary made it look easy.
/graveyardis deliberately narrow. It closes out the evidence you already have. When you’re ready to target roles with it, there’s career-ops. An open-source Claude Code pipeline for scanning, evaluating, and negotiating offers. 33k stars. Built by a Head of Applied AI who used it to land his own role.The two workflows compose. Close your graveyard this week. Feed the artifacts into career-ops next week. The job search starts from a real portfolio instead of a cold resume.
But don’t install career-ops today. You need one closed-out repo first.
7. Evidence is all you need.
Next Sunday night, one of your dead ones should be different.
It should include a closed-out README with a postmortem, an evidence list, and a written decision on whether to revive or not.
It should be pinned instead of hidden.
There should be three more interview stories than there were this Sunday.
That’s one project closed out, one evening of work, and a permanent lift to your portfolio’s signal-to-noise.
Run /graveyard on one repo this week. Just one.
Don’t close out the full graveyard in one sitting. You’ll get tired, the quality drops, the READMEs get worse than none.
One per week for three months → twelve closed-out repos, and somewhere between twenty and forty rehearseable stories.
That’s the entire game.
If you’re reading this between jobs and panicking: you can close out one repo tonight. The evidence is already written, in commits and in your memory. The skill just pulls it out.
Stop apologizing for the projects you built.
Start linking the evidence you already have.
Now go build.
— Ale & Manuel
PS. Reply and tell us which dead project you closed out first. We want to see the before-and-after READMEs. Best three get featured in a follow-up.
And whenever you are ready, there are 2 ways I can help you:
1. AI Side-Project Clarity Scorecard (Discover what’s blocking you from shipping your first side-project)
2. NoIdea (Pick a ready-to-start idea created from real user problems)