How to Publish What You Built With AI: Step by Step
Press publish. On Zugo the project gets a live address at your-project.zugo.run straight away, and that link works for anyone you send it to, on any device, without an account. A custom domain is the next step rather than a prerequisite, and it sits on the paid plans.
The button is the easy part. What decides whether publishing goes well is the ten minutes before it and the two decisions after it, so this is the whole sequence rather than just the click.
What does publishing actually do?
It takes the version currently in your project and serves it at a public address. Before that moment the build exists as something you can preview; after it, the same thing exists as a URL other people can open.
Every Zugo build is booted in a sandbox before it reaches you, and a build that fails to open is reported as a failure rather than handed over. That lowers the risk of publishing a blank page. It does not remove it, and it says nothing about whether your prices are right or your contact details are current.
Publishing is also reversible in the sense that matters: the project stays editable. An edit costs 3 credits and republishing puts the new version at the same address, which means the correct strategy is to publish early and fix in public rather than polish privately for a week.
What publishing does not do is bring anyone. The address is a destination, not a route, and the first visitors always come from somewhere you put the link. That side of launch has its own answer in how to get the first visitors.
What should you check before you press it?
Six things, and all of them are faster to check than to fix after somebody has already seen the site.
| Check | Why it matters | How long |
|---|---|---|
| Open it on a real phone | Most first visits are mobile, and previews lie about scale | 2 minutes |
| Read every headline out loud | Generated copy is plausible before it is accurate | 5 minutes |
| Click every link and button | A dead nav item is the most common launch defect | 3 minutes |
| Confirm contact details | Wrong email or phone number wastes real enquiries | 1 minute |
| Check images are yours to use | Licensing is your responsibility, not the builder's | 5 minutes |
| Decide the one action a visitor takes | A page with three equal calls to action has none | 5 minutes |
Twenty minutes total, and it catches nearly everything embarrassing. The phone check is the one people skip and the one that finds the most, because a headline that fits a laptop can wrap into four lines on a handset. That whole question is covered in are AI-built sites mobile friendly.
The copy check deserves its own emphasis. AI-generated text is fluent by default and specific only when you insist, so read it as a stranger would and delete every sentence that could describe any business in your category.
How do you put it on your own domain?
Buy or use a domain you already own, then point a DNS record at the project and confirm it in Zugo. The record propagates on your registrar's schedule, which is usually minutes and occasionally hours, and no builder controls that clock.
Custom domains sit on the paid plans. Pro is $25 per month with 200 credits and Business is $99 per month, while the free tier publishes to the zugo.run address as normal. So the honest sequence is: publish free, decide the project is real, then attach the domain.
Do it before you start sharing links widely rather than after. Every link you post at the temporary address is a link you will want redirected later, and moving addresses after people have started bookmarking is avoidable work. The step-by-step version is in connecting a custom domain.
One practical note about email. A domain used for a website and a domain used for sending mail need different records, and adding one does not configure the other. If the project sends transactional email through Resend, that is a separate configuration on the same domain.
What do you connect after publishing?
Only what the project actually needs, and one at a time. Each connector is a short configuration step rather than a rebuild, but the first time you do one it takes longer than you expect, so budget around fifteen minutes each.
Supabase handles the database, sign-in and file storage, and it lives in your own Supabase account. Stripe handles payments and subscriptions, in your own Stripe account. Resend sends email. Google Analytics reports traffic. Vercel deploys to your own hosting account, and GitHub exports the source code to a repository you own.
The order that wastes least time is to publish on the free address first, check the site on a real phone, then attach the domain, and only then wire connectors. Reversing it means debugging DNS and webhooks while you are still deciding what the page should say.
Notice what that list implies about ownership. The data, the payments and the code all sit in accounts you control, so publishing through a builder does not put the important parts of your project inside it. That distinction is examined properly in is my data safe in an AI builder.
How is publishing a game different?
Not much, mechanically. A 2D browser game publishes to the same kind of address and opens in a browser like anything else, which is the shortest route from an idea to a link you can send someone.
The difference is in testing. A site is right when it reads correctly; a game is right when it feels correct, and that is only knowable by playing it. Jump height, spawn rate and difficulty are numbers you cannot judge by looking, so expect a round of edits after the first playthrough.
Touch is the other thing to verify deliberately. Keyboard controls that work on a laptop do nothing on a phone, so say in the prompt that the game must be playable by touch and then confirm it on an actual handset rather than in a resized browser window.
The honest boundary here: games built this way are 2D and run in the browser. That covers a lot, including the arcade formats most people want, and it does not cover 3D or native console and store builds without a separate wrapping step.
What does publishing not solve?
Three things, and expecting them from a publish button is the usual source of disappointment.
Traffic. A published site has no audience until you give it one. Publishing is the start of distribution, not the end of it.
Search ranking. Being live makes you indexable, not ranked. Indexing takes time and ranking takes content and links, on any platform.
Business approvals. Taking payments requires a Stripe account in good standing, and anything regulated needs its own paperwork. Software readiness and commercial readiness are different states.
What publishing does solve is real and worth naming: it turns a private idea into a public link the same day, at a cost measured in credits rather than weeks. Then the useful loop begins, which is showing it to people and fixing what confuses them. Build something small, publish it, and send it to ten people this evening at zugo.dev.