A custom domain sounds like one feature. For a new customer it can become several jobs: choose a name, locate the provider, obtain permission, apply records, and check that the result works. Dub's August 19, 2026 update addresses two paths through that work. Eligible Vercel or Cloudflare domains can use automatic configuration. People who lack DNS access can forward the required records to the person who manages them.
The current domain guide retains manual setup instructions and describes provider approval and ownership verification. It also warns that verifying the wrong domain can disrupt another site. The documented design therefore includes both a shortcut and a consequential boundary. We have not connected a domain to Dub or measured its onboarding completion rate.
Design for the person with the next permission
The transferable idea is that onboarding can continue across people. A founder may own the product decision while a contractor owns DNS. A marketer may prepare an integration while an administrator controls the key. A screen that assumes one person has every permission will produce an avoidable dead end.
For an AI product, map a comparable handoff before building a larger wizard. Perhaps a user can prepare a document collection but cannot approve its upload. Preserve a reviewable request containing the intended purpose, requested access, and exact next action. Do not include credentials or treat a forwarded request as approval. The recipient needs enough context to decide whether the work is appropriate.
Map three completion paths
- Write the direct path for an authorized operator. Show the target resource, the intended change, and the step that grants permission.
- Write the handoff path for someone without access. Produce a concise instruction packet with a stable resource name, the responsible role, and a way to check completion.
- Keep a manual path for unsupported providers or declined automation. Explain which parts the user must perform and which parts the product can verify.
- Define visible states for prepared, waiting for approval, verification pending, complete, and failed. Attach the next useful action to each state.
Review the paths with separate people acting as requester and administrator. Check whether the administrator can identify the target without another conversation. Then test cancellation, an unsupported provider, and a verification failure in an isolated environment. These are proposed checks, not a report of tests we ran against Dub.
Keep the first version narrow. A plain instruction card and a dependable state transition may serve the handoff better than a long setup sequence. Explain what can be undone and what requires another operator. Avoid promising that automatic setup is universal.
Reject the redesign if an unapproved request can apply a change, if secrets appear in a shareable packet, or if the completion screen celebrates before verification succeeds. Dub's dated release provides a recent product reference. It does not, by itself, establish that the update was widely discussed on X or that the same approach will improve another product's activation.