Jedes Mal, wenn ich ein neues Projekt starte — eigenes oder für Kunden — mache ich das Gleiche. 15 Tabs öffnen. Den Namen bei Domain-Registraren, GitHub, npm, im App Store, bei Twitter eintippen. Abgleichen. Einen Tab vergessen. Nochmal öffnen. Wiederholen. Es ist der unangenehmste Teil der Namensfindung, und es wird nie schneller.
Also habe ich Hustle Namechecker gebaut. Ein Eingabefeld. Namen eintippen. Eine vollständige Verfügbarkeitsprüfung über Domains, Social-Media-Handles, Dev-Registries, App Stores und Markendatenbanken. Kein Account. Keine Preisseite. Kein Upsell.
Es ist die Art Tool, bei der man die Verfügbarkeit eines Startup-Namens prüft, seine Antwort bekommt und den Tab schließt. Das ist der ganze Zweck.
Was geprüft wird
Das Tool prüft sechs Kategorien. Man tippt einen Namen ein, drückt Enter, und alle Ergebnisse laden parallel.
Domains
Gängige TLDs, die für SaaS- und Startup-Produkte relevant sind. .com, .io, .dev, .app, .de und die üblichen Verdächtigen. Jedes Ergebnis verlinkt direkt zu einem Registrar, damit man sofort kaufen kann, wenn die Domain frei ist.
Social-Media-Handles
@deinname auf den relevanten Plattformen: X (Twitter), Instagram, LinkedIn, TikTok, YouTube und weitere. Vorab zu wissen, ob der Markenname auf jeder großen Plattform belegt ist, erspart die unangenehme Entdeckung beim Launch, dass man für immer @deinname_official sein wird.
Dev-Registries
Hier wird es für Entwickler besonders nützlich. NameChecker prüft npm, PyPI, crates.io, Homebrew, RubyGems, NuGet und mehr. Wer eine Library, ein CLI-Tool oder ein Open-Source-Projekt baut, für den ist der Paketname genauso wichtig wie die Domain. Erst nach dem Schreiben der README festzustellen, dass der Name auf npm vergeben ist — das ist eine besondere Art von Schmerz.
GitHub
Prüft sowohl die Verfügbarkeit als User/Organisation als auch, ob ein Repository mit dem Namen existiert. Wer plant, irgendetwas als Open Source zu veröffentlichen — oder auch nur will, dass github.com/deinname sauber aussieht — sollte das früh wissen.
App Stores
Durchsucht Apple App Store und Google Play nach existierenden Apps mit ähnlichen Namen. Keine Markenprüfung — aber ein nützlicher Realitätscheck, ob der Namensraum überfüllt ist.
Markenregister
Markendatenbanken lassen sich nicht zuverlässig automatisiert abfragen. NameChecker liefert Quicklinks zu den relevanten Datenbanken — EUIPO, USPTO, DPMA — damit man manuell suchen kann. Ehrlich darüber, was Automatisierung nicht leisten kann.
Warum das bauen, wenn es Alternativen gibt
Es gibt andere Namensprüfer. Namechk, Namecheckr, KnowEm. Die gibt es seit Jahren.
Die meisten sind langsam. Viele verlangen einen Account, bevor sie vollständige Ergebnisse zeigen. Einige verstecken Features hinter einer Paywall. Mehrere sind gespickt mit Affiliate-Links zu Domain-Registraren, was bedeutet, dass die „verfügbar"-Ergebnisse zum Kauf animieren sollen — nicht zur Genauigkeit.
Ich wollte etwas ohne Reibung. Kein Account. Kein Tracking über einfache Analytics hinaus. Keine Affiliate-Links. Kein „Upgrade auf Pro für vollständige Ergebnisse." Name eintippen, Antwort bekommen.
Der andere Aspekt: Die meisten bestehenden Tools konzentrieren sich auf Domains und Social Media. Sie prüfen kein npm. Sie prüfen kein PyPI oder crates.io. Wer als Entwickler eine Library oder ein CLI-Tool benennt, muss diese Registries zuerst prüfen — und bestehende Tools kümmern sich zuletzt darum.
Der Wochenend-Build
NameChecker ist eine Next.js-App. Der Stack:
- Next.js mit App Router
- TypeScript durchgehend
- Server Actions für die Verfügbarkeitsprüfungen (teils API-basiert, teils DNS-Lookups, teils HTML-Scraping)
- Deployed auf Vercel — ein zustandsloses Tool, keine Datenbank nötig
- Umami für datenschutzfreundliche Analytics
Die erste Version hat ein Wochenende gedauert. Kein „Wochenende" im Startup-Sinne, wo das drei Wochen Abendarbeit bedeutet. Ein tatsächlicher Samstag und Sonntag.
Die Architektur ist geradlinig. Das Frontend ist eine Formular-Komponente und ein Ergebnis-Grid. Das Backend ist eine Sammlung von Check-Funktionen — eine pro Service — die parallel auf dem Server laufen. Jeder Check liefert einen von drei Zuständen: verfügbar, vergeben oder Fehler (wenn eine API rate-limited oder nicht erreichbar ist).
// Vereinfachte Struktur einer Check-Funktion
async function checkNpm(name: string): Promise<CheckResult> {
const res = await fetch(`https://registry.npmjs.org/${name}`, {
method: "HEAD",
});
if (res.status === 404) return { status: "available" };
if (res.status === 200) return { status: "taken" };
return { status: "error" };
}
Die meisten Services sind Variationen dieses Musters. Eine bekannte URL anfragen, den Status-Code interpretieren. npm liefert 404 für Pakete, die nicht existieren. GitHubs API macht das Gleiche für User und Orgs. DNS-Lookups für Domains. Manche Services erfordern das Scrapen einer Suchergebnisseite — App Stores zum Beispiel — was fragil, aber funktional ist.
Das Ganze läuft ohne Datenbank. Kein State zu verwalten. Keine User-Accounts. Keine Daten zu speichern, sichern oder unter DSGVO-Gesichtspunkten zu bewerten. Zustandslose Tools sind unterschätzt.
Design-Entscheidungen, die zählten
Ein paar Entscheidungen haben das Endprodukt mehr geprägt als der Code.
Terminal-Ästhetik. Die UI nutzt eine Monospace-Schrift und einen Command-Line-artigen Input (~/hustle » your-idea-here). Das ist keine Dekoration. Es signalisiert, für wen das Tool ist — Entwickler und technische Gründer. Es setzt auch Erwartungen: Das hier ist ein Utility, kein SaaS-Produkt. Man nutzt es und geht.
Parallele Ausführung. Alle Checks laufen gleichzeitig. Die Ergebnisseite füllt sich, sobald jeder Check fertig wird, schnellste zuerst. Niemand will auf einen sequenziellen Crawl über 30 Services warten. Wahrgenommene Performance ist wichtiger als tatsächliche Performance bei einem Tool wie diesem — das erste Ergebnis nach 300ms zu zeigen, während der Rest über 2 Sekunden eintröpfelt, fühlt sich schnell an. Alle Ergebnisse nach 2 Sekunden Wartezeit zu zeigen fühlt sich langsam an, obwohl die Gesamtzeit identisch ist.
Keine Anmelde-Hürde. Das war die schwierigste Nicht-Entscheidung. Der Reflex ist, eine E-Mail-Erfassung einzubauen. „E-Mail eingeben, um Ergebnisse zu speichern." Das würde Leads generieren. Aber es würde auch Reibung zu einem Tool hinzufügen, dessen gesamtes Wertversprechen null Reibung ist. Ich habe es weggelassen. Das Tool verlinkt zurück zu CodeAttack. Das reicht.
Zweisprachig. Die Seite unterstützt sowohl Englisch als auch Deutsch, passend zur DACH-Startup-Zielgruppe, mit der ich arbeite. Kein großer Engineering-Aufwand mit next-intl, aber es verbreitert die relevante Zielgruppe.
Was ich über das Shipping kleiner Tools gelernt habe
Scope ist alles
Die ursprüngliche Idee beinhaltete ein „Name-Scoring" Feature — bewerten, wie brandable ein Name ist, basierend auf Länge, Aussprechbarkeit, Einprägsamkeit. Ich habe es gestrichen, bevor eine einzige Zeile Code geschrieben war. Scoring ist subjektiv. Es erhöht die Komplexität. Es lädt zu Diskussionen über die Methodik ein. Das Tool macht eine Sache: sagt dir, ob ein Name vergeben ist. Das ist eine Frage mit einer konkreten Antwort.
Die 80%, die funktionieren, schlagen die 100%, die nächsten Monat fertig werden
Manche Checks sind unvollkommen. App-Store-Suchergebnisse bedeuten nicht, dass der Name markenrechtlich geschützt ist. Ein DNS-Lookup kann nicht verraten, ob eine Domain geparkt, aber kaufbar ist. Das Tool ist ehrlich über diese Einschränkungen — es zeigt, was es verifizieren kann, verlinkt zu dem, was es nicht kann, und gibt sich nicht als rechtliche Einschätzung aus.
Die unvollkommene Version zu shippen und basierend auf tatsächlicher Nutzung zu iterieren war produktiver, als jeden Edge-Case vorab lösen zu wollen.
Dev-Tools müssen keine Produkte sein
NameChecker hat keine Preisgestaltung. Kein Premium-Tier. Keine Roadmap-Seite. Es ist ein scharfes Tool, das ein spezifisches Problem löst, und es verlinkt zurück zu CodeAttack als Demonstration meiner Arbeitsweise: schnell, fokussiert, keine unnötige Komplexität.
Nicht alles muss ein Business sein. Manchmal ist ein Tool ein Tool.
Die laufenden Kosten
Das Tool läuft auf Vercels kostenlosem Tier. Keine Datenbank, kein Storage, keine Background-Jobs. Die einzigen Kosten sind die Domain und Umami-Analytics (die auf bestehender Infrastruktur laufen).
Monatliche Gesamtkosten: ungefähr €1 für den Subdomain-DNS. Das war's. Ein nützliches öffentliches Tool für den Preis eines schlechten Espressos.
Wann man ein Wochenend-Tool bauen sollte
Das Muster funktioniert, wenn drei Bedingungen erfüllt sind:
- Der eigene Juckreiz. Man macht die Aufgabe schon manuell, wiederholt, und sie nervt.
- Der Scope ist begrenzbar. Ein Input, ein Output. Keine User-Accounts, kein komplexer State, keine Third-Party-Auth-Flows.
- Man ist mit „gut genug" einverstanden. Das Tool muss nicht jeden Edge-Case abdecken. Es muss im Normalfall Zeit sparen.
Wenn alle drei zutreffen: bauen. Nicht planen. Kein PRD schreiben. Kein Projektboard aufsetzen. Am Samstagmorgen hinsetzen, bis Sonntagabend shippen, und schauen, ob es jemand anderem nützt.
NameChecker begann als Scratch-my-own-itch-Tool. Es wurde zu etwas, das ich bei jedem neuen Projekt nutze — meinem und dem meiner Kunden. Beim nächsten Mal, wenn ein Name gesucht wird: namechecker.codeattack.io.