Where to launch a developer tool
I built a weekly launch board, so I see developer-tool submissions before the public does. The ones that die are almost never "wrong board." They linked a waitlist, a private repo, or a README that still says clone it and figure it out. Put the tool where people already install that kind of thing. Then tell a community.
Updated September 24, 2026
What I check before a listing goes live
Every Nukkadly listing stays private until a person reviews it. The rule in the guidelines is blunt. Live software, an API, a developer utility, or open source with a homepage or docs. Honest MVPs that people can try today. Not a landing page with no product.
For a developer tool, that review is really one question. Can a stranger get to a first result from the URL you submitted, without a call from you? If the answer is no, sending that URL to a ranked week is a waste of both of us. I will send it back. You will still have a broken first run.
Pick the install path, not a brand of launch board
CLI or library
Ship it to the registry your users already type. npm, PyPI, crates.io, a Homebrew formula. Follow that registry's own publish docs, not a launch thread. Add a tagged GitHub release when you ship binaries or you want the changelog tied to a version. Then the Nukkadly URL can point at that install. If the package is still private, you do not have a launch. You have a teaser.
Editor extension
Publish in the Visual Studio Marketplace or the JetBrains Marketplace first. Those listings are the install button. Microsoft's VS Code publishing guide and JetBrains' plugin upload guide are the process. What I still see in submissions is a GitHub zip and a screenshot of the editor. That is not an install path. Say what the extension can read, on the marketplace page, before you ask anyone to vote.
Hosted API or developer SaaS
Docs, one copy-paste request, a price. This is the format a weekly board can actually host. Visitors on Nukkadly mark whether it fits, whether they would try it, and whether they would pay. Those marks are empty if the docs still 404. Finish the first call on a clean laptop, then submit.
Show HN is still the right room for something they can run
A weekly directory does not replace a thread where engineers argue with the implementation. Show HN wants something people can run or inspect the moment they open it. A waitlist is the wrong format there, and it is the wrong format on Nukkadly too. Title the post as the job the tool does. Stay in the thread. Most posts go nowhere. That is the price of that room. There is also no product page left in October. If you want a URL that still exists, keep the registry listing, and a directory page, after the thread dies.
When a board is the next step, and when it is not
Product Hunt still works when you can explain the tool with a screen and you can staff a Pacific morning. Their own posting guide is a gallery, a tagline, topics, pricing. I would not make that the whole plan for a protocol that only one role understands. Those buyers read docs.
Nukkadly is a Monday to Sunday UTC week, then the same page stays in Browse. I designed it that way because a 24-hour hunt freezes before a lot of developers even see it. Rank is not for sale. New accounts vote at a quarter weight for seven days, which is annoying if you just signed up and useful if someone tries to stuff the board. Comments are tagged useful, confusing, pricing, or missing on purpose. A CLI that only collects fire emojis taught me nothing when I was the one shipping. I did not want that on this board either.
Use the Developer Tools category once the install works. How the week works is the short loop. If you are shopping boards rather than install paths, that comparison already lives in Product Hunt alternatives. I am not going to rewrite it here.
What I would skip
Pasting the same paragraph into five Discords on release day. Paying for a homepage pin while the quick start still fails. Asking friends to upvote a Show HN. Submitting the same vaporware to ten directories because a spreadsheet promised Domain Rating.
If you need people to sit with the product before any of that, do that first. The method is how to get feedback on a SaaS before launch. A CLI has the same first-run problem. Watch the install. Write down the pause.
Common questions
What is the best place to launch a developer tool?
The install page for that kind of tool. On Nukkadly we review the public URL. A library that is not in its registry, or an extension that is not in its marketplace, is not ready for a launch week.
Should I launch a CLI on Product Hunt first?
Usually no. Product Hunt is built around a tagline and a gallery. A CLI is built around a command that runs. Publish the package, then use a board if you still want people outside GitHub to see it.
Will Nukkadly accept an open-source developer tool?
Yes, if there is a homepage or docs a stranger can use today. We reject listings that are only a waitlist or a landing page with no product. Open source with a tagged release and an install command is a good fit.
Where should a VS Code extension launch?
In the Visual Studio Marketplace. Share that listing after it is live. Do not send launch traffic to a zip file.
Have a URL someone can open?
Submit it after the install or the trial works. If you are still comparing directories, read new product listing sites before you fill out ten forms.