When we first designed this marketing site, the temptation was the same as every other developer tool launch: put a large, impressive number in the hero section and worry about accuracy later. We resisted that temptation.
The problem with vanity metrics
Inflated metrics erode trust the moment a developer inspects the actual npm page, the GitHub repository, or the Wayback Machine. A developer who catches you rounding 47 downloads to '1 000+' will never trust your documentation, your changelogs, or your uptime claims.
"A small number that is true is worth more than a large number that is invented."
How we source the data
- GitHub stars and forks — GitHub REST API v3, unauthenticated read.
- npm download counts — api.npmjs.org/downloads/point/last-month/<pkg>.
- Package versions — registry.npmjs.org/<pkg>/latest.
- All numbers baked at deploy time and displayed with a verification timestamp.
const res = await fetch(
"https://api.npmjs.org/downloads/point/last-month/@hari7261/ainative-cli"
);
const { downloads } = await res.json();
// bake into static site output
export const cliDownloads = downloads; // 415What this means for you
If you are evaluating AINative for a production project, you can verify every metric this site displays by hitting the same public APIs. We consider that a feature, not a limitation.
As our adoption grows, the numbers will grow with it — and every increase will be credible because we started from zero and counted honestly.