I’ve been working on a small open source CLI tool in my spare time and recently reached a point
where it feels “done enough” to share — but I’m unsure what the right next steps are.
So far I’ve tried:
- Writing a clear README with examples
- Adding documentation and usage guides on my docs website
- Sharing it in one or two relevant discussions (without spamming)
I’m explicitly not trying to market it aggressively — I’d rather get it in front of the right people
and receive honest feedback.
For those of you who’ve shipped open source projects that actually got adopted:
What made the biggest difference early on?
What do you wish you had done sooner?
If it helps, the project it's the link if you have any tips
I recently built a small open source CLI tool that scans a codebase for environment variable issues
(missing env vars, unused vars, framework-specific mistakes like Next.js / t3-env, etc.).
I’m not trying to grow users yet — I’m mainly looking for honest technical feedback:
- Is the problem real?
- Are there obvious flaws in the approach?
- Could this be used in your workflow?
For people who’ve shipped OSS tools before:
What worked best for you when gathering early feedback from experienced developers?
I'm looking for input from senior engineers who have more experience than me with large codebases and team workflows.
I built a CLI tool that scans the codebase and warns about these problems automatically. It also detects framework-specific rules for Next.js and SvelteKit.
The tool i have build works well in my job where we have a turbo monorepo — but I genuinely don’t know if this is something experienced teams would ever rely on, or if there's already a better approach in the real world.
I recently released an open-source tool that solves a real problem I kept running into, and now I’m wondering how other developers get visibility for their projects.
I'm not trying to “promote” anything here — I’m genuinely curious about the process.
I’ve posted on GitHub Discussions and Reddit, but it’s still hard to get people to notice a new repo unless it randomly hits the right place at the right time.
What I have observed is that a project's popularity has almost zero correlation to the amount of effort behind it, or how well done it is. You just need to get lucky. Maybe one person noticed your utility, invited you to some podcast, and then your repo explodes in popularity.
One thing I can tell you is that you should stop seeking to get notoriety, because the effort you are spending on that is effort you don't spend in improving your open source tools. I know it is probably quite frustrating, but you just have to continue building stuff in public and hoping to get noticed at some point.
Thanks for the advice, and i think you are 100% right.
i am already working as a software developer, so the only reason that i want it to get noticed, its because i just think its cool to have made something other people find useful. And i love programming, and this project is definitely making me a better software developer, with or without tons of downloads or stars :)
Just wanted to make sure that i didn't do anything miserable wrong
I am currently working on a turbo mono repo frontend on my work with maybe 20-25 different env variables. Here the dotenv-diff is really a game changer, but yea for smaller projects, i might be a bit overkill.
I like the projects you have linked, i will try to see if they have any need to have features that i could use
in `dotenv-diff` you also have the --compare option which will compare your .env whit your .env.example to keeping them in sync, while also have the amount of scanning features that keeps the project safe.
One really nice thing in varlock for monorepos is the import syntax. This lets you have shared config at the root, or just to break things up however you need. No need for diffing or copy pasting, as the schema validates everything - if something is required, it will yell at you.
:)
https://github.com/Chrilleweb/dotenv-diff