Is your AI-built website actually portable?

Portability isn’t binary

A website built with an AI tool is portable to the extent that each of its layers could be picked up and moved. The code is one layer. The hosting, the domain, the database, the sign-in, the uploaded files, the credentials and the deployment path are others. A site can have completely portable code and still be pinned to one platform by its database, or have every account in your name and still be unbuildable elsewhere because the secrets live in a panel nobody can read.

So the useful question isn’t “is it portable?” but “which layers are mine, and which would need work?”. The nine questions below are that, in order. Each has a definition of what a real “yes” means, a check that takes minutes, and the guide that turns a “no” into a “yes”.

The nine questions

1. I can access the source code.

   Yes means: You can open the files that make up the site, today, without asking anyone. A view inside a builder doesn’t count unless it can export or sync them.

   Check: Find the repository or the export option and open the files. Guide 1.

2. The source is stored in an account I control.

   Yes means: The repository’s owner is your GitHub account or an organization you own, with your email and 2FA. A collaborator invitation on someone else’s repository is access, not control.

   Check: Read the owner in the repository address and confirm you can open its Settings. Guide 2.

3. I know where the site is hosted, and the account is mine.

   Yes means: You can name the host, sign in to it, and see the project. Your card, your email.

   Check: Run the diagnostic from the domain name to the host. Guide 3.

4. I could change hosts without rebuilding the site.

   Yes means: The host deploys from the repository, and a different host could be connected to the same repository with the same settings and variables.

   Check: Look at the host’s Git settings, and list the environment variables it holds. Guide 4.

5. I control the domain.

   Yes means: The domain is in a registrar account in your name, or you can transfer it into one, and you know where its DNS is managed.

   Check: Look the domain up and try to sign in to the registrar it names. Guide 5.

6. I know where the database and every external service live.

   Yes means: For each store of data and each service the site calls, you can name the provider, the account owner, and whether it exports.

   Check: Run the data inventory. Guide 6.

7. I control the credentials.

   Yes means: Every API key, database password and sign-in secret was issued from an account you own, and you have a list of their names and where each is regenerated.

   Check: List the environment variables on the host and trace each to its issuer. Guide 7.

8. Another developer or AI coding agent could run the project.

   Yes means: Someone with the repository and the variable list could build and run the site without the original builder’s account or its managed services.

   Check: Ask: what would they need that isn’t in the repository or the variable list? Guide 8.

9. I can deploy without relying on one proprietary builder.

   Yes means: A push to the repository reaches the live site through a host you control, and would still if the builder disappeared.

   Check: Make a small change directly in the repository and watch it go live. Guide 9.

Scoring it

Count your honest yeses out of nine, but weight them. The first two and the fifth are the ones that can’t be recovered later: if the code or the domain isn’t yours, everything else is provisional. Fix those first, whatever the total.

Why owning the code isn’t enough

Builders have got good at the code layer. Most can put your source in a GitHub repository under your account, and several keep it in sync. That’s real ownership of the code, and it’s the layer this site’s guides start from. But the code is a description of the site, not the site. The live site also needs:

• A database, which may run inside the builder (Lovable Cloud, Bolt Database, Replit’s databases) or in a provider account of your own.
• Sign-in, which may be a service you own or the builder’s own login system, as with Replit Auth.
• Uploaded files, in a storage bucket somewhere.
• Secrets, which are deliberately not in the code and often can’t be read back out of the builder.
• Managed keys, where the builder calls an AI model or a payment provider on your behalf through its own account.
• A deployment path, which for a builder-hosted site is the builder’s publish button.
• A domain, which may be registered through the builder.

None of those moves with a repository. Each is a separate account, export or re-issue. The platform guides below say, for each builder, which of these it runs for you and what its documentation says about getting each one out.

Your builder, specifically

For each builder we’ve checked against its current documentation, there are two guides: an honest account of what you own there and what still depends on the platform, and the procedure for taking the site with you.

• Lovable: Do you own your Lovable site? · Move a Lovable site to GitHub and your own hosting
• Bolt: Do you own your Bolt site? · Move a Bolt site to GitHub and your own hosting
• Replit: Do you own your Replit site? · Move a Replit site to GitHub and your own hosting
• v0: Do you own your v0 site? · Move a v0 site to GitHub and your own hosting

Built with a coding agent such as Claude Code, Cursor or Codex rather than a builder? Then the code was in a repository from the start, and the questions that matter are three to nine. The ownership overview walks through them.

The real test

Not “could they see it”, and not “could they rebuild it from the code”. Take it over: deploy it, change it, keep it running, with nothing from the original builder except what’s in the repository and your accounts. If the answer is a clean yes, the site is yours. If the answer has a “but”, the “but” is the next thing to fix.