Custom Domain for Your Waitlist: The Authority You Build Elsewhere Never Transfers

Launching a waitlist on a shared platform subdomain is the default, because it is free and takes zero configuration. For the first week that is the correct trade — you are testing whether the idea survives contact with strangers, and domains are procrastination in that window.

After that week the trade inverts, and it inverts quietly. Nothing breaks. You simply begin accruing value to an address you do not own.

Move to your own domain as soon as the idea survives its first hundred visitors. Three things are at stake, and they differ in how recoverable they are — which is the part worth understanding before you decide it can wait another month.

Search authority accrues to the domain, and migrating forfeits most of it

This is the expensive one, and it is invisible while it is happening.

Every link your waitlist earns — launch coverage, a mention in a newsletter, someone's roundup post, a forum thread — passes authority to the domain hosting the page. If that domain is not yours, you are performing unpaid SEO work for your platform vendor.

The damage shows up at migration. When you eventually move to your real site, every external link points at the old address. A redirect passes a fraction of the original value, not all of it, and only for as long as the platform maintains the redirect. Links you never learn about simply break.

The compounding runs the wrong way, too. Search authority is roughly cumulative over time, so a year on a shared subdomain is not a year of neutral parking — it is a year your real domain spent at zero while an alternative accumulated.

There is a cheap fix that most founders miss: use a subdomain of the domain you will actually keep. A waitlist at join.yourproduct.com accrues authority to yourproduct.com, which means the value lands where you need it and you can retire the subdomain later without losing anything.

Email deliverability depends on a domain reputation you cannot control on shared infrastructure

The second cost is not recoverable either, and it is the one that bites at launch.

Sending from a domain you own, with SPF, DKIM and DMARC configured, means your sending reputation is yours. It builds slowly, it reflects your own behaviour, and it is portable.

Sending from a shared platform domain pools your reputation with every other user of that platform. Someone else's aggressive campaign moves your mail to Promotions. You have no visibility into it and no lever to pull. For a launch email — the single highest-stakes send of the entire project — that is an unnecessary dependency on strangers.

This matters most on the one send that cannot be repeated — the launch email. Deliverability failures are also silent: there is no bounce, no error, no dashboard warning. Your open rate is simply lower than it should be and you attribute it to list quality.

Trust is read from the address bar before any of your copy is read

The third cost is recoverable, and smaller, but it is real and it arrives first.

The URL is the first credibility signal a visitor processes, ahead of your headline, your design and your social proof. A page at yourproduct.com reads as a company. The same page at platform.com/yourproduct reads as an experiment someone is running.

For a low-stakes consumer signup the gap is modest and often irrelevant. For anyone you will later ask for money, for payroll data, or for a business-critical dependency, it is not. The visitor is making an implicit judgement about whether you will still exist in eighteen months, and renting your address is evidence against.

Unlike the first two costs, this one resets the moment you migrate. The visitor who bounced does not come back, but the next one sees the real domain.

The configuration is two DNS records and ten minutes

The reason this gets postponed is an assumption that it is fiddly. It is not.

Point a CNAME at the platform, add the verification record, wait for propagation. Certificates are issued and renewed automatically. There is no ongoing maintenance and nothing to monitor. The whole operation fits comfortably inside a coffee.

The reason to do it early rather than eventually is that the cost of postponing is not flat — it grows with every link you earn. Migrating a page with three inbound links costs nothing. Migrating one with two hundred, accumulated over a launch cycle, forfeits a meaningful share of authority permanently and breaks an unknown number of references you will never find. The work is identical in both cases; only the loss differs. That asymmetry is the entire argument for doing it in week two rather than month six.

Two decisions are worth thinking about for a minute. Use a subdomain of your real domain rather than a separate one, for the authority reason above. And decide the subdomain name with the eventual migration in mind — join and early both age well; waitlist becomes a lie the moment you launch.

When renting the address is still the right call

One case genuinely justifies the default. If you are validating three ideas in parallel and expect to kill two, buying and configuring domains for hypotheses is procrastination wearing a productive hat. Use the shared subdomain, learn which idea survives, and move that one.

Everything else — anything you have told a customer about, anything you have linked to publicly, anything you intend to charge for — should be on a domain you own before the links start arriving.

Connect your domain now, before the first link lands. Add a CNAME, verify, and the certificate is issued for you. Custom domains are included on Pro, along with the branding removal that makes the address bar and the page tell the same story.

The links you earn next month are the ones you cannot get back.