How do solo builders get honest developer feedback without sounding like self-promotion?

[TomWartenberg-IRN]

🏷️ Discussion Type

Question

Body

Hi everyone,

I’m a solo builder from Germany and I recently launched my first small developer tool after teaching myself most of the product, security, deployment, billing, and documentation work along the way.

The hardest part has not been only building the tool itself. The harder part is finding honest developer feedback without sounding like I am just trying to promote something.

I built a small snippet-first code audit and security-testing playground because I wanted a faster way to understand small pieces of code without setting up a full SAST pipeline. The idea is simple: paste a snippet, choose whether you want code-quality feedback or security-focused feedback, and get a readable explanation of what is wrong, where it is, why it matters, and how it could be improved.

But after launching, I realized that getting people to actually try something and tell you what is confusing, useful, broken, or unnecessary is much harder than expected.

I do not want to spam communities with links. I also do not want to pretend the product is bigger than it is. It is a public beta, built by one person, and I am mainly trying to understand how developers evaluate small tools like this.

For those of you who have launched developer tools, open-source utilities, SaaS products, or side projects:

How did you get your first real feedback from developers?

What worked for you without feeling spammy?

Did you post in communities, ask maintainers directly, write articles, submit to newsletters, or just wait for organic discovery?

I would really appreciate practical advice from people who have been through this stage.!!!

Guidelines

• I have read and understood this category's guidelines before making this post.

[svenkroll]

Try to reach out to your existing network, colleagues, other developers you know and collect some feedback from them.
I also don't like doing it but a Reddit post really could end in real feedback.
I don't like saying this because it sounds harsh, but at the end, if nobody needs your tool: nobody searches for it, nobody will read your posts, nobody will share it, nobody will provide you feedback.

[TomWartenberg-IRN]

Thanks, that is fair and I appreciate the honest answer.

I think this is exactly the part I underestimated. Building the tool was difficult, but getting real developers to look at it and say “this is useful”, “this is confusing”, or “I would never use this” is a different challenge.

I have started reaching out through a few developer-focused places and listings, but I am trying to avoid low-effort promotion. I would rather get a small amount of real feedback than push the link everywhere.

And yes, your last point is harsh but useful: if nobody needs it, the market will make that clear. That is exactly what I am trying to find out now.

Thanks again for taking the time to reply. 👌

[aashwindev]

Honest dev feedback without feeling spammy:

1. Lead with a specific question, not a launch announcement — e.g. "Does this API shape confuse you?" with a screenshot.
2. Post in the right category (Programming Help, Show and tell) with context about what you want critiqued.
3. Offer reciprocity — review someone else's project in the same thread.
4. Share a minimal repro (repo link + 30 sec Loom) instead of marketing copy.
5. Use GitHub Discussions on your own repo for structured feedback; link it from README as "Feedback welcome".

Developers respond to concrete problems and readable diffs, not pitch decks.

[sauravsingla]

This is exactly the challenge I’m running into with an open-source developer tool.

I’m working on ConfigReach, which tries to answer a fairly specific testing question:

Your tests may have high code coverage, but which environment variables, feature flags, configuration values and important combinations are actually exercised?

https://github.com/sauravsingla/ConfigReach

Rather than simply asking people to “check out the project,” I’ve started publishing the measurable limitations too — precision/recall benchmarks, false positives/negatives, reproducibility results, and good first issue / help wanted tasks.

The feedback I’d most value isn’t “nice project”; it is something concrete like:

Run it against a real repository and tell me the first configuration pattern it gets wrong.

For people who maintain developer tools, have you found that this kind of narrowly defined validation request gets better engagement than asking generally for feedback?