How we review every submission

Most directories will not tell you why you were rejected. BetaList says so openly in its own FAQ: thousands of submissions a month, no individual feedback. applauncher.io has no published rejection policy we could find at all. From the maker’s side that is the worst possible outcome, because you cannot fix what you were not told.

So here is the whole process, including the list of things that will get you declined, written down before you submit rather than after.

The bar

An app gets listed if all of this is true. It is live and usable today, not a waitlist and not a demo video. It sits on a domain the submitter controls, which rules out free hosting subdomains and listings that only point at an app store page. It has a landing page that explains what it does. It has a working install or signup path. It has at least one real screenshot. And it has three to eight written features.

That last one is the completeness gate, borrowed from Peerlist, where a project that is not one hundred percent complete simply fails to launch. It is the cheapest quality control available: nobody spamming fifty directories in an afternoon writes six features per submission.

What happens after you submit

You paste a URL, we crawl it, and you edit a pre-filled draft with no account. Entering your email sends a magic link, and clicking it both verifies the email and submits the listing. From there the states are:

in_review. Your listing is in the queue. Free submissions are reviewed inside thirty days and get a launch date fourteen to thirty days out. Fast Track and above are reviewed within twenty four hours.

changes_requested. Something specific is wrong and fixable. You get a reason code, a free-text note saying what to change, and your edit link. Resubmitting puts you back in the queue rather than at the end of it.

scheduled, then live. Approved, with a date. On your date the listing enters the launch window for a week, competes for votes, and then becomes a permanent published listing that no longer moves.

rejected. Declined with a named reason code. The page 404s rather than lingering as a noindex ghost.

There is also a quarantine state for anything the spam checks flag, which a human clears or rejects. Nothing is ever auto-rejected by a machine.

The thirteen reason codes

Every rejection carries exactly one of these, and they are all published on the submission guidelines page.

• not_live The product is not usable yet.
• waitlist_only There is a signup form but no product behind it.
• no_own_domain A free hosting subdomain, or an app store link with no site.
• duplicate This app is already listed. We merge and redirect rather than list twice.
• thin_content The landing page does not say what the product does.
• is_directory_or_template Directories, templates and boilerplates are out, including ones a lot like this site.
• is_course_or_ebook Information products are out.
• affiliate_or_resell A storefront for someone else’s product.
• adult_or_illegal Self-explanatory.
• broken_site A 4xx or 5xx, a parked page, or a site that will not load.
• saturated_category We already publish a lot of this exact thing this month. Uneed cites the same reason as its most common decline, and it is the only code on this list that is about us rather than about you. Resubmit later.
• low_craft The product works but the execution does not clear the bar.
• vote_manipulation Bought, traded or solicited upvotes. This also removes an already-published listing from the leaderboard.

Note what is not on the list. Being small is not a reason. Being free is not a reason. Being a CLI tool, a self-hosted server or a browser extension is very specifically not a reason, since those are the listings this directory was built to carry properly.

Paying does not change the answer

The same person applies the same bar to every tier. What a paid tier buys is speed, placement and, at the top tier, editorial writing.

If we reject a paid submission, it is refunded in full, automatically, and the refund confirmation arrives in the same email as the reason code. You do not have to ask, and you do not have to read the terms page to find out that you can.

This rule exists because the alternative destroys the product. Uneed’s published policy is that paid launches are never declined. That is a coherent business decision and we understand why it exists, but it means the review only applies to people who did not pay, which means the listing quality signal only applies to people who did not pay, which means the badge means less for everyone. We would rather refund the money.

Anti-spam without accounts

Since there are no accounts at launch, the checks sit elsewhere: mandatory email verification with disposable domains blocked, a submission-time crawl that rejects dead and parked and thin pages on the spot with a plain-English reason, auto-quarantine for domains under fourteen days old, rate limits of one submission per email per week and two per domain ever, duplicate detection on domain plus name plus tagline similarity, a honeypot, a minimum time-to-submit, and Turnstile.

One thing we deliberately did not add is an interstitial bot wall. LaunchingNext runs one, and during our own research it blocked two legitimate fetches of its submission page. A wall that stops a researcher reading your form is stopping buyers too.

If you disagree

Reply to the rejection email. A reason code is a starting point for a conversation, not a verdict from a machine, and if we got it wrong we would rather find out from you than not find out at all.