AI Can Generate a Website. But Who Owns the Code?

A founder showed me a site last month. An AI tool built it in an afternoon, and it looked good. She wanted a small change to the booking flow before launch.

We asked for the code. She didn’t have any, and her plan didn’t include an export option.

That moment arrives often now. AI has made building a website fast and cheap. Owning the result, changing it later, and keeping it alive are separate questions, and almost nobody asks them until something breaks.

Quick takeaways:

• Generating code and owning code are not the same thing.
• Purely AI-generated material sits in a grey area under US copyright law.
• Some AI builders never hand you exportable code at all.
• Unreviewed dependencies become tomorrow’s security problem.
• Weak architecture costs more to fix than the site cost to build.
• Ownership hides three different questions

People say “who owns the code” and mean one of three things. Separating them makes the answer much clearer.

Legal ownership asks whether you hold rights to the code at all. Practical possession asks whether you can download it and move it elsewhere. Working control asks whether anyone can actually change it once it exists.

You can lose on all three at once. A tool generates your site, keeps the code on its servers, and produces something no developer wants to touch. Nothing was stolen from you, yet you own very little that’s useful.

Work through each question before you commit to a platform.

What copyright actually says

Start with the legal layer, because it surprises people.

The US Copyright Office released Part 2 of its report on copyright and AI in January 2025, concluding that generative AI outputs can be protected by copyright only where a human author determined sufficient expressive elements. The Office also concluded that even a detailed or complex prompt does not confer copyright ownership over the output, since prompts work as instructions rather than expressions of creativity.

US copyright office, Manatt, Phelps & Phillips, LLP

Read that carefully. Typing “build me a landing page for a dental clinic” does not make you the author of what comes back.

Most AI vendors do assign you whatever rights they have in the output through their terms of service. That’s a contract between you and the vendor, and it settles very little about whether anyone else could copy your code freely.

Rules also differ by country, and the UK, EU and Australia each treat this differently. Talk to a lawyer if your site contains something genuinely proprietary.

Can you actually take the code with you?

Legal questions matter less than this practical one for most businesses.

Some AI tools generate real, exportable files. Others generate a site that lives inside their platform and runs on their proprietary runtime. The second kind gives you a website, not a codebase.

Ask three questions before you build anything serious:

• Can I export the full source, including the back end and the database?
• Will it run on my own hosting without the vendor’s platform?
• What happens to my site if this company shuts down or triples its price?

Vendors rarely advertise the answers, so test the export yourself during a trial. Download the files, then hand them to a developer and ask whether the site runs.

Lock-in isn’t automatically wrong. Shopify locks you in too, and thousands of businesses happily accept that trade. Choose it deliberately rather than discovering it the week before launch.

WordPress, Webflow, Shopify or Custom Code — Which One Actually Fits Your Business?

The licence problem inside the output

AI models learned to write code by reading code, much of it open source and licensed under terms that require attribution or force derivative works to stay open.

Occasionally a model reproduces recognisable chunks of what it learned. The risk is small for ordinary layout code, and it grows with unusual algorithms or distinctive implementations.

Larger vendors now offer indemnity on copyright claims for paying customers. Free tiers and smaller tools usually offer nothing. Check what your tool promises before you ship commercial work.

Run generated dependencies through a licence scanner too. An AGPL package inside a commercial product creates real obligations, and nobody notices until an acquirer’s due diligence team does.

Owning code nobody can maintain

Say you clear every ownership question. You hold the rights, you have the files, and the site works today.

Then you need a change. This is where AI-built projects usually fail, and it has nothing to do with law.

AI writes code that satisfies the prompt in front of it. Ask for a contact form, get a contact form. Ask for a booking system next, and the tool often builds a second, unrelated system beside the first.

Repeat that fifteen times. You end up with duplicated logic, three different ways of handling dates, and styling scattered across files that nobody organised.

Developers then quote you more for a small change than the whole site cost, because they must understand the mess before touching it. Clients hear that quote as greed. It’s usually just the true price of unowned complexity.

A Website Is Never Really Finished. And That’s the Point.

Dependencies you never chose

AI tools reach for packages constantly. Each one solves an immediate problem and adds a permanent liability.

Generated projects routinely pull in dozens of libraries. Some are abandoned. Some duplicate what another package already does. A few don’t exist at all, because models occasionally invent plausible package names, and attackers now register those names deliberately.

The WordPress version looks familiar. An AI-assisted build installs a plugin for every feature request, and you reach twenty-five plugins without a single deliberate decision.

Audit what came with your site:

• List every package or plugin, and delete anything unused.
• Check when each one was last updated.
• Confirm that a maintained alternative doesn’t cover three of them at once.
• Set up automated security alerts for the rest.

Architecture is the expensive part

Features are cheap now, and structure still isn’t.

Architecture decides how your data is organised, how pages get built, where business logic lives, and how the site handles ten thousand visitors instead of ten. AI handles these well when you specify them, and badly when you don’t.

Common results we see in generated builds: database tables with no relationships, business rules copied into six templates, authentication assembled from tutorial fragments, and no caching strategy anywhere.

None of that shows up in a demo. All of it surfaces at scale, or during a security review, or when you try to add a second language.

Fixing architecture after launch means rebuilding while the site stays live. That costs far more than getting it right at the start, so treat the structural decisions as the part worth a human’s attention.

Using AI without losing the asset

We use AI daily at Infyras, and it makes good developers considerably faster. The difference lies in what stays under human control.

Decide the architecture yourself. Choose the stack, the data model and the folder structure before generating anything. AI then fills in components inside a structure someone designed on purpose.

Review every line that ships. Generated code goes through the same review as hand-written code, and unreviewed output never reaches production.

Keep the project in Git from day one. Version control turns the code into an asset you hold, independent of any tool that helped produce it.

Document the decisions. A short README explaining why the project is shaped this way saves the next developer days of archaeology.

Check this before you accept an AI-built site

Run through this list with whoever built your site, or with the platform you’re evaluating:

• Export the complete source code and confirm it runs elsewhere.
• Get the repository, not a zip file emailed to you.
• Read the vendor’s terms on output ownership and indemnity.
• Scan dependencies for licences and known vulnerabilities.
• Ask a developer to price one small change, as a maintainability test.
• Confirm who holds the hosting, domain and database credentials.
• Check that database backups exist and restore properly.

Item five tells you more than the rest combined. A healthy codebase makes small changes cheap, and that stays true whether a human or a model wrote it.

Speed is worth having, once the asset is real

AI has genuinely changed how quickly a website can exist, and that’s good news for anyone launching something.

The old risk was cost. The new risk is ending up with a site you can’t move, can’t change, and don’t quite own. Those problems stay invisible for months, then arrive together at the worst possible moment.

So ask the ownership questions early, while switching still costs you nothing.

At Infyras we build sites clients fully own, and we take over AI-generated projects that have stalled. If you’re unsure what you actually hold, we’ll review the code, the dependencies and the structure, then tell you plainly what it would take to make it maintainable.

Send us your repository or platform link. You’ll get an honest assessment of whether it’s worth keeping or worth rebuilding.