Domain Launch Assistant

Turn a business idea into a launch-ready domain in one flow: AI brand names → real name.com availability & pricing → AI pick → trademark check → DNS readiness → sandbox registration.

Comment

Inspiration

Every founder hits the same wall on day one. What do I even call this thing, and can I actually get the domain for it? That one question sends you bouncing between an AI naming tool, a domain registrar, and some DNS dashboard, three separate tools for what's really just one decision you're trying to make. So we built Domain Launch Assistant to put all of that into one guided flow instead.

What it does

You describe your business in plain language and the app takes it from there:

  • Generates brandable names using Gemini, and actually explains the reasoning behind each one
  • Checks real-time availability and live pricing against name.com, across whichever extensions you pick (.com, .ai, .io, .net, .org, .co, .dev, .app)
  • Gives you an AI-recommended pick out of the available domains, with reasoning attached
  • Runs an automatic trademark (TMCH) claims check on every candidate that's available
  • Verifies the domain is DNS-resolution ready
  • Walks you through a sandboxed registration (this actually calls name.com's real Create Domain endpoint, just sandbox-scoped) with a WHOIS privacy toggle
  • Lets you set up A and CNAME records against the domain you just registered, and you can edit or delete them too
  • Spits out a launch report at the end summarizing the whole thing

It's all behind JWT auth, and you can also just sign in with Google, an account gets created automatically the first time, so there's no separate registration step to worry about.

How we built it

The backend is a Django monolith, API-only, split into apps by responsibility (accounts, launches, brands, domains, dns, tasks, core). Anything that depends on an outside provider (Gemini, name.com) runs through Celery, and the frontend just polls a task-status endpoint instead of sitting there blocked waiting on a slow API call. Postgres holds all the workflow state, and name.com stays the source of truth for actual DNS records, we never cache those locally.

One thing we were pretty deliberate about: the name.com integration uses two completely separate client instances. Production credentials handle search, pricing, and claims. Sandbox credentials (which are host-guarded, not just a settings flag) handle registration and DNS record changes. That way a "sandbox" action literally cannot hit a real billable endpoint by accident.

Frontend's React + Tailwind, and it only ever talks to Django over versioned JSON (/api/v1/). No provider credentials or business logic live on the frontend at all.

What we're proud of

Honestly, the fact that the whole pipeline, from idea to brand to checking real availability to sandboxed registration, runs on actual API calls the whole way through. Nothing's mocked for the demo. And that failure-discipline thing we mentioned (never turning a provider error into a fake positive or negative) is consistent across search, claims, and DNS checks, not just bolted onto one part.

What's next

Real, non-sandbox domain registration and billing is the obvious next step. We'd also like a more general DNS management surface, right now it's A/CNAME only in the UI even though the backend already supports MX/TXT/SRV etc, just not exposed yet. And caching for repeat availability lookups, Redis is already sitting there as our Celery broker, we just haven't wired it up for caching yet.

Longer term we're thinking about a country-aware business registration handoff too. Once someone's locked in a domain, we'd point them toward actually forming the legal entity (an LLC, for example) through referral partnerships with business-formation platforms, matched to whatever country they're in.

Built With

Share this project:

Updates

Submission history