Do you own the code an AI app builder writes for you?

Short answer: in the United States you own the parts of the output that reflect your own creative contribution, the vendor almost certainly disclaims ownership of the output in its terms and assigns whatever rights exist to you, and neither of those facts tells you whether you can actually get the code out of the tool.

The first question is legal. Who holds copyright in code a model wrote? The real answer is more restrictive than most vendor marketing implies.

The second question is operational. Can you download the source, push it to a git remote you control, run it on infrastructure the vendor does not own, and keep your deployed app alive if you stop paying? This is what determines your position in eighteen months when pricing changes, the roadmap moves, or the company gets acquired.

These two questions have almost nothing to do with each other. A platform can grant you every right it holds in the output and still leave you with no mechanism to obtain a copy of it. Bubble is the cleanest illustration in the market: its own documentation says you own your app design and your user data, and in the same breath says Bubble apps can only be run on the Bubble platform and there is no way of exporting your application as code. Both statements are true simultaneously. Ownership without portability is a receipt for something you cannot pick up.

In the United States, purely AI-generated material is not copyrightable, and prompting alone -- however long, structured or iterative the prompt -- does not make you the author of the output.

That is the position the US Copyright Office set out in Part 2 of its Report on Copyright and Artificial Intelligence, released on 29 January 2025. The Office concluded that with current technology, prompts do not give a human sufficient control over how an idea is expressed for the resulting output to count as that human's work of authorship. Writing a longer or cleverer prompt does not change the analysis, because the mechanism of control is the problem, not the effort.

What is protectable is narrower and more specific. Human-authored material that is perceptible in the output remains yours. So does your creative selection, coordination and arrangement of AI-generated material, and your creative modification of what the model produced. If you took generated components, restructured the data model, wrote the business rules yourself and arranged the whole application, there is human authorship in there -- it just does not extend to every line the model emitted. The Office also expects applicants to disclose AI-generated content when registering a work and to describe the human contribution.

The courts have not disturbed this. On 2 March 2026 the Supreme Court denied certiorari in Thaler v. Perlmutter (No. 25-449), leaving in place the DC Circuit's holding that the Copyright Act requires every eligible work to be authored in the first instance by a human being. A denial of certiorari is not an endorsement and the doctrine may be revisited, but as of today the human-authorship requirement stands.

This is jurisdiction-specific. The United Kingdom still has section 9(3) of the Copyright, Designs and Patents Act 1988, which grants copyright in computer-generated works that have no human author and treats the person who made the arrangements for their creation as the author. In its Report on Copyright and Artificial Intelligence, published 18 March 2026, the government said its preferred option is to repeal that provision, noting that most consultation respondents took the view that works created solely by AI should not attract copyright, while protection would remain for AI-assisted works reflecting human creative choices. That report is not binding and no legislation had been introduced as of July 2026. Same output, different answer depending on where you ask.

For most people shipping a small product this is less alarming than it sounds; you are rarely going to litigate copyright in a CRUD app. Where it does bite is narrower and predictable: assignment warranties in client contracts, IP representations in an acquisition, and any situation where you must state on paper that you are the sole author of everything you are transferring. If you sign that language about a codebase a model wrote, read it again first.

Almost every AI app builder disclaims ownership of the generated output and assigns whatever rights exist to the customer. That clause is close to universal across the category, and on its own it means very little.

Vercel states it plainly in the v0 FAQs: "Vercel doesn't own the code generated based on your queries and prompts." The same FAQ then notes that output "may be the same or similar to other users' output or third party's IP, be incomplete or contain bugs," and puts the burden of evaluating it on you.

Read that second half carefully, because it is the half that does work. The standard shape of these terms is: we do not claim ownership, and we do not warrant that the output is original, non-infringing or correct. You receive whatever rights exist, and you also receive the risk.

Bubble draws the other line in the same category more explicitly than anyone. Its manual says you own your app's design and user data, while "Bubble retains ownership of the underlying code that powers your app," and compares this to Microsoft owning Word while you own your documents. It also commits that in the unlikely event of discontinuation, Bubble's source code will be made available under an open-source license so an app can be maintained on a self-hosted Bubble server.

Most platforms leave the same distinction implicit, so Bubble deserves credit for stating it. The pattern to look for is the split between the output and the machine: the vendor gives you the output and keeps the machine. That is entirely reasonable as a business model. It only becomes your problem when the output is inert without the machine.

Legal ownership is a question you answer once. Portability is a question you answer every month you keep paying, and there are exactly five things worth checking.

1. Can you download the source? Not a preview, not a public share link, not a screenshot of the file tree -- a complete archive of the files on disk. Check whether this is gated behind a plan, because on several platforms it is.

2. Is there a git remote or a GitHub sync? A ZIP is a snapshot; a git remote is continuity. Two-way sync is meaningfully better than one-way push, because it means you can edit locally and the platform will accept your changes back rather than silently overwriting them.

3. Can you run it without the vendor's runtime? Some generated apps are ordinary Node or Vite projects that boot anywhere. Some are ordinary projects that happen to target one specific cloud. Some are not projects at all, just configuration inside a proprietary engine. These are three very different outcomes and the marketing word for all three is "export".

4. Are there proprietary runtime dependencies you cannot replicate? A hosted database with no export path, a bespoke auth service, a managed function runtime with no local equivalent. If the code compiles but cannot serve a request without the vendor's infrastructure, the export is a reference implementation, not an escape hatch.

5. What happens to your deployed app when you stop paying? This is the cell nobody puts on a pricing page and the one that decides whether leaving is a migration or an outage. In our research for the matrix below, it was also by far the hardest thing to verify from any vendor's own documentation, including our own.

Every cell below was checked against the vendor's own current documentation on 26 July 2026, or, for Fabricate, against the code in the repository that runs the product. Where a vendor's public documentation does not answer the question, the cell says "Not verified". That is not a negative finding about the vendor -- it means the answer is not published where a customer can read it before buying.

We would rather ship a table with gaps in it than a table where every cell is filled and some of them are invented. If you need certainty on a "Not verified" cell, ask that vendor's support directly and get the answer in writing before you commit.

Fabricate generates a real repository -- React and TypeScript on Vite, Tailwind CSS, and a Hono backend running on Cloudflare Workers with a D1 database accessed through Drizzle ORM -- and you can take all of it. The exact shape depends on which template the build starts from: the full-stack template ships D1 and its own JWT session auth written into the worker, another adds a KV namespace and Durable Objects, and another wires Stripe. D1 and KV are the two resource types the platform provisions on your behalf. Three separate paths out exist, and all three are gated to paid plans, enforced server-side rather than hidden in the UI.

The ZIP export is GET /api/apps/:id/source/archive, registered owner-only in worker/api/routes/appRoutes.ts and re-checked with requirePaidTier inside the controller. GitHub export returns a 403 to free accounts with the message "GitHub export is available on paid plans (Pro or Scale)" in worker/api/controllers/githubExporter/controller.ts, and two-way sync returns "GitHub sync is available on paid plans (Pro or Scale)" in worker/api/controllers/githubSync/controller.ts. Cloning over HTTPS needs a short-lived token from POST /api/apps/:id/git/token, which is also paid-tier gated.

So the honest summary of the free tier: you can build and you can publish one project, but you cannot take the code with you. PUBLISHED_PROJECT_LIMITS in worker/config/billing.ts sets the free cap at one published project, and evaluatePublishGate in worker/agents/services/implementations/publishGate.ts enforces it at deploy time. The same gate carries a second limit worth knowing before you depend on it: on free, the first publish of an app goes through, but pushing an update to an app that is already live is rejected as a Pro feature. Free gets 60 credits a month, plus a daily ceiling and a per-generation cap; Pro is $25/month for 350 credits and Scale is $50/month for 700. The current cap figures are on the pricing page -- they are tuned periodically, so this article does not restate them. Annual billing exists on Pro and Scale. Credits do not roll over. There is no free trial and there is no Team or Enterprise tier.

The second honest limitation is the runtime. Generated apps target Cloudflare. You can deploy the exported project to your own Cloudflare account with your own wrangler credentials, and nothing in the code phones home -- but "portable" here means portable to Cloudflare, not portable to any host. If you export an app that uses D1 and KV and try to run it on a generic Node box, you have a port to do. That is a real constraint, and it is the price of the integration.

The third thing worth knowing before you need it: if a paid subscription lapses and the account drops to free, Fabricate does not tear down your deployed app. Nothing in the codebase deletes a live deployment on downgrade. What it does do is flip every private app to public -- enforceFreeTierProjectRestrictions in worker/database/services/BillingService.ts runs a single UPDATE setting visibility to public for that user. You also fall back under the free publish gate, so the live app keeps serving but pushing changes to it stops working. If you are running something you need to stay private, or something you still need to update, those are the two behaviours to plan around.

The archive is the generated file set, unmodified. The export handler reads the project files straight from the agent, filters anything that fails a path-safety check, and zips them. It does not inject a licence header, a phone-home script, or a Fabricate dependency -- there is no fabricate package in the generated package.json.

What you get is an ordinary Vite project with an ordinary Cloudflare wrangler config. The scripts are dev, build, typecheck, lint, preview, deploy and cf-typegen. The deploy script is a build followed by wrangler deploy, pointed at whatever account your own wrangler credentials resolve to. The dev dependencies are the ones you would expect for this stack -- @cloudflare/vite-plugin, @cloudflare/workers-types, @vitejs/plugin-react -- and the wrangler config names worker/index.ts as the entry point with single-page-application fallback for assets.

One detail worth stating: the free-tier badge is applied to the served HTTP response by worker/utils/watermark-injector.ts, not written into your source files. Your exported HTML is not carrying a hidden script you have to hunt for.

The reason the wrangler config in the export is usable rather than a template full of holes is a pre-deploy check. Fabricate runs an AST-based safety gate before every deploy -- worker/agents/validators/preDeploySafetyGate.ts, which enforces 28 named rules -- and one of those rules, unresolved_resource_placeholder, fails the build if wrangler.jsonc still contains raw {{KV_*_ID}} or {{D1_*_ID}} placeholders. Production rejects those outright; a sandbox will happily run with a binding that never resolves, which is the worse failure. Gating on it means the config that ships in your export is a real one.

Getting the source out solves one of the five lock-in questions. The other four are about everything the code depends on, and they do not fit in a ZIP.

Runtime coupling is the big one, and it applies to every platform in this category, not just ours. An app written against Cloudflare Workers, D1 and KV assumes a specific request model, a specific SQL dialect and specific binding semantics. An app written against a vendor's managed Postgres and edge functions assumes a different set. Moving between them is a port with a real cost, and the cost is proportional to how much of the app touches the platform rather than how many files there are.

Data is the second. Your source code is a few megabytes. Your production database is the thing your users care about. Before you believe you can leave, confirm you can get a full dump of the data, not a CSV of one table through an admin UI, and confirm you can restore it somewhere else.

Third-party accounts are the third, and they are the one piece of good news. If your app takes payments through Stripe or calls any other external API, those are your accounts, with your keys, held in your own environment variables. They move because they were never the platform's to hold. That is a genuine argument for builders that wire up real third-party services instead of proprietary in-house equivalents: a Stripe account is portable by construction.

Then there is the part nobody lists: the agent. Whatever tool built the app also knows how to change it. Fabricate's phasic pipeline -- worker/agents/execution/phasicStateMachine.ts -- plans a milestone, implements it, deploys, validates and repeats, and the models behind it are routed per step from AUTO_PRESET_MODELS_BY_ACTION in worker/agents/inferutils/config.ts. Take the export and you keep the code and lose that loop. That is a fair trade and it is not really lock-in, but it is the thing people are surprised by when they leave: the app still works, and changing it is suddenly a different job.

Do this in the first week, while the app is worth nothing and you have no users to disappoint. Portability is trivially testable, and almost nobody tests it until the day they need it.

Build something small and real -- a login, one database table, one write path. Not a static landing page, because a static page will export cleanly from anything and prove nothing about the parts that bind you.

Export the source. Note whether you had to pay to do it and how long it took. Unzip it and read the dependency list for anything with the vendor's name on it.

Install and boot it locally. This is the step that separates real exports from decorative ones. If npm install and a dev command do not get you a running app, you have learned something important for the price of an afternoon.

Deploy it somewhere that is not the vendor. Your own cloud account, your own credentials. You will hit the resource-provisioning wall here: databases and storage that exist under the vendor's account need recreating under yours. Finding out how tall that wall is now is much cheaper than finding out later.

Finally, export the data and restore it into a fresh database. If every one of those five steps works, you have a genuine exit. If step three or five fails, you do not have portability, whatever the marketing page says.

You own what you contributed and the vendor almost certainly is not claiming the rest. In US law, purely AI-generated material is not copyrightable and prompting alone does not confer authorship, but your selection, arrangement and modification of the output can be. That answer is stable enough to plan around and narrow enough that you should not sign a sole-authorship warranty without thinking.

The question that will actually affect you is the other one. Can you leave? Judge that on five things -- source download, git remote, off-platform runtime, proprietary dependencies, and what happens to a live app when the payments stop -- and get the answers before you build, in writing, from the vendor.

Fabricate's position, stated plainly: you get a complete standard repository with no proprietary dependency, GitHub sync, git clone and ZIP export, and a deployed app that does not get torn down if you stop paying. All three export paths are paid-plan features enforced server-side, the free tier publishes one project and cannot push updates to an app that is already live, private apps go public on downgrade, and the generated apps target Cloudflare rather than any host. Three of the competitors in the matrix above state no plan gate on source download in their docs. If code export on a free plan is your requirement, we are not currently the right answer, and we would rather you find that out here than after you have built something.