One last annoying thing before launch: Removing the ambiguity out of domain verification

I dread the last bit before launching an idea or a small project. If you've built one, you know the feeling. Everything is done, product works, design feels good. You're finally ready to share it with people, and then you remember there's one last annoying thing to do, attach your domain.

It sounds small but it sure doesn't feel small. You leave the product, open your DNS provider, copy records, wait for verification, refresh a few times, wonder if you did something wrong, and then somehow the most exciting part of shipping turns into the part where you're staring at DNS records and questioning your life decisions.

Context

Domain verification was one of the first features ever designed for Laravel Cloud, which makes sense cause you can't really have a product like Cloud without letting people connect their own domains. Cloud had grown a lot since then and when it became more mature, the edge cases became more visible, and the way we thought about this flow needed to mature as well.

I think we needed one vital thing: pre-planning.

People were entering the process without really knowing what kind of setup they needed and with domains that matters a lot. The path drastically changes depending on whether downtime is acceptable, whether the domain is already live somewhere else, whether Cloudflare is involved, whether the proxy is enabled, and whether the user needs zero-downtime verification. Based on those details the instructions and records the product surfaces are entirely different.

The real problem was ambiguity

Domain setup feels hard because products often ask people, in the name of simplicity, to act before helping them understand the situation they're in.

The main issue I discovered in the previous flow was that it was reactive. It would give people DNS instructions, then discover later that something about their setup needed a different path. That led to people ending up blocked without understanding why. We didn't surface enough pre-instructions nor validating errors after failure. From the user perspective all failures felt the same.

People did what the product asked and their domain still didn't verify. And now they had to guess if the issue was their DNS provider, propagation, the records, the domain itself, or Cloud. That's not a good place to leave someone. It also put a lot of weight on our support team.

Simply asking the right questions earlier

The main focus of my design was moving the important questions to the beginning.

Before showing any records or asking someone to open their DNS provider, Cloud now asks a few simple questions about how the domain is going to be used. The point of this step was to make the rest of the flow correct even if it's longer. A shorter flow that gives the wrong instructions is not actually simple because we'd just be delaying complexity and failure.

The product can guide users into the right path by asking those questions upfront.

Designing for recovery

The other piece of this that I cared about was recovery. Even with a better flow domain setup can still fail. Cloud can't control every part of that process, but it can control whether people understand what happened. The error states needed to become more specific and we needed to do a better job explaining where the setup broke.

If a domain is invalid it doesn't make sense to show configuration. If the verification window times out, we need to explain that clearly and guide people to restart after.

The way products handle errors matters because vague ones leave people stuck without a way back.

No more dead ends

The biggest difference in the new experience is that users are not dropped into a setup path without context anymore.

In short, they're given context when they need it through setup questions, configuration guidance and error states. That's the heart of good technical UX imo. The technical parts are not simple, but the complexity needs to show up at the right time, in the right amount, with a clear next step.

Domain verification will probably never be the most exciting part of launching an app, but it also shouldn't be so dreadful.