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 -- a React 19 and TypeScript app with hand-written CSS, published as its own Cloudflare Worker and backed by a Durable Object that stores the app's data in its built-in SQLite database -- and you can take all of it. Every app built today starts from the same scaffold: src/index.ts for the server, src/client.tsx for the React client, and public/ for the page and its stylesheet. User accounts and login are written into the app when it needs them, and for payments the AI can write Stripe code against your own keys. No separate database, key-value namespace or storage bucket is provisioned on your behalf; the data lives in the app's Durable Object. Apps built on our earlier engine used a different template set -- Vite, Tailwind CSS, and a Hono backend with a D1 database through Drizzle ORM -- and their exports keep that shape. 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 Max)" in worker/api/controllers/githubExporter/controller.ts, and GitHub sync returns "GitHub sync is available on paid plans (Pro or Max)" in worker/api/controllers/githubSync/controller.ts. One limit to state plainly: apps built on the current generation engine push to GitHub but cannot yet pull changes back, so for them it is an export, not a two-way sync. Apps built on the original engine keep the pull direction. 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 preview, but you cannot put an app online or take the code with you. getAccountPublishedProjectLimit in worker/config/billing.ts gives a free account no published projects, and evaluatePublishGate in worker/agents/services/implementations/publishGate.ts enforces it at deploy time. Free gets a monthly credit allowance, plus a daily ceiling and a per-generation cap; Pro and Max raise the allowance. The current prices, allowances and caps are on the pricing page -- they are tuned periodically, so this article does not restate them. Annual billing exists on Pro and Max. Unused paid plan credits carry over for one month. There is no free trial and there is no Team or Enterprise tier.

The second honest limitation is the runtime. Generated apps target Cloudflare. Once you add the Worker entry, Durable Object binding and client bundling that Fabricate otherwise supplies at publish time, 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 built around a Cloudflare Durable Object 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 delete your app, but it does take it offline. Keeping an app online is a paid feature, so we email you, and at least 14 days later the live link shows an offline page instead of the app until you choose a paid plan again; the app, its data and its address stay where they were. Private apps stay private. If you are running something that has to stay online, that is the behaviour 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 the app's own source with a small Cloudflare config. package.json lists the runtime dependencies -- React 19 and whatever the app added -- and wrangler.json names src/index.ts as the server entry, src/client.tsx as the client entry and public/ as the static assets. There are no build scripts, because the platform bundles the client and wires the Durable Object when it publishes. Apps built on our earlier engine export as an ordinary Vite project instead, with the scripts dev, build, typecheck, lint, preview, deploy and cf-typegen and worker/index.ts as the Worker entry.

One detail worth stating: the Fabricate 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.

Today's exports have no resource IDs to fill in: wrangler.json is the same small file for every app, because the data lives in the Durable Object rather than in a provisioned database. The earlier engine needed a pre-deploy check for this. It ran 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, failed the build if wrangler.jsonc still contained 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 meant the config that shipped in those exports was 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 and a Durable Object's built-in SQLite assumes a specific request model, a specific storage API 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 export, git clone and ZIP export, and an app that is not deleted if you stop paying, though its live link goes offline after notice. All three export paths are paid-plan features enforced server-side, so is publishing, 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 or publishing 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.