AI App Builder With a Custom Domain: How It Connects

Yes. A project built in Zugo publishes to an address like your-project.zugo.run, and your own domain attaches to that same project and becomes its main address, while the original keeps working. You buy the domain from a registrar yourself, because Zugo does not sell domains. Connecting one costs no credits: credits pay for builds and edits, not for addresses.

Why move off the zugo.run address at all?

A subdomain like your-project.zugo.run does one job, and it does it well: it makes a working project shareable the minute it exists. For testing an idea, showing a client, or dropping a link into a chat, that is enough, and there is nothing to improve.

Your own domain starts to matter when the address stops being a technical detail and becomes part of the product. A name you read out over the phone. A link in an ad you are paying for. An email address on the same domain. In all three situations somebody else's subdomain reads as temporary, however good the site behind it is.

There is a slower reason too, and it is the one people notice about a year in. The domain is the only part of a project that is fully yours from day one and travels anywhere. Change the builder, change the host, change the agency: the address survives, and so do the links and the search positions that accumulated against it. Starting on a name you own is cheaper than moving to one later.

How does connecting a domain work, step by step?

The sequence looks the same at almost every host, and Zugo is not an exception.

Step five is the only one that happens outside Zugo. Registrar panels all look different, but the section you need is almost always called "DNS" or "Manage records". You paste in what the builder gave you and save.

After that you wait. DNS changes do not spread across the internet instantly, and that is a property of DNS rather than of any particular builder. Zugo states the ceiling plainly in the publish dialog: DNS can take up to 24 hours to land. While you wait, the old address keeps working, so the project is never offline.

The most common failure is editing DNS in the wrong place. If you bought the domain at one company but its nameservers point at another, the records live at the second one. Check which nameservers are authoritative before you start typing, and you avoid the confusing hour where a correct record has no effect.

What is the difference between the two addresses?

More than how the browser bar looks, though less than people expect in terms of the site itself. Same pages, same speed, same behaviour.

The practical conclusion is simple. While you are still testing whether the idea works, the subdomain is enough and spending an evening on DNS is a waste. Once people are being asked to trust the page with money or contact details, the domain pays for itself with the first ad placement.

What does it cost?

Two separate sums get confused here, so it is worth splitting them.

The first is the domain. You buy it from a registrar for an annual fee, and the amount depends on the extension and the registrar. Zugo has nothing to do with that payment and does not trade in domains.

The second is the work inside the builder, which is measured in credits, and connecting a domain does not touch them. Credits go to generation: a build costs 6 credits, an edit costs 3, and a multi-page platform costs 12 for the first three pages plus 3 for each page after that. Hi-Fi mode doubles both: a build is 12 and an edit is 6.

The plans are short to describe. Free comes with 5 credits, Pro is $25 per month for 200 credits, and Business is $99 per month for 800. Two hundred credits works out to roughly 16 full platforms, or 33 builds, or 66 edits, if you spend them on one kind of action. Worth noticing before you sign up: 5 free credits is less than the 6 a single build costs, so the free tier is a look around the interface rather than a finished project. The arithmetic with worked examples is in AI app builder pricing.

How do you pick a domain you will not want to change?

Domains get changed reluctantly, because moving resets the links you earned and confuses everyone who memorised the old address. Five minutes of thought here saves a year of small annoyances.

Short beats long. The address gets dictated over the phone, printed on cards, and typed from memory. Every extra word raises the odds that somebody lands somewhere else.

Avoid anything that cannot be spelled out loud once. Hyphens, digits and doubled letters have to be spelled letter by letter every single time you mention them. If a name can be heard two ways, you will be explaining it for the life of the project.

Do not encode things that change. A name built around a street address stops being true at the first move, and one with a year in it expires on schedule. A company or service name lasts longer.

Check availability in several extensions at once, and check the same name on the social platforms you plan to use. A good name in a less obvious extension usually beats an awkward name in the obvious one. Finally, check that the name does not collide with somebody's trademark. That is the only problem on this list that a lawyer solves rather than a move.

What else belongs on your own domain?

A domain usually drags three neighbouring decisions along with it, and it is easier to make them at the same time.

Analytics. While the address is temporary, the numbers say very little, because most of the traffic is you. On a permanent domain it is worth connecting Google Analytics straight away so the first weeks are not lost.

Email. A mailbox like hello@yourdomain is set up at your registrar or a mail provider, not in the builder. A separate job is email sent by the project itself: confirmations, notifications, replies to a form. Resend connects for that, and mail sent from your own domain reads as more trustworthy to the person receiving it.

Payments. If the project sells anything, Stripe connects to it. Here the domain stops being cosmetic: a checkout page on somebody else's subdomain costs you trust at the exact moment a card number is being typed. The broader question of which address to use when is covered in can I use my own domain with an AI website builder.

What if the address is already on printed cards?

Sometimes the domain gets connected not to a fresh project but to one people already know by its zugo.run address. The order of operations matters more in that case.

Connect the domain first and confirm the project opens on both addresses. Nothing has moved yet: you simply have two doors into the same project, and no existing link is broken.

Then change the address everywhere you control it: email signature, social profiles, ad campaigns, anything going to print. This is the slowest part and none of it is technical.

Next, update analytics so the data for the two addresses does not split into halves you cannot compare. If there is no analytics yet, a move is a good excuse to add it.

Only then decide what to do with the old address. Leaving it working is simpler and safer: it bothers nobody, and anyone holding the old link still arrives in the right place. The reverse order, switching the old thing off before the new one answers, produces a few hours of downtime on precisely the day you announced the move.

What should you not expect from a custom domain?

Three honest limits.

A domain does not improve the content. A weak offer reads the same on any address, and a move is not a substitute for rewriting the page. Before you publish, it is worth checking the thing itself: every build is booted in a sandbox before delivery, and one that fails to open is reported as a failure rather than handed over, but that only tells you the page loads, not that the prices on it are current.

Zugo does not manage your domain. The registrar, the renewal, the DNS records and the mailboxes stay in your hands. That is a feature from the ownership side and a chore from the daily side: nobody else will remember the renewal date.

Switching is never instant. Time passes between saving a record and the site answering on the new address, and no platform can speed that up. Connect the domain before the campaign starts, not an hour before it goes live. The same patience applies to the product underneath: Zugo does not replace a development team on a complex product, and very specific business logic arrives through follow-up edits rather than one perfect prompt.

Where to start

A sensible order is to build first and buy the name second. Describe the project, look at it on the zugo.run address, edit it until it is worth showing, and only then pay a registrar. The reverse order tends to produce a paid domain with a draft sitting behind it for six months.

You can walk the whole path, including what the publish step actually does, in how to publish what you built with AI. And if you want to see the first address appear before deciding anything about the second one, start a project at zugo.dev: the zugo.run address is issued automatically, so the domain decision can wait until you are looking at something real.