domainsearcher.app scores domain names instead of just listing them

The point is the ranking, not the list of names

Most domain tools stop at availability, and the readme says this one helps you decide instead. The flow is the whole pitch. You describe your startup idea, you get 60 creative domain name candidates, the app checks real-time availability across the TLDs you care about, and each name is scored on six dimensions that you weight yourself so you can rank names objectively. Each of the sixty names then gets a breakdown, and the readme's table is the clearest statement of what each score means. LEN measures length, where 5 characters is a perfect 10, and it is computed. PRO is pronounceability, whether it flows naturally out loud, and it is AI-scored. MEM is memorability, the question of whether someone would remember it tomorrow, also AI-scored. BRD is brandability, whether the name is unique, ownable and not generic, also AI-scored. ZON is the zone score, the fraction of your chosen TLDs that are available, computed. FIT is how well the name evokes your specific app idea, AI-scored. Weights are adjustable per dimension, and the defaults are FIT at 5 with the others at 1 or 2, which tells you the tool assumes fit matters more than the rest. The interesting engineering decision is in how the AI calls are batched.

One AI call for four scores, two scores computed locally

PRO, MEM, BRD and FIT are all scored in a single AI call once you enter an app description, while LEN and ZON are instant local computation. That split is a deliberate design decision and it shapes both the cost and the latency of the tool. A single call means the model sees the whole set of candidate names and the app description at once, so the scores are relative to one another rather than absolute judgements made in isolation. It also means the scoring step is one request rather than one per candidate, which is the difference between a feature that feels instant and one that does not. The consequence for a reader is that the AI scores are only as good as the description you give. The app description is what FIT is measured against and what informs the other judgements, so a vague description produces scores that look precise and are not. The computed dimensions have no such dependency. LEN is arithmetic on the string and ZON is a count of available zones, so they are reproducible and free, which is also why they are the ones the readme lists as computed rather than AI-scored. The scoring is a ranking aid over sixty candidates, and the ordering depends on a blend of a deterministic measure and a model judgement.

Two-stage availability checking exists because registries lie

The availability check is the part with real engineering in it, and the readme explains the shape. There is a two-stage check per domain, and the stated reason is that it catches false negatives from unreliable registries, with .io, .ai and .co named as the culprits. The first stage is RDAP, a registry lookup through rdap.org, where a 200 means the domain is taken and a 404 means unconfirmed rather than available. The second stage is a DNS-over-HTTPS A-record lookup against Cloudflare at 1.1.1.1, where NXDOMAIN means the domain is available and an NS or SOA record in the Authority section means it is taken. The ordering matters. A registry that answers incorrectly can make an available domain look taken, and a second, independent check catches that. The cost is two network round trips per domain instead of one, and the reward is fewer false negatives in exactly the TLD extensions that are most often misreported. Both endpoints are CORS-enabled, so the whole thing runs entirely in the browser with no proxy, which is the reason the project can ship as a static site with no backend at all.

No build step, so serving the folder is the whole install

There is no build step, and the run locally instructions are correspondingly short. You serve the repository root over HTTP:

npx serve .
# or
python3 -m http.server 8080

Then you open http://localhost:8080. The readme is explicit about the constraint that catches people, that you must use an HTTP server and not the file:// protocol for the ES modules to work, which is a consequence of the app being plain ES modules with no bundler. The technology list in the readme confirms the shape. Static HTML with vanilla JavaScript as ES modules, no build step, RDAP and Cloudflare DoH for the two-stage availability check, Groq or OpenAI or Anthropic for generation and scoring, localStorage for all persistence with no backend and no account, and GitHub Pages for hosting. The repository layout matches. There is an index.html, a guide.html, a js/ directory, a privacy.html and a terms.html, plus a CNAME file for the custom domain, a robots.txt, a sitemap.xml and an llms.txt, which is a file some tools read to describe a site's content. There is also an openapi.yaml, so the service's API is described even though the app itself has no backend, and a scripts/ directory.

Favorites, weights, quick check and a snapshot button

The interface has a specific set of affordances, and the readme walks through them as a numbered flow. You type your startup idea in the description box, select TLDs by toggling .ai, .com, .io, .app, .dev and others, and click Search Domains, at which point names stream in as each one is checked rather than appearing all at once. You star the domains you like, and they appear in the Favorites scoring panel. You enter your app description and click Score AI, at which point PRO, MEM, BRD and FIT all update in one call. You adjust the weights to match your priorities, with FIT set to 5 by default and the others at 1 to 2. Two features are worth calling out. Quick Check takes any single domain stem and checks synonyms plus all zones instantly, which is the answer to the moment when you have a name in mind but not a full idea. Save and Clear snapshots a favorite set so you can restore it later, which is what you want when you are comparing several batches of candidates over a week. There is also an AI word-associations feature, where each favorited domain gets three word-associations reflecting both the name stem and its TLD meaning, .ai as artificial intelligence and .io as developer tool for example, and a refresh control that regenerates them from a custom prompt.

A bundled key in the browser, which is the sharpest edge here

The API key handling is the part a careful reader should look at first. The tool ships with a bundled Groq key, on the free tier, with no setup needed, and that is what makes the no-signup promise true. To use your own key or switch providers, you paste it in the AI provider row at the top of the search form, and keys are stored in the browser's localStorage only. The provider table covers three options with their key prefixes. Groq is the recommended one with the gsk_ prefix, OpenAI uses sk-, and Anthropic/Claude uses sk-ant-, each with the console URL where you obtain it. A bundled key inside a public static site is a shared resource by definition, so its quota and its abuse are exposed to anyone who loads the page, and the readme is candid that it is a free tier with no setup needed. The privacy posture otherwise matches what the readme claims, with no backend, no account and localStorage for all persistence. The repository also carries privacy.html and terms.html as separate pages. A related point is the licence, which the readme badge marks as MIT, while the project record for this repository lists the licence as unknown, so the file itself is the thing to read before you reuse the code.

Editorial conclusion

domainsearcher-app is worth using for the narrow job it does well, which is turning a vague startup idea into a shortlist of names with a measured reason to prefer one over another, since the weighted scoring is the part most availability-only tools leave to taste. It is the wrong tool for anything requiring trademark or legal clearance, because the scores are about memorability and pronunciation rather than rights, and the availability check is a DNS and registry lookup rather than a purchase guarantee. Verify first that the availability result you act on was confirmed by the second stage rather than left unconfirmed, since a 404 from RDAP is treated as unconfirmed rather than available, and check the scoring weights before trusting a ranking. The last push was on 2026-10-02 and the repository publishes no GitHub releases.

Frequently asked questions

Official sources

1. Issues
2. Project website
3. README
4. vasilytrofimchuk/domainsearcher-app on GitHub