Project Graveyard

"We tell developers why their projects die, before the next one does."

Comment

Inspiration

Every developer I know has a graveyard: folders of repos that started with huge excitement and quietly died after a week. What bothered me is that nobody ever asks why. We just start the next project and repeat the same pattern.

I wanted to turn that into something real: a tool that shows developers why their projects die, and warns them before the next one does. When I ran the first version on my own GitHub account, it immediately flagged repos I had forgotten about, and that's when I knew the idea was worth building.

What it does

Project Graveyard takes any GitHub username and analyzes their repositories:

  • ðŸŸĒðŸŸĄðŸŸ ðŸŠĶ Classifies every repo as Alive, Sleeping, Dying, or Dead based on commit activity
  • 📈 Draws a commit timeline showing exactly when each project went quiet
  • 🔍 Performs an autopsy with the likely causes of death: burst-and-burn (all the work in week one), stillborn (a handful of commits), never introduced (no README), untested, or long coma
  • ⚠ïļ Predicts which living repo dies next with an abandonment risk score from 0 to 100
  • 🔎 Gives an AI-written autopsy with one concrete step to revive the project this week

Type any username and see their graveyard in seconds.

How we built it

  • Data: GitHub REST API for repos, the last 100 commit dates, and each repo's file tree
  • Feature engineering: days idle, commit count, first-week burst ratio, longest gap between commits, and whether the repo has a README, tests, CI, and a description
  • Scoring: a transparent weighted risk score plus rule-based cause-of-death detection, so every verdict can be explained
  • AI layer: an optional Claude-powered autopsy, with a rule-based fallback so the app never breaks
  • Frontend: Streamlit, Pandas, and Altair for the dashboard and timeline chart

The pipeline is: fetch → extract features → score → diagnose → visualize.

Challenges we ran into

  • API rate limits: GitHub allows only 60 requests/hour without a token, and each analysis needs about 30 calls. I added token support and caching so repeated lookups don't burn the limit.
  • Messy real-world repos: empty repos, forks, and missing branches all broke the first version. I had to handle these edge cases carefully.
  • Defining "dead": there's no official answer, so I had to choose thresholds and signals that feel fair and are easy to explain.
  • Keeping the AI optional: I didn't want the demo to fail because of a missing API key, so the autopsy falls back gracefully.

Accomplishments that we're proud of

  • A fully working, deployed app built and shipped within the hackathon window
  • An explainable approach: every score and diagnosis traces back to visible signals, with no black box
  • A problem that is instantly relatable to every developer who has abandoned a side project
  • Handling messy real-world data without crashing

What we learned

  • Working with the GitHub API: pagination, authentication, and rate limits
  • Turning raw commit history into meaningful features
  • Designing a scoring system people can trust because they can see why it says what it says
  • That the reasons projects die are surprisingly consistent: no README, no tests, and one burst of energy

What's next for Project Graveyard

  • ðŸĪ– Replace the heuristic risk score with a trained model (logistic regression on labeled public repos) with feature importance
  • 🊊 A shareable "My Graveyard" card
  • 🔔 Revival reminders that nudge you when a healthy repo starts to slow down
  • ðŸ‘Ĩ Team and organization view to spot where projects die across a whole group

Built With

Share this project:

Updates

Submission history