:)
6 karma · joined December 9, 2025
:)
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
Thanks!
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?
Thanks!
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 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 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.
Do i need to do anything else on my repo?
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.
I recently built a tool that I personally needed for my own projects, and now I’m super curious if other developers would actually find it useful.
It’s called dotenv-diff, and the main feature is a codebase scanner that finds problems with environment variables before they break things.
Why I built it
I kept seeing the same issues in real projects:
Feature breaks because .env is missing variables
New developer joins → app crashes due to missing env
.env.example goes out of sync
Someone accidentally leaves a secret inside a TS file
Frontend frameworks misused env naming (NEXT_PUBLIC, VITE_, etc.)
I wanted one CLI command that gives me a full health check of environment usage in my project.
Honest question:
Would this be useful in your workflow?
If you want to check it out:
npm package: https://www.npmjs.com/package/dotenv-diff Docs: https://dotenv-diff-docs.vercel.app