Why the rest were not listed
Every assessed listing that is not in the catalog, grouped by what stopped it. These add up to the 25,381 above.
- Removed from the catalog10,744
Withdrawn after listing — by request, or because the record turned out not to hold up.
- A store page with no project behind it5,744
The listing exists on a store or registry but carries no description, no working surface, or nothing that identifies a project.
- Reason not recorded4,408
Kept out before the reason was written down. These are the ones we cannot explain, and the count is here rather than folded into the others.
- Identity could not be resolved3,232
Ambiguous, a staging or mirror URL, or a surface that turned out to be a service rather than a project.
- Outside the covered window (retired)1,136
A rule this catalog no longer applies to new listings. It refused anything whose release date — or, failing that, the date we first saw it — fell before 2022. It was retired on 2026-09-02 because it was never applied evenly: whether a row met it depended on whether we had learned its release date yet, so apps of the same vintage landed on both sides. The rows counted here are still held out and clear as each is re-checked.
- Withheld under content policy117
Adult or otherwise restricted material. Assessed, recorded, not published.
Turned away before any of that
Most candidates never become a listing to assess at all. Over the last 30 days 179,763 candidate pages were stopped earlier, for these reasons. Separate from the figures above, which count listings that were assessed; the two do not add up and are not meant to. The window is 30 days because that is how long these decisions are kept.
- Writing about software, not software47,771
News stories, roundups, listing directories, company about-pages and link hubs. They describe products; this catalog tracks the products themselves.
- Read, and not a product45,687
The page opened and was legible, and what it turned out to describe was not software anyone could go and use.
- The page could not be opened30,675
Bot protection refused the request, or the address did not answer. Nothing about a page that cannot be read is verifiable, so it is turned away rather than guessed at.
- Reason not recorded30,230
Stopped before the reason was written down. Small, and counted here rather than folded into one of the families above.
- Excluded by standing policy15,582
Hosts and domains that are out by rule, plus material withheld under the content policy.
- Nothing running behind it yet9,818
A waiting list, a placeholder store entry, or a domain with no working product surface on it.
Qualifies for listing
A project generally qualifies when it has a stable public identity, a clear software surface, and enough public evidence for PulseGate to anchor and monitor it consistently.
- Public project URL
- Recognizable software identity or official store listing
- Enough corroborating evidence to avoid duplicate or low-trust inclusion
Does not qualify
Not every discovered URL should become a listing. PulseGate avoids listing thin, ambiguous pages, and pages that are not a project.
- Single marketing pages with no evidence of a project behind them
- Dead, suppressed, or clearly abandoned surfaces
- Non-software pages, generic company sites, mirrors, and clones
Public-facing requirement
PulseGate only lists projects that can be verified from public-facing surfaces. Private dashboards, closed betas without public identity, and software nobody outside the company can reach are out of scope.
Duplicate and canonical handling
Discovered URLs are resolved toward one canonical project whenever possible. Multiple URLs, stores, or mirrors may map to a single listing when the public identity is clearly the same.
Directional coverage caveats
Coverage is designed to be useful, not exhaustive. Entire categories or geographies can have less complete coverage than others, especially where public structured data is scarce.
How to report a mismatch
If a listing looks miscategorized, duplicated, stale, or clearly outside coverage rules, use Report an Issue and include the affected URL or slug together with any public evidence that helps verify the correction.
Contesting a decision
Every listing decision here follows from public evidence, so new public evidence is what changes one. Send the URL or slug and what the record should say, with something we can check — a store listing, a repository, a changelog, the project's own page.
Reports reach the operator directly as mail. There is no ticket number, no queue position and no promised turnaround; the honest version is that a person reads it and either the record changes or it does not. A corrected record is re-assessed against these same rules on its next pass, so a change holds without needing to be re-argued.
- What can change: category, canonical identity, the name a listing carries, whether it is listed at all
- Delisting your own project: send the request from a surface you control and it comes off
- What changes nothing: paying, asking often, or who is asking