Who owns your AI-built app? Code, accounts and the ability to leave

Conceptual illustration, not a customer photograph.

Owning an AI-built app means checking more than whether you can download its source code. You need to understand the contractual rights, control the accounts that keep it running and know how its code and data could move elsewhere. Check each of these before making the platform part of a business-critical product.

Separate rights, control and portability

Start by asking three separate questions. What do the contracts permit? Can the business access the repository, domain and service accounts? Could it move the functioning application, with its dependencies, to another suitable host? These describe contractual rights, operational control and portability respectively. Establishing one does not settle the others.

Consider a founder who receives the source code while a freelancer retains control of the domain and database. Another business might control every account yet have no instructions for rebuilding its app. Both have unfinished handoffs. Close those gaps while the person who created the setup is still available.

These checks concern operating an app and do not constitute a legal opinion. Get advice specific to your contracts and jurisdiction for an ownership dispute, licensing question or proposed acquisition.

What a platform’s documentation can establish

According to Lovable's ownership and deployment documentation, users own the apps, code and content they create, subject to third-party rights. The provider also treats frontend, backend and whole-app moves separately. Read the applicable terms alongside that published position before making a business decision based on it.

The GitHub integration documentation describes code export and synchronisation. Having that repository makes review and handoff easier, but it is not evidence that anyone has successfully moved your particular application.

Identify the framework and runtime your app actually uses, along with its external services. A migration guide written for another framework may not apply, even within the same platform. Have a maintainer record which components would still depend on the original provider after the proposed move.

Build an account and dependency inventory

• Repository: identify the owning organisation, administrators and branches, and retain build instructions.
• Domain: record the registrar, DNS configuration, renewal owner and recovery contact.
• Data: document database ownership, export format, stored files, and retention and deletion requirements.
• Authentication: list login providers, redirect addresses, recovery arrangements and email delivery.
• Payments and integrations: identify account owners, webhook destinations, secrets and usage charges.
• Deployment: record the host, environment settings, scheduled work and monitoring.

Record account names and the people responsible for them. Store credentials in an appropriate password or secrets manager, outside this inventory. Where possible, give collaborators individual access so removing one person does not interrupt everyone else's work.

Verify that the business has authority to recover and renew each service, as well as a login that works today. A shared account may still send recovery messages to a former employee's personal email. Resolve that during the handoff, before an outage or missed renewal makes access urgent.

Run a small exit rehearsal

Rehearse with a project copy containing synthetic or appropriately protected data. Start in a clean environment, follow the build instructions and configure the necessary services. Then complete a core task. Add every newly discovered dependency to the inventory as you go.

Investigate the pieces that may stay behind: uploaded files, scheduled tasks, email templates, authentication settings and provider-specific calls. Loading the homepage does not exercise those functions. Finish the rehearsal only once you understand the recovery procedure and have completed the chosen task.

Budget for the move itself, not just the destination's hosting price. Data transfer, testing and downtime planning take work, as does maintenance afterwards. The estimate may lead you to stay with the current provider. You will still have a clearer account of what the business depends on.

AI-generated output adds a separate rights question

Permission from a platform to use generated output does not settle whether each element qualifies for copyright protection. In its January 2025 report announcement, the U.S. Copyright Office says protection requires sufficient human-authored expressive elements; prompts alone do not establish authorship. This is the U.S. position, not a rule that applies globally to every app.

Document commissioned assets and their licences, open-source dependencies, and substantial human contributions. Restrictions on a font, image or library can survive an export. Have the relevant rights reviewed when an asset is disputed or forms part of a transaction.

Give each account, obligation and recovery step a named owner. Then use the production checklist to examine how the app behaves and the maintenance guide to assign its ongoing operation.

A worksheet you can reuse

For each component record: business owner, admin access, export path and recovery owner.

Code repository: [ ]
Domain and DNS: [ ]
Database: [ ]
Uploaded files: [ ]
Authentication: [ ]
Payments: [ ]
Hosting and scheduled tasks: [ ]
Email and external APIs: [ ]

Last isolated rebuild and outcome: [ ]
Unresolved dependencies: [ ]
Secure credential location, not the credentials: [ ]