How to revive a side project

The 6 steps

Step 1: Decide: revive or archive

Before you commit 2 weeks, decide whether to revive or archive. The decision tree:

• Revive if the code is salvageable, you remember the vision, less than 2 years have passed, and dependencies still work.
• Archive if the code is unrecoverable, you've lost the vision, more than 3 years have passed, or dependencies are unmaintained.
• Hand off if you'd like to see it continue but you can't commit time. Drop it on BreakPoint.

Step 2: Re-read the original README

The README you wrote at the start is the truest description of the project. Read it. Is this still what you want? Or did the project become something else in your head? Most revival projects fail because the revivalist tries to ship the version they imagined 2 years later, not the version the original README described. The README is the anchor.

Step 3: Run it once

Don't start coding. Run the existing version first. Get the project working locally. See what it does. The act of running it is a kind of memory retrieval — you'll remember why you started it. If the project won't run, that's diagnostic: revive is harder than you thought, but not impossible.

Step 4: Pick the single most important feature

The single most important feature is the one that, if shipped, would make the project feel "real." For an MVP, it's the user flow. For a weekend hack, it's the demo. For a personal tool, it's the function that solves your actual problem. Ship that one. Don't ship a feature list. Ship the one thing.

Step 5: 14-day sprint, public commitment

Commit publicly to a 14-day sprint. Tweet it. Post on your blog. Tell your friends. The public commitment creates social pressure that prevents the revival from drifting into another 2-year project. Daily commits, public log, end-of-sprint demo. The structure is more important than the work.

Step 6: Ship, then iterate (or archive)

At the end of the sprint: ship, or archive. Don't ship "if you have time." Don't ship "once you polish the UI." Ship or archive. The binary decision is what kills the revival-as-drift pattern. If you ship, you can iterate. If you archive, you can start something new without guilt. Both are wins.

The 5 red flags that mean archive, not revive

• You don't remember why you started it. The original motivation is gone.
• Dependencies are abandoned. Three levels deep, the dep tree is dead.
• The market moved on. A better version exists publicly.
• Your life changed. New job, new city, new family — the project was a snapshot of a moment.
• You've been here before. This is the 3rd revival attempt. Patterns don't lie.

If 2 or more of these are true: archive. Don't revive. Use the responsible abandonment guide.

Frequently asked questions

Related reading