Can I Collaborate With Someone on an AI-Built Project?
Yes, but not by sharing a cursor. Collaboration in Zugo runs through the things a build produces: a published URL anyone can open, a GitHub repository you can add people to, and your own Supabase, Stripe and Vercel accounts. One person drives the prompt, everyone else reviews and hands back edits in writing.
That is a real workflow, and for two or three people it is often faster than a shared canvas. It is also not what most people picture when they ask the question, so the rest of this post is about which parts work well, which parts you have to organise yourself, and where the approach genuinely runs out.
What does "collaborating" actually mean here?
Three different things hide behind that one word, and they have three different answers. Editing the same project at the same moment, in the same window, is the version people imagine. Reviewing someone else's build and asking for changes is the version teams actually do all day. Taking a project over completely is the third.
Zugo answers those in reverse order of how they get asked. Handover is the strongest: the project belongs to you, the code exports to GitHub, and every connector runs on your own account. Review is easy, because each project publishes to an address like your-project.zugo.run and anyone with the link can open it on any device.
Simultaneous editing is the one it does not do, and being blunt about that saves a week of confusion. There is no shared cursor, no presence indicator, no comment pins on the preview. If your mental model is a design tool where two people drag things around at once, adjust it now. The unit of collaboration here is a build and a link, not a live session.
How do two people actually work on one Zugo project?
By splitting roles rather than splitting the screen. One person holds the account and runs the prompts. Everyone else works from the published address and sends back changes as text, which the driver pastes in as edits.
That sounds primitive until you notice that the instruction format and the review format are the same thing. "Make the pricing table three columns and move the FAQ above the footer" is both a comment and a prompt. There is no translation step between what a reviewer says and what the builder does.
| Way of working together | How it works | What to watch for |
|---|---|---|
| Driver and reviewers | One account runs builds, others open the published URL and reply with edits | Batch the notes: one edit with six changes beats six edits |
| Shared connector accounts | Supabase, Stripe and Vercel are your own accounts, so teammates you add there see the data and the deploys | Builder access and connector access are separate, and the second one is not managed by Zugo |
| Repository handover | Export to GitHub, then use branches, pull requests and reviews as normal | Once the code moves forward in the repo, the builder copy stops being the source of truth |
| Separate projects, one owner | Each person builds their own variant, the best one wins | Nothing merges automatically, so keep the variants small |
The first row covers most small teams. The third is the one that scales, because at that point you are using GitHub's collaboration model rather than asking a builder to invent one.
Who should hold the account?
Whoever will still be there in six months. Plans are priced per account: Free comes with 5 credits, Pro is $25 per month with 200 credits, and Business is $99 per month. The practical consequence is that credits are a shared pool, and the person holding the login is the person who can spend it.
For a founding team, put the account on the entity rather than on an individual, using an address that survives someone leaving. For an agency building on behalf of a client, decide early whether the client gets the account at the end or only the exported repository, because those are very different handovers.
Connectors change the calculation in a good way. Supabase holds the database and the sign-in, Stripe holds the money, Vercel can hold the hosting, and all three are accounts you already control. Even if a Zugo login changed hands tomorrow, the data, the payouts and the deployment targets would not move with it. Setting that up is covered in connecting Supabase to an AI-built app.
How do you hand the project to a developer?
Export it. GitHub export produces a standard project under your own account, and from that point a developer works with ordinary tools: clone, branch, review, deploy. No part of that requires the developer to have a Zugo login or to learn how the builder works.
This is the cleanest collaboration Zugo supports, because it stops being collaboration inside a builder and becomes collaboration inside a codebase, where the tooling has had twenty years to mature. Pull requests, blame, CI and rollbacks all exist there and none of them exist in a prompt window.
The thing to decide is whether work continues in both places. It usually should not. Once a developer starts committing, treat the repository as the only source of truth, because changes made in the builder afterwards live in a different copy and nothing reconciles them for you. The full sequence is in can a developer take over an AI-built project later.
What does a shared workflow cost in credits?
Less than people expect, because reviewing is free and only acting costs anything. Opening the published URL, reading it, arguing about it and writing notes consume nothing. Credits are spent when a build or an edit runs.
A fresh single-page build costs 6 credits. A multi-page platform costs 12 credits for the first three pages and 3 for each page after that. An edit costs 3 credits, and Hi-Fi mode doubles both figures, so a Hi-Fi edit is 6 and a Hi-Fi build is 12.
That pricing shape rewards batching, which happens to be the right review discipline anyway. Three reviewers sending three separate notes cost three edits. The same three notes collected into one instruction cost one. Pro's 200 credits work out to 66 edits if that is all you spend them on, which is a lot of review rounds for a small project. The wider breakdown lives in what an AI app builder costs.
Where does this way of collaborating break down?
At four fairly predictable points, and none of them are secret.
- Real-time co-editing. It does not exist. If your team's entire process depends on two people working in one document simultaneously, this will feel wrong from day one.
- Merging two people's work. There is no merge inside the builder. Two variants of a project stay two variants until somebody rebuilds by hand or the work moves into a repository.
- Role-based permissions inside a build. Access to the connectors is managed in Supabase, Stripe, GitHub and Vercel, each with its own rules. Nothing hands you one combined permission model.
- A complex product with several developers. Zugo does not replace a development team. Past a certain size the correct answer is that the builder produced the first version quickly and the team owns it from there.
None of that is a reason to avoid building this way. It is a reason to be deliberate about the moment when a project graduates from a prompt window to a repository, which is a decision people usually make too late rather than too early.
What is the practical setup for a small team?
Four steps, in this order. Put the account on an address the team controls. Connect Supabase, Stripe and any other service under accounts the business owns, not personal ones. Publish early, because a link that reviewers can open is what makes remote feedback specific. Export to GitHub as soon as anyone writes code by hand.
Every build is booted in a sandbox before it reaches you, and one that fails to load is reported as a failure instead of being handed over. That lowers the odds of sending your team a blank page to review, though it does not remove them, and it says nothing about whether the layout is what you meant.
So the review loop still matters, and it is the cheap part. Open the published address, collect the notes, send them in one edit, look again. If you want to try that loop with someone before committing to a plan, start at zugo.dev, build one page, and send the link to the person whose opinion you actually need.