Can I Sell What I Build With AI? Ownership and Limits

Yes. The project belongs to you, the source exports to your own GitHub account, Stripe handles the money into your own account, and a custom domain puts it on your own address. What selling still requires is everything that was never code: business approval from your payment processor, tax registration, refund terms, and support.

Those two halves get confused constantly. The software question has a short answer and the business question has a long one, so this post separates them and is specific about which obligations move to you the moment somebody pays.

What does "you own it" actually cover?

Three concrete things rather than a slogan. The generated source is yours and exports to a repository under your GitHub account. The data lives in your Supabase project. The revenue arrives in your Stripe account, without passing through anyone else.

That combination is what makes selling viable at all. A product whose code, customers and payouts sit inside somebody else's tool is not really a business you own; it is a tenancy. Owning all three means the worst case is an inconvenient migration, not the end of the thing.

The published address is the one piece that starts on shared infrastructure. Every project goes live at your-project.zugo.run, and connecting your own domain is what turns a demo link into a product address. For anything you charge for, do that early: a commercial page on a subdomain of a builder reads as unfinished, fairly or not.

Which parts of selling does the builder actually handle?

The build and the checkout. Not the business. Here is the split, stated without softening.

The pattern is consistent: what is code gets generated, and what is a decision or an obligation stays with the person taking the money. An AI builder compresses the build. It does not compress the responsibilities that come with a customer.

How fast can you get from idea to something sellable?

The build itself is quick. A simple single-page site arrives in about a minute; a multi-page platform with a database, sign-in and payments takes a few minutes, because those pieces genuinely need the time. Every build is booted in a sandbox first, and one that fails to load is reported as a failure rather than handed to you.

The realistic gate is not the build, it is the payment processor. Stripe verifies businesses on its own schedule, and no builder speeds that up or routes around it. The sane sequence is to build and test the entire purchase flow with test keys while verification runs, then swap in live keys afterwards, since nothing in the generated code changes between the two.

In credits, getting to a sellable version is modest. A single-page build costs 6 credits, a multi-page platform costs 12 for the first three pages and 3 for each page beyond, and every edit costs 3. Hi-Fi mode doubles the build and the edit. Free comes with 5 credits, Pro is $25 per month with 200 credits, and Business is $99 per month. The mechanics of wiring the checkout are in can AI build a site that takes payments.

What can you sell: the product, or the code itself?

Both, and they are different businesses with different risks.

Selling access to something you run is the common case. You host it, customers pay a subscription or a one-off fee, and you keep the accounts, the data and the support load. This is what the Stripe and Supabase connectors are shaped for.

Selling the code as an asset is the other case: a template, a starter kit, a finished site delivered to a client. Export to GitHub, transfer the repository, and the client owns what you built. Agencies do exactly this, and the export is what makes the deliverable credible, because "here is the repository" is a stronger handover than "here is a login to my builder account". The mechanics are in can I export the code from an AI builder.

The risk profile differs. Running a product means ongoing obligations and recurring revenue. Selling code means a clean exit and a client who may well ask you to maintain it anyway, which is a conversation to have before the invoice rather than after.

What should you check before you charge anyone?

Five things, and they take an afternoon rather than a week.

• Run your own purchase. Buy your product in Stripe test mode, with a test card, all the way to the success page and the record in Stripe. This catches more than any automated check, because a checkout that charges the wrong amount loads perfectly.
• Replace the imagery. Builds arrive with stock photography so the layout can be judged, and anything commercial deserves your own photos. It is also the cheapest way to stop a page looking generic, as covered in can I use my own images.
• Write the terms and the refund policy yourself. These are promises with legal weight, not filler text, and generated placeholders are not a substitute for deciding what you actually offer.
• Check who can read what. If customer data is stored, access rules in the database are the thing to have reviewed. This is the class of mistake that looks completely fine in a browser.
• Point a real domain at it. Trust and a builder subdomain do not sit well together on a paid product. The steps are in can I use my own domain.

Where does this approach genuinely fall short?

At the point where the product stops being pages and starts being rules. A shop with a catalogue, a checkout and an account area is well inside what a builder does. A marketplace with split payouts, usage-based metering, complex proration or a compliance regime is not something one prompt produces, and pretending otherwise wastes your money rather than ours.

Those things are not impossible, they are just built the ordinary way: through a series of edits that narrow the behaviour, and past a certain point by a developer working in the exported repository. Zugo does not replace a development team on a complex product, and a business with real revenue eventually deserves one.

The sandbox check has limits worth restating too. It confirms the build loaded and rendered. It lowers the risk of publishing a blank page and does not remove it, and it says nothing about whether your pricing logic is correct or your data is protected. For money flows, your own end-to-end test is the check that matters.

What is the honest summary?

You can sell what you build, and the ownership behind that claim is real: your code, your repository, your database, your Stripe account, your domain. That is a genuinely different position from renting a page on a platform, and it is the part worth caring about when choosing a tool.

What does not change is that selling is a set of obligations, most of which have nothing to do with software. The builder removes the weeks of construction, which leaves the checklist above as the actual project, and that is a much better problem to have.

The concrete first step is small: describe one offer at one price at zugo.dev, connect Stripe in test mode, and buy your own product with a test card. If that loop works end to end, everything after it is paperwork and pricing rather than engineering.