Zugo Verified Builds: What 'Verified' Actually Means
A verified build on Zugo is one that has actually loaded and rendered in an isolated sandbox — not one that merely looks finished. When Zugo's AI builder finishes a game, site, or app, it doesn't hand you raw code and hope for the best. It boots the project in front of you, watches whether the page renders and the loop advances, and only marks the build verified if it does. A game goes further: it is compiled and repaired before it ever reaches your screen.
That one word changes how you read the result. "Done" from most code generators means "the model stopped writing." "Verified" on Zugo means "this ran."
What does "verified" mean on Zugo?
Anyone who has generated code with AI knows the standard failure mode: the output looks plausible, you open it, and you get a blank screen. A missing import, a typo in a component name, a runtime error on line one. The model was confident; the browser was not.
Zugo closes that gap with a sandbox check. Before a build reaches your screen, it goes through two hard gates:
- Load. The project boots in an isolated sandbox. If it crashes on startup, it does not pass.
- Render. The sandbox confirms the page actually draws something. A server that starts but paints nothing is not a working app.
Only a build that clears both gates gets the verified label. If it fails, you don't get a green checkmark on a broken app — the agent keeps working instead of shipping the failure to you.
For context, here is what Zugo is in one paragraph:
Zugo (zugo.dev) is an AI builder: you describe an idea in plain language, and it assembles a working 2D game, landing site, app, or multi-page platform with database, auth, payments, and AI features. Simple builds arrive in about a minute; complex platforms take a few minutes. Every build is verified — loaded and rendered in a sandbox, with the verdict shown to you.
If you're new to this way of working, what is vibe coding covers the broader idea of building by describing instead of typing code.
What gets checked at each stage?
| Stage | What Zugo checks | What you see |
|---|---|---|
| Generation | Code is assembled from your prompt (or from a Plan mode plan) | Live process log entries as files are created |
| Sandbox load | The project boots without fatal errors | Build status while the check runs |
| Render check | The page actually renders in the sandbox | The verified label on the finished build |
| Deep builds | Each major part of a multi-page platform completes | Checkpoints ticking off, one per stage |
The point of the table is the order. Verification is not a report you read after the fact. It sits between generation and delivery, so unverified output never becomes your problem.
How do checkpoints work on deep builds?
A prompt like "a landing page for a dog-walking service in Austin with a booking form" is one unit of work. It builds, loads, renders, done — usually in about a minute.
A prompt like "a booking platform for a nail salon with client accounts, an admin calendar, and Stripe deposits" is not one unit of work. It's auth, a database schema, several pages, a payment flow, and the wiring between them. Zugo breaks builds like this into checkpoints, and you watch them complete one by one: data model in place, auth working, pages rendering, integrations connected.
Checkpoints matter for two reasons. First, progress is visible — a few minutes of building feels very different when you can see what's finished versus staring at a spinner. Second, verification happens per stage, not just once at the end, so a problem in the admin calendar doesn't silently poison everything built after it.
What does the live process log show?
Alongside checkpoints, deep builds stream a live process log: what the agent is doing right now, which files it's creating, what it's wiring up, what it caught and corrected along the way. It reads like watching a developer's terminal over their shoulder, minus the need to understand every line.
The log is also an honesty mechanism. An AI builder that hides its process asks you to trust the output blindly. One that shows its work lets you see exactly where the time went when a complex platform takes a few minutes instead of one.
Where does Plan mode fit?
Verification checks the build. Plan mode checks the intent before the build starts.
In Plan mode, Zugo lays out what it's going to build — pages, features, data, integrations — and you adjust the plan before any code is generated. For a quick game prototype you'll rarely need it. For a multi-page platform, agreeing on the plan first means the checkpoints that follow are checkpoints toward the right thing.
Workspace skills extend this in the other direction: they're named instructions the agent remembers across builds. If every project in your workspace should use your brand colors or write copy in a specific tone, you say it once as a skill instead of repeating it in every prompt.
The full prompt-to-app workflow, including how to phrase requests that build well, is covered in how to build an app with AI.
What doesn't verification catch?
Being precise about the guarantee matters more than making it sound bigger than it is.
Verified means the build loaded and rendered. It does not mean:
- Your business logic is correct. If you asked for a 15% discount and meant 25%, the app will render perfectly and apply the wrong number.
- The game is fun. A verified platformer is a running platformer. Whether the jump feels right is a design question, and you'll want to playtest it.
- Every user flow is exercised. The render check confirms the app draws; it doesn't click through every path a user might take.
This is why iteration is part of the design. You describe a change in plain language, the build re-verifies, and you look again. Verification removes the most common and most frustrating class of failure — the app that doesn't start — so your review time goes to the questions only you can answer.
What happens after a build is verified?
A verified build is publishable immediately. One click puts it on a <slug>.zugo.run URL; free publishes carry a "Made with Zugo" badge, and paid plans support custom domains.
It's also portable. Zugo exports to GitHub as a real repository — src/, package.json, vite.config — not a proprietary bundle. The details are in exporting your AI app to GitHub.
For apps that need real infrastructure, connectors cover Supabase (database and auth), Stripe (payments), Google Analytics, Resend (email), and Vercel (deploy to your own account). Zugo Cloud provides a built-in database for generated apps that don't need external services.
Pricing is straightforward: free starter credits with no card required, Pro at $25/month (200 credits — roughly 16 platforms or 33 quick builds — plus custom domains), and Business at $99/month. There are 25 templates across 5 categories if you'd rather start from a base than a blank prompt, and the interface works in English and Russian.
The fastest way to calibrate what "verified" produces in practice is to look at real output: the showcase is all builds that passed the same sandbox check described here.