I have spent the last few months shipping a string of small tools: a scaffolding CLI, a secret scanner, a git analytics tool, a snippet manager, and a set of 14 browser utilities. All free, all zero-dependency.
The interesting question was never "how do I build these?" (each takes an afternoon). The question was: what actually gets them used?
Honest retrospective, with the parts that worked and the parts that did not.
What Drove Downloads
1. Dev.to articles with real terminal output
Every article I published included actual command output — not "here is what it might look like", but the real thing, pasted. Those articles consistently outperformed the polished ones.
Why: developers sniff out marketing from a mile away. A terminal screenshot of the tool actually running reads as evidence.
2. The npx-first design
Zero install, zero config. The friction between "saw an article" and "ran the tool" was one line:
npx @wuchunjie/dotguard .
Every tool that required setup got fewer users than every tool that did not. No contest.
3. Cross-linking
Each article's footer listed all four CLI tools. A reader of the snippet article met the scaffolder. A reader of the security article met the analytics tool. The funnel is a web, not a line.
4. The npm page itself
A good one-line description, a README with copy-paste commands, and sensible keywords. npm search is a quiet, persistent channel — people find the tools months after the article traffic is gone.
What Did Not Work
1. Generic "top 10 tools" posts
The listicle format gets reads but barely converts when your tool is item #7 in a list of ten famous ones. Specificity beats breadth: "the tool for this exact job" wins.
2. Trying every platform at once
I tried to spread across several communities and burned out in a week. One platform (Dev.to), one rhythm (a few well-targeted articles), beat scattered presence everywhere.
3. Announcing "v1.0" like a product launch
Nobody cares about version numbers for a free utility. The tool either solves the moment it appears in the article or it does not.
The Pattern That Repeats
Every successful push followed the same shape:
- One concrete pain ("your .env is in the repo")
-
One command that solves it (
npx @wuchunjie/dotguard .) - Real output as proof
- Cross-links to the other tools
- A quiet Ko-fi line
The tools are small on purpose. The funnel is the product.
What Is Next
More templates in the scaffolder, more scan patterns in the scanner, and — if the feedback says yes — a small web dashboard that reads the same local JSON files the CLIs write. Same rules: free, local-first, zero bloat.
If any of these saved you time, the Ko-fi is how the next one gets built.
From the same toolbox
-
ScaffoldX — generate production-ready project templates in seconds:
npx scaffoldx-cli -
DotGuard — scan
.envfiles for exposed secrets:npx @wuchunjie/dotguard -
GitPulse — git analytics (commits, contributors, activity) in your terminal:
npx @wuchunjie/gitpulse -
SnippetX — save, search, and copy code snippets from the terminal:
npx @wuchunjie/snippetx
☕ If This Saved You Time
All of these tools are and will always be 100% free. If they make your day a little easier, consider fueling the next one:
Built with ❤️. Zero dependencies, zero tracking, zero bloat.
Top comments (0)