The sessions / Quality & Ownership

Ownership is not one switch. Your words, code, images, domain, accounts, third-party packages and AI output can each have different terms. Portability is simpler to test: keep the source in an account you control, download a complete copy, know which services it depends on, and prove that someone else could rebuild it.

5 min read

Read as: HTML / Markdown

Is the website really mine?

The honest answer begins with another question: which part?

A website is a bundle of things that happen to appear as one page:

• The words, photographs and designs you supplied
• The code written for the project
• Open-source packages the project uses under their own licences
• Fonts, icons, photographs or other material made by somebody else
• The domain name
• The repository and its version history
• The hosting, analytics, forms and other connected services
• Any data the site collects
• The AI tool and the terms under which it generated the output

Those parts do not all have the same owner, and they do not all move in the same way.

So I would not teach you the easy sentence, “The AI made it for you, therefore it is yours.” The safer sentence is this:

Put the project’s accounts and source under your control, keep a record of where every important part came from, and check the terms and licences that give you the right to use it.

That is not legal advice. If the project is commercially valuable, built for an employer or client, or depends heavily on generated material, get advice for that situation rather than relying on a general lesson.

What should definitely be under my control?

The practical foundations should be in accounts you can access without the person or agency that helped you build:

• The domain registrar
• The source-code repository
• The hosting account
• The AI-building account, while you still need it
• Analytics and form services
• Billing details and recovery email addresses

Turn on two-factor authentication, keep recovery methods current, and do not let somebody else’s personal account become the only doorway to your project.

This is practical control, not a complete legal opinion. It matters because a right you cannot exercise without someone else’s password is not much use on an ordinary Tuesday morning.

Can I take the code away?

Do not answer this from a platform’s marketing page. Test it.

For a code-based project, you should be able to put the source in a repository you control and make a complete copy on your own computer. A proper clone of a repository includes the files and their version history. A downloaded zip is still useful, but it is only a snapshot.

The more important test is whether the copy can stand up elsewhere. Ask the model to produce a short handover containing:

1. What the project needs in order to run
2. The command that installs it
3. The command that builds it
4. The services it connects to
5. The settings and secrets that are required, named but not exposed
6. The current hosting arrangement
7. Any platform-specific features that would need replacing
8. The licences for important dependencies and assets

Then ask a fresh session, or a different person, to rebuild the project from that handover and the repository alone. If they cannot, you have found a dependency that was living in the original conversation or platform rather than in the project.

What might not come with me?

Source code is only one layer. Moving it may not automatically move:

• The visual editor or chat history from the tool where it was made
• Hosted databases and their data
• User accounts and login sessions
• Form submissions
• Analytics history
• Environment variables and secret keys
• Deployment settings
• Scheduled jobs
• A domain name registered in somebody else’s account

That does not mean the site is trapped. It means portability has to include a map of its dependencies, not only a folder of code.

For a first one-page site, that map may be wonderfully short. That is another reason to begin without accounts, payments, databases or private data.

What is a good portability drill?

Once the site works, run a fire drill:

• Confirm that the repository is in your account.
• Make a fresh copy in a new folder.
• Follow the written setup instructions exactly.
• Build it without relying on the original chat.
• List every outside service it needs.
• Confirm that the domain and hosting accounts are yours.
• Record how to export any content or data held elsewhere.

You do not need to migrate the live site. The exercise proves that leaving is possible and reveals what would have to travel with you.

Portability is not a promise made by a platform. It is a journey you have rehearsed.

Where can I see this on the site?

The lesson on getting a site online explains the repository as the project’s home in the cloud and the difference between committing and pushing. The colophon names the services behind this site rather than hiding them behind a claim that it simply lives “in the cloud”. Those records make the project legible to the next person, including a future version of you.

So, is it really mine, and can I take it away?

Treat those as two questions.

Whether you own every right depends on what went into the project, the terms you agreed to and the law that applies. Do not let a model give you a one-sentence legal conclusion.

Whether you can take the project away is something you can prove: keep the source and core accounts under your control, record every outside dependency, make a complete copy, and rebuild it without the original platform or conversation.

Ownership needs care. Portability needs a drill. Ask for both.

The facts on this page that mirror the outside world were last checked against their sources on 9 August 2026; they are re-checked at every review.