Why We Built GitStat
If you maintain open source projects, you've probably clicked on the "Insights" tab more times than you can count.
And every time, you hit the same walls.
Traffic data disappears after 14 days. Star history is just a number, not a graph. Viewing multiple repos means opening multiple tabs. Exporting data usually means copy-pasting from a table.
GitHub Insights works, but it's not built for people who want to seriously track their project's growth.
So we built GitStat.
What we wanted
We wanted something simple but powerful.
We needed to see star growth over time, not just a total count. We wanted to keep traffic data longer than two weeks. We wanted to compare multiple repos side-by-side without browser tab chaos.
And we wanted to export charts for tweets and READMEs, or get raw CSV data for our own analysis.
None of this should require an enterprise plan or a sales call.
The Stack
We chose a stack that lets us move fast and avoid configuration hell.
Bun for speed
We use Bun for package management and our dev server. It turned "go make a coffee" install times into "already done."
Native TypeScript support means no transpilation steps during development. It just works.
Next.js 16 for the frontend
We're using the App Router with React 19.
Server components handle static pages like this blog. Client components handle the interactive dashboard charts.
File-based routing makes adding new pages as simple as creating a folder. No webpack config, no babel plugins. The defaults are solid.
Supabase for auth
We didn't want to build auth from scratch. Supabase gave us GitHub OAuth out of the box.
Users sign in with GitHub, we get an access token, and that's it. We use a simple Postgres table to store your connected repositories. No complex schema, no ORM headaches.
GitHub API for data
Everything else comes straight from GitHub's REST API via Octokit.
Stars, traffic, contributors, issues, and PRs—we fetch it all directly using your GitHub token.
This means we don't hit rate limits on our end. Your token, your limits. And you aren't trusting us with cached data that might be stale.
Technical decisions
Client-side fetching
Most data fetching happens right in your browser.
When you load the stars page, your browser hits GitHub's API directly. We don't proxy it through our servers.
This keeps our infrastructure light and ensures we never see your private repo stats. We literally can't see them because we never receive them.
Batch requests
Fetching every stargazer for a popular repo requires thousands of API calls.
We batch these requests 5 pages at a time. It's not instant, but we show a progress indicator so you know exactly what's happening.
Visualization
We use Recharts for visualization. It handles responsive sizing well and the area charts look clean.
We added custom tooltips and hover states so you can see exact numbers, not just vague trends.
Exports
For PNG exports, we use html-to-image to capture the chart element directly.
No server-side rendering or canvas manipulation required. The chart you see is exactly what you get in the image.
Better than Insights
Here's how we compare to the default GitHub experience:
Star History: GitHub gives you a number. We give you a full timeline with avatars for every stargazer.
Traffic: GitHub deletes data after 14 days. We show you everything available now, and we're working on long-term storage.
Multi-repo: GitHub forces you to click between repos. We put all your connected repos in one sidebar.
Exports: GitHub has none. We offer CSV for analysis and PNG for sharing.
Free forever
No trial periods. No credit cards.
We built GitStat because we needed it to understand our own projects. If you've ever wondered when your repo hit 1,000 stars or who your top contributors really are, this is for you.
Hopefully, you find it useful too.