Shipping Isn't Just Clicking Deploy: The DNS Setting That Almost Broke Email

The code was solid. Committed, working, ready. And GitHub had no remote configured for it yet, which meant the actual first step of shipping wasn't deploying anything. It was giving the project a home to deploy from.

A few commands later, the repo existed on GitHub, Vercel had it connected, and the site was live on a default Vercel URL. That part moved fast, faster than I expected for something I'd been building toward for weeks.

Then came the real test: pointing aiwithailabs.com at the actual build instead of leaving it live on a throwaway subdomain.

Here's the part that could have gone badly. Vercel offers two paths for connecting a custom domain, and they are not the same thing, even though they can look similar from the setup screen. Switching your domain's nameservers over to Vercel DNS hands over every single record on that domain, not just the website. That includes whatever's keeping your email working. The other option, adding specific DNS records instead of switching nameservers wholesale, leaves everything else on the domain untouched and only points the site itself.

I chose the second path on purpose, specifically because email needed to keep working through this. One wrong move on the first option and I could have taken down my own inbox while trying to launch a website, which is the kind of self-inflicted problem that's very avoidable once you know the two options aren't interchangeable.

While I was in there double-checking the live build against the actual PRDs, I found something small but worth naming: the site already had a day and night theme toggle that neither document had written down. It had gotten built somewhere along the way and just never made it back into the spec. Not a bug. Just documentation drifting the moment the build moves faster than the notes tracking it, which is a normal thing that happens and worth catching rather than ignoring.

The DNS setup, step by step

The lesson from this whole stretch: shipping isn't the moment you click deploy. It's the sequence of smaller decisions after that, the ones that don't show up in a demo but absolutely show up if you get them wrong. Repo before deploy. DNS records before nameservers, when anything else on the domain depends on staying intact. A pass to reconcile the build against the docs before calling it done, because the build will have moved past what's written down.

If you're about to point a custom domain at your own build for the first time, check which of the two DNS paths you actually need before you touch anything. If there's an inbox living on that domain, that choice matters more than it looks like it should.