The Difference Between a Vercel Subdomain and a Real Home
Closing the gap from a working Vercel URL to a real, owned domain, and the DNS records that mattered.
AI with AI Labs had been sitting on a Vercel subdomain for a while. The homepage worked. The theme toggle worked. The Cowork page worked. Everything about it was functional. It just wasn't home yet.
A subdomain is a fine place to build. It's not a place to actually launch from. So I closed that gap: added aiwithailabs.com and www.aiwithailabs.com inside Vercel, then went over to Northwest Registered Agent, where the domain lives, to update the DNS records.
I want to name the exact sentence I kept in my head while doing this, because it's the part worth repeating to anyone about to do the same thing: one wrong DNS record and you can knock out your own email while chasing a website launch. That's not a hypothetical. It's the actual risk sitting in the same settings panel as the change you're trying to make, one field away from the one you meant to touch.
Once the records verified, I updated the environment variable pointing at the domain and redeployed under the real one instead of the Vercel default.
While I was already in the DNS and deployment weeds, I documented the design system properly, since it hadn't been written down in one place yet. Violet for primary actions. Lime and coral for the free and paid tags. Electric blue for links. A hero gradient running orange to pink to violet. Small thing to do while already in there, and it meant the next build session had a real reference instead of me eyeballing old screenshots for the right shade of purple.
The DNS setup, step by step
0 / 5 done
Push your finished code to a GitHub repo, connect it to Vercel
In Vercel, add your custom domain (and the www subdomain)
Under Project Settings → Domains.
Choose "DNS Records," not "Vercel DNS"
This keeps your existing nameserver and only adds the specific records Vercel needs.
At your registrar, add the A record (apex) and CNAME record (www)
Whatever Vercel gives you. Do not touch any existing MX or email records.
Wait for Vercel to show "Valid Configuration"
Then update your NEXT_PUBLIC_SITE_URL env var and redeploy.
This pairs directly with the DNS story from getting the site live in the first place: same category of risk, same kind of care required, just one step further down the path from "it works" to "it's actually mine."
If you're still running your own project off a platform subdomain, here's the question worth sitting with: what is still living on localhost, or on someone else's URL, that deserves its own home?
Go deeper
Shipping Isn't Just Clicking Deploy: The DNS Setting That Almost Broke Email →
What actually happened getting AI with AI Labs from finished code to a live domain.
The Site Reverted to a Blank Word Document: Here's How the Actual Bug Got Found →
Diagnosing before touching anything, and turning an emergency fix into a real design decision.
Get new guides and builds in your inbox
No noise. New artifacts, skills, and lessons when they drop — and early access when agents launch.
Want a full structured path instead of one-off guides?
That's Learn AI with AI — a sequenced course that takes you from zero to building real things, with community and accountability built in.
Check out Learn AI with AI →