We're all learning how to ship more side projects. If you're "in the bubble" it can feel like everyone is repo-maxxing. Shipping weekly. Spinning up agents to scaffold full apps overnight. New OSS dropped every Friday. The reality I see with most developers is much more normal:
They have six or seven repos sitting in various states of half-attention.
A side project from last year that still gets an issue every couple of months. A library someone mentioned in a thread once. A fork they meant to upstream. The repo they pinned on their profile that hasn't seen a commit since November. Most people I know don't have a "repo factory" problem. They have an I have no idea what's going on across my own GitHub anymore problem.
I've roasted plenty of developers for letting their projects rot. This year I realized I had been doing the same thing, just with more discipline pretending otherwise. Six GitHub tabs open on a Sunday morning, clicking between them, trying to figure out what actually needed me that week.
My maintenance routine suddenly felt... less of a routine.
The Web Version Of Copy/Paste
The data was always there. The interface just made me click for it.
Anything new since yesterday? Which repo is going stale? Whose PR have I been ignoring? Is anyone actually using the latest release? Each one lived behind a different tab, a different filter, a different page. Cheap individually, expensive in aggregate.
I use a normal-ish setup. VS Code, the gh CLI, a couple of PATs, a folder with too many cloned repos. Nothing fancy. And every morning I'd ferry context between tabs the same way junior devs ferry errors between VS Code and ChatGPT — manually, slowly, badly.
The obvious fix is: use GitHub Projects. The less obvious problem is: Projects is built for working inside a repo, not across all of them at once. It shows you what a single project thinks you should care about, not what you actually need to triage across your whole footprint.
I didn't want more from GitHub. I wanted less of it, arranged differently.
A Weekend Hack I Kept Opening
The first version was rough. A single React page hitting the API directly, no caching, no backend, the token sitting in localStorage where it absolutely shouldn't have been. Built on a weekend.
But I kept opening it every morning. That is the only signal that ever matters with an internal tool — whether you reach for it without being reminded.
So I rewrote it properly, then posted about the idea on Reddit, mostly to check if I was alone with this.
I was not. The replies were almost all variations of yes, this, exactly. Maintainers of small libraries. Indie devs with a graveyard of side projects. Tiny teams who didn't want a full Projects setup but needed an overview. People quietly assuming this was a personal failing.
That thread is the reason this is open source instead of a script in ~/dev/tools/.
Local Means Local
The naive version of my project was easy: spin it up as a SaaS, ask people for a GitHub token, host it somewhere, slap a Pro tier on it. And call it a day.
Except... tokens and security are a thing. I already play it too fast and loose with my own credentials. I'm trying to be better about that. I've also been on the other side of that ask too many times to put someone else through it. I needed local-first visibility, not "give a stranger read access to every repo you touch."
That became the design constraint for gh-dashboard: it runs on your machine, the OAuth app belongs to you, and the token never reaches the browser.
GitHub As The Data, Your Machine As The Trust Surface
The project is a small Node backend plus a React frontend.
The backend is the GitHub-facing part. It handles OAuth Device Flow, talks to REST and GraphQL, caches responses, and exposes JSON to the frontend.
The frontend is the human-facing part. Repository overview ranked by triage value, cross-repo issues and PRs in one list, a Kanban board for triage sessions, per-repo deep dives, and a daily digest of what changed — with optional AI-generated narrative if you plug in an OpenAI key.
I did not want consent hidden inside a hosted dashboard somewhere. I wanted separate surfaces. GitHub is the data layer. Your machine is where the token lives and where you actually look.
That feels like the right boundary.
The v1 surface is intentionally boring. List repos, list issues, list PRs, summarize what changed, flag stale stuff. That is enough to stop me from clicking through six tabs every morning.
Not GitHub Itself
I'm not naive to the fact that this overlaps with things GitHub already does. Notifications exist. Projects exist. The mobile app exists.
I am not trying to replace any of them. I am trying to make my normal triage routine less sloppy.
The goal is for the easy path to be the focused path: one place, no push notifications, attention-first, quiet when there is nothing actually demanding me. That already feels better than tab-juggling chaos.
More To Do
I still have plenty to do on this project. It's a rough first pass. Smarter health scoring. Daily digests that adapt to what you actually read. Saved filters. Lightweight team workflows that don't bloat into a project tracker. Smoother first-run.
But the direction feels right and I think it solves a real problem that I imagine other folks have.
I'm gonna keep using it and iterating on it for my workflow. Feel free to check it out!
Top comments (0)