CLI tools and self-hosted apps deserve their own launch pages

Try listing a command line tool on a launch directory and watch where it ends up. applauncher.io offers thirteen categories: SaaS, Web Apps, AI, SEO, Marketing, Directories, Online Tools, Chrome Extensions, CRM, Mobile Apps, Education, Social Media, Gaming. A terminal-first package manager is not any of those. You pick Online Tools, which is wrong, or Web Apps, which is wronger, and your listing is now filed next to things that have nothing to do with it.

This is not a small taxonomy quibble. It decides whether a page can ever rank, and it decides whether the people looking for your kind of software can find it.

What every directory gets wrong

We benchmarked ten launch directories in detail. Here is how they organize things.

applauncher.io and applauncher.app both use the same thirteen-item list, mixing platform (Chrome Extensions, Mobile Apps, Web Apps) with purpose (Marketing, Education, CRM) on a single axis. Uneed runs five categories plus a deep open tag layer. TinyLaunch has about twelve flat categories with no tag layer at all. Product Hunt has roughly twenty top-level categories with three to eight subcategories each. LaunchingNext captures a category field at submission and then never exposes it as a browsable hub, which across forty five thousand listings is the single largest piece of wasted surface in the benchmark.

MicroLaunch is the only one that comes close to getting it right. It runs two axes: Type (SaaS, Web App, Mobile App, Desktop App, Self-Hosted, AI Assistant) crossed with Industry. That is genuinely better, and it is still a type list rather than a platform list, so a tool that is macOS and Linux and CLI at once has to pick one.

The consequence is the same everywhere. Platform is a property with five or six plausible values per listing, and it is being forced into a field that allows one.

Three axes, kept apart

Here a listing carries three independent things.

Category, one of twelve, is what the app is for. Developer Tools, AI and Machine Learning, Productivity, Design and Creative, and so on.

Platform, multi-select from nine, is where it runs: web, iOS, Android, macOS, Windows, Linux, CLI, browser extension, self-hosted. A listing can hold as many as apply, because most real software does.

Tags, two to six from a curated vocabulary, are everything else: function, technology, attributes like open source or privacy first, and audience.

Keeping them apart is what turns platform into pages instead of noise. Nine platforms times twelve categories is 108 crosses, each of them a specific, low-competition, high-intent page. “Best CLI productivity tools” and “Chrome extensions for designers” are things people actually search for, and no benchmarked directory has a page for either, because none of them can generate one.

We gate those pages at five listings each, so a cross stays unindexed until it has enough to be worth landing on. A thin page is worse than no page, and the cautionary tale is right there in the benchmark.

The field nobody has

Look at a CLI tool’s listing on any of the ten directories and you will find a screenshot, a description, and a “Visit Website” button. What you will not find is the one line the reader actually wants, which is how to install it.

Not one directory in the benchmark carries an install_command field. Our research flagged it explicitly as a gap, and it is a strange one, because for a large class of software the install command is the tagline. brew install something. npm i -g something. uv pip install something. It is the fastest possible demonstration that the thing is real.

So a CLI listing here renders the install command as a copy-button code block directly under the hero, with the package registry named, plus room for a terminal demo recording and a link to the repository with its SPDX license. For self-hosted software the equivalent details are the ones that decide whether someone deploys it at all: the license, the repo, what it actually runs on.

Why this is the gap worth taking

A new directory cannot win the launch day. Product Hunt owns that, and it owns it so thoroughly that its featuring guidelines explicitly exclude directories from being listed on it, which is a useful reminder of who is setting the rules.

What Product Hunt does not do, because its taxonomy cannot, is give a self-hosted deployment platform or a terminal tool a page that is about being a self-hosted deployment platform or a terminal tool. Its rules allow those products. Its categories squeeze them into something generic, and then the permanent page underneath is generic too.

A .dev directory that treats the terminal as a first-class platform, renders install commands, shows package registries and licenses, and generates real category and platform crosses is doing something none of the ten competitors does. That is not a marketing angle. It is just the structure being correct, and the structure being correct is what makes the pages rank.

Two of our week one listings are here specifically because of this. Coolify is web and Linux, self-hosted, Apache-2.0, with 62,123 GitHub stars as of 2026-09-21 and a single maintainer funded by sponsorships. Firecrawl is web and CLI, with an oversubscribed 14.5 million dollar Series A in August 2025 and over 350,000 registered developers. Both of them get listings that say what they are, rather than listings that say “Online Tool.”

If your product lives in a terminal or on someone else’s server, submit it. The form has the fields.