Why we built RepoVelocity: GitHub trends without the noise

I lost the better part of a week building something that already existed. Not a rough equivalent — the actual thing, better made, with thousands of stars and a handful of active contributors. I found it two days after I shipped.

The wasted time stung. The wasted LLM credits stung more, because those come with a number attached and the number was not small. The genuinely irritating part is that the information had been public the entire time. It was sitting on GitHub, findable, if only I had known to look there first.

That is the problem RepoVelocity exists to solve. It is worth being specific about why the answers that already existed did not solve it for me.

The trend sites already exist. That's the problem.

There is no shortage of GitHub trending sites. I tried most of them. Three things kept sending me away:

• They're slow. Pages that take several seconds to become usable, mostly because of what is loading alongside the content rather than the content itself.
• They're cluttered. Ad slots above the list, beside the list, between the rows. Once you are scanning a hundred repositories, every unit of visual noise costs you real attention.
• They tell you what already happened. Ranking by raw star count over a fixed window surfaces repositories that have already had their moment.

The third one is the actual problem. The first two are irritating; that one makes the tool useless for the thing I wanted it for. A repository with 12,000 stars this week got them because a lot of people already found it. Being told about it puts you at the back of a queue you did not know you had joined.

A trending list is a record of attention that has already been paid.

We look for the burst before it bursts

RepoVelocity runs seven ranking models instead of one, because "what's trending" is not a single question. Trending now, daily, weekly, 30-day, fastest growing, new breakout, and established momentum each answer something different, and picking the wrong one is how people miss things.

Two of them exist specifically to catch things early:

• New breakout looks at repositories that are young and accelerating, where the total star count is still low enough that no trending list has noticed.
• Fastest growing ranks by rate rather than total — so a project going from 200 to 900 stars outranks one going from 40,000 to 41,000, which is the correct ordering if you are trying to spot what is happening rather than what happened.

Rate is the useful signal, and it is the one raw star counts throw away.

We deliberately don't track everything

This is the decision people question most, so here is the reasoning in full.

RepoVelocity does not cover every category on GitHub. It covers the ones a builder can actually ship something from — AI and machine learning, developer tooling, web frameworks, databases, infrastructure, design tooling, and their neighbours. The rough test for whether a category belongs is whether a repository in it could plausibly end up inside a project someone is trying to make money from.

I built this for myself before it was a product, and I did not want a complete index of open source. A complete index of everything is exactly what makes the other sites hard to use. Every category you add that I will never build with is a category I have to skip past, and skipping past things is the cost the existing tools already charge.

Narrow coverage is a real limitation, and worth saying plainly: if you work in scientific computing, embedded systems, or game engines, RepoVelocity is currently not built for you. More categories may follow as the tracked pool grows. But the default is deliberately not "add everything" — it is "add what earns its place."

Stars lie, so we score them

A 40,000-star repository abandoned two years ago will outrank a 2,000-star project with sixty active contributors and daily commits on almost any trending list. That ordering is backwards for anyone choosing a dependency, because the thing you actually want to know is whether the project will still be maintained when you hit a problem.

So every tracked repository carries a Signal Score from 0 to 100, built from four things:

• Code-to-fork ratio. Whether there is substance behind the attention.
• Contributor spread over 90 days. One person's project and sixty people's project carry very different risk, and this is the number that is hardest to fake.
• Star-curve organicity. Real enthusiasm is jagged — it has a working week in it, and visible spikes around releases. Purchased attention is smooth.
• Freshness. When the repository was last actually touched.

Repositories scoring 80 or above are marked verified. Ones showing manipulation patterns score lower and can be flagged suspect — which does not mean malicious, just that the star count is not evidence and you should look at contributors and commit recency instead.

This is the piece other trend sites do not have, and it is the one that took the most work.

No ads. That's the whole design.

Ads are the reason the other sites are slow and cluttered. It is not incompetence — it is the business model showing through the interface. So RepoVelocity has none, and will not have any.

That leaves one honest way to pay for it, which is a members area with features worth paying for: tracking repositories we do not cover yet, watching specific projects you care about, organising what you find into folders, and bookmarking things to come back to. The rankings themselves stay free to browse without an account.

Membership is not open for signups yet. When it is, it will be because those features are genuinely useful, not because the free version has been made worse.

Where this actually is right now

Being straight about the state of things: ingestion is live and runs hourly, but the rankings on the board are currently sample data while snapshot history accumulates.

That is not a soft launch excuse, it is the nature of what is being measured. A momentum ranking is only as good as the history behind it — you cannot compute a growth rate from a single reading. The system needs its own hourly snapshots, over days, before the numbers mean anything. The board shows how much history has been collected so far, and it says "sample data" until that history is deep enough to rank honestly.

Showing made-up rankings without saying so would be the easier launch. It would also be the exact behaviour this whole product is a complaint about.

What it's for

The week I lost is the short version of why this exists. The longer version is that keeping up is now part of the job. The tools, the harnesses, the patterns, the design conventions — the useful ones surface on GitHub first, and they surface as a rising line before they surface as a headline.

RepoVelocity is an attempt to watch that line, in the areas where watching it pays, without an ad in the way.