I have written two posts about Muraqib already. One on August 29, about open sourcing the thing and then spending three nights trying to break it myself before anyone else could. One earlier today, about the bot that got cancelled sixty nights in a row and never said a word about it.
Neither post mentions a star count. Neither mentions a fork count. Neither mentions a download number. I checked both, word for word, before writing this one. The gap was just never there.
That is the actual subject of this post. Not a new feature. A readme that shipped with zero signal on it, for a project people were already pulling down.
Muraqib is a nightly Playwright QA watchdog for solo SaaS founders, open source, MIT licensed, at github.com/holistis/muraqib. Here is what I mean by already pulling down. Muraqib has zero GitHub stars and zero forks right now. But over the last 14 days, the repo has been cloned 175 times, by 70 unique cloners. Views sit at 83 total, 66 unique. Clones spiked hard on August 29, the day the first article went out. 96 clones from 43 unique cloners in a single day, more than half of the two week total.
So the readme people were landing on, the same day the traffic actually happened, had nothing on it that told a visitor anyone else was using the thing. No badge, no number, nothing. Zero stars sitting at the top of the page next to 43 people quietly cloning it that same day is not a coincidence I am proud of. It is just what happens when you build the tool and forget to build the page.
I found this today while doing something unrelated. Earlier the same day I had already fixed a different readme problem on this project, a line that promised a public defect history with nothing underneath it. Different bug, same shape. A claim or a blank space where evidence should be, and nobody checking what the reader actually sees.
What I fixed
The fix for the stars and forks gap was small. I added badges today. npm version, npm downloads per month, GitHub stars, GitHub forks, license. All pulled live, none of them typed in by hand. If the numbers move, the badges move. I do not have to remember to update them, which is good, because I clearly do not remember to check them either.
The npm version badge already has something real to show. Muraqib went from 0.2.0 to 0.3.3 today, eight versions in one day, each one a real fix I found by running the tool against a production app and against other people's public repos.
The downloads badge does not have anything to show yet. npm's own download stats API is still returning package not found for this package as of today. That lag, 24 to 48 hours before a brand new package's stats populate, is normal, not a bug. But it means the badge on the page right now is a real badge with no number behind it. That is fine. It is honest about what is known, which is more than the readme was doing before today.
The broader thing I keep relearning is that a product having activity and a page showing that activity are two separate jobs. I spent real effort making sure Muraqib's core failure mode does not happen quietly. The release notes cover the actual reason for that effort. Of roughly 163,840 public playwright.config.ts files on GitHub, only about 1,684, roughly 1 percent, set a globalTimeout, the setting that prevents this project's core failure mode. I care about that kind of thing a lot.
I did not care, until today, whether my own readme gave a stranger any reason to trust the project when they first looked at it.
Instrumenting the product was the easy part. Instrumenting the page describing the product was the part I skipped without noticing. If you are building something people can find and clone, put the badge on before you write the second post about it, not after.
Top comments (0)