NameVetta
Name checkers love a row of green ticks, but most of those checks cannot prove a name is free. NameVetta has no 'available' status anywhere. Every source resolves to one of five evidence states, and a source that could not be checked lowers coverage instead of counting as clean.
- Type
- Research engine
- State
- Live
- Role
- Solo, end to end
- Next.js 16
- React 19
- TypeScript
- Supabase
- Zod
- Vitest
- Playwright
At a glance
- 50+ sources checked, including 37 TLDs over RDAP
- A 116-case benchmark gates CI
- Public status page with per-source success rates
What I owned
Solo project. The source adapters, the similarity engine, scoring, the Postgres schema and RLS, the Next.js app, and the benchmark and source-health jobs in CI.
Decisions, and what they cost
Uncertainty is enforced in four layers, not one
A rule that lives only in the UI erodes the first time someone writes to the database directly. The 'never claim more certainty than the source provides' rule is held by Zod schema invariants, by matching Postgres CHECK constraints, by scoring (an unverifiable source contributes null, never 0), and by presentation, where unverified results render neutral grey with a question mark rather than green or amber.
What I gave upReports look less reassuring than a checklist of green ticks. A name can come back with a good score and 40% coverage, and the report says exactly that instead of rounding it up.
Score and coverage are two numbers, never blended
The Digital Viability Score is weighted by what you are naming: a crowded npm namespace matters a lot for a developer tool and barely at all for a restaurant. Research Coverage reports how much of the intended research actually completed. Duplicate matches count once, and one reliable conflict cannot be averaged away by clear results from the same source group.
What I gave upTwo figures to read instead of one. Two names with identical evidence get identical scores, even when that makes a comparison look unhelpfully flat.
A source stays automatic only while it can answer the question
Before a registry ships, a known-taken and a known-free name must produce different answers from it. Instagram, X, TikTok and Threads all return 200 OK for handles that do not exist, and GitLab's user API answers 200 either way, so none of them is reported as free. An unexpected 403, 429 or 500 resolves to unable_to_verify, and a test pins that rule.
What I gave upEleven social platforms are manual-only, which pushes work back onto the user. I would rather hand them a checklist than a false 'clear'.
Where it went wrong
A source that found a conflict for every name it ever saw
CPAN was probed against metacpan.org/pod/{name}. That URL answers 200 for a module nobody has ever published, so the source reported a confirmed conflict on every name. Slack failed the other way: every existing workspace answered 403 with a browser-not-supported page, which is a block, not a verdict. CPAN now asks the MetaCPAN API, Slack became manual, and regression tests cover both directions, because a probe verified only against a taken name is not verified.
Known limitations
- No trademark or legal clearance. Trademark Assist prepares variants, likely Nice classes and registry links; you run the search yourself.
- Web presence checks use Tavily's free 1,000 credits a month, one request per Deep Check, cached for 30 days.
- Scans do not survive navigating away yet; realtime transport is not built.
Where it stands
Live on free tiers. 37 TLDs over RDAP with DNS fallback, package registries from npm to Hex and CRAN, app stores, company registers and profile probes. A 116-case quality benchmark gates CI, /methodology is generated from the same manifest that runs at request time, and /status publishes each source's real success rate over the last 24 hours.