What does a Lovable export actually give you?

Owning generated code is useful, but it does not mean you can leave a platform on Friday and run the same product elsewhere on Monday. A Lovable export can give you a normal source repository. It cannot, by itself, transfer a live database, authentication state, stored files, secrets, domains, deployment controls, monitoring, or the habits your team built around the platform.

That distinction matters most after a prototype becomes a business system. Founders tend to ask, "Do we own the code?" Procurement tends to ask, "Can we export it?" Both questions are too narrow. The practical question is whether another competent team can rebuild and operate the service, with its data and security controls intact, on infrastructure you control and within a time you can afford.

My test is blunt: an exit is real only after a clean machine can build the exported commit, a separate environment can serve it, and a rehearsed data migration can restore a usable application. Until then, ownership is a legal right attached to an untested recovery plan.

Code ownership and operational independence are different

Lovable's documentation says creators own their projects and generated code, and its terms describe applications, websites, and AI output as customer property, subject to third-party rights. That is a meaningful ownership position. It lets you copy, modify, and deploy the output without asking the platform to assign each generated file to you again.

The same terms reserve Lovable's platform, cloud, models, interfaces, tools, and other materials to Lovable. This is normal for software as a service, but it draws the boundary founders often miss. You own the house plan the system produced. You do not own the editor, generation workflow, managed runtime, internal deployment machinery, or every dependency used to turn that plan into a working building.

There is another qualification. AI output may resemble other output, and generated code can include open-source packages, icons, fonts, sample data, or code suggested from third-party material. "The vendor says we own the output" does not erase the licenses or rights attached to those inputs. Run a dependency and asset review before an acquisition, enterprise sale, or regulated launch. Record package licenses, remove assets with unclear provenance, and keep evidence for anything your team supplied.

This separates three claims that teams routinely blur:

• Legal ownership means the contract does not claim your application as the vendor's property.
• Technical possession means you have a current copy in a repository you administer.
• Operational portability means you can build, deploy, restore, secure, and support that copy elsewhere.

Account ownership can still break the chain. If a founder, freelancer, or agency created the workspace under a personal account, the company may own the commercial idea while lacking administrative control over the project, repository, domain, or paid subscription. Move those assets into company-controlled accounts before the relationship becomes tense. Give at least two employees the administrative access needed for recovery, and store recovery methods under company control.

Put contractor terms around the platform terms. Your agreement with Lovable cannot assign rights that an agency kept in its own contract. Require the contractor to assign project-specific work, disclose reused components, list third-party licenses, transfer repository history and documentation, and delete retained credentials and customer data after acceptance. Record any pre-existing library the contractor licenses rather than assigns.

Check contribution rights inside the company as well. Employment and invention-assignment agreements should cover the people who prompt, edit, review, and deploy the application. This matters because the final repository can combine generated output with human-authored code, purchased design assets, and copied snippets. Due diligence asks for a clean chain of title across the whole product, not a screenshot of one vendor FAQ.

Administrative control also affects the export itself. Lovable limits GitHub connection management to appropriate workspace roles, so an engineer with edit access may not be able to create the repository during an emergency. Test the permission path while the account owner is available. Document who can transfer project ownership, authorize the GitHub app, approve organization access, and disconnect the project.

You need all three for a credible exit. The first without the other two can still leave the company stuck during a pricing dispute, account suspension, outage, or due diligence review.

The export is a source tree, not a running company

Lovable offers two practical code paths. Its code editor can download a full project codebase as a ZIP on paid plans. Its GitHub integration creates a repository and supports two-way synchronization on the default branch. The documentation says the repository remains in GitHub after you disconnect, while changes stop syncing.

For a typical project, expect application source, package manifests and lockfiles, public assets stored with the project, styling and configuration files, database migration files if the project uses them, and server or edge function source that lives in the repository. The exact tree depends on when the app was created and which backend it uses. Lovable's FAQ currently distinguishes newer TanStack Start applications from older React and Vite applications, so do not approve an exit plan based on a generic screenshot of somebody else's repository.

Inventory the actual export with commands that produce reviewable evidence. After cloning into an empty directory, run:

git ls-files > exported-files.txt
git log -1 > export-commit.txt
find . -type l -print > symbolic-links.txt

The first file records everything under version control. The second binds the review to a commit and timestamp. The third catches links that may point outside the copied tree. Then inspect the package scripts, lockfile, runtime version, environment variable references, migrations, and generated files. A ZIP without Git history is adequate for an emergency copy, but it is a weak handover artifact because you lose authorship, change history, tags, and the exact relationship between deployed code and a commit.

GitHub synchronization also has operating constraints. Lovable documents one linked repository per project, sync on the default branch, and a connection that depends on the repository's name, owner, organization, and location remaining stable. Renaming or moving the repository can break the connection. It also says an existing external repository cannot simply become a Lovable project. Treat the linked repository as company infrastructure from day one: put it in the company organization, require multifactor authentication, limit the app's repository access, protect the default branch, and keep an independent mirror or scheduled archive.

Do not count a successful clone as an exit test. A repository can be complete and still fail to build because the runtime version is implicit, a package was fetched from a private registry, or a build variable exists only inside the vendor workspace. Possession starts the work; it does not finish it.

Runtime state is where most lock-in hides

The export generally captures declarative code, not every piece of live state around that code. Your exit inventory should name each stateful asset, its owner, its export method, its restore method, and the maximum tolerable loss. If any row says "we can probably recreate it," you have found unpaid migration work.

Live database rows are separate from schema migrations. A migration can recreate tables, indexes, policies, and functions, but it does not recreate customers, orders, audit records, authentication identities, or consent history. Take a database-native logical backup, encrypt it, restore it into a clean target, and compare record counts and application behavior. For a large or active database, define how you will capture changes between the initial copy and final cutover.

Object storage needs its own transfer. Product images, user uploads, generated reports, and attachment metadata may reference provider-specific bucket names or URLs. Copy the blobs, preserve content types and access rules, rewrite references where needed, and test both public and private downloads. A database backup that restores file metadata but not the files creates a product that looks healthy until users open old records.

Secrets should not appear in a source export, which means their absence is good security and an exit requirement. Make a controlled inventory of build variables, runtime variables, signing secrets, webhook secrets, encryption keys, service credentials, and certificate material. Move values through a secrets manager, never through the repository. Decide which credentials can transfer and which must rotate because the platform or a departing contractor had access.

Identity is harder than copying an email column. Password hashes may not be exportable or compatible. Social login depends on OAuth applications, redirect URIs, signing keys, and provider review. Passkeys, multifactor enrollment, active sessions, recovery codes, and email templates all need decisions. A safe migration may require users to reset credentials or reauthenticate. Product and support teams need to prepare for that friction instead of discovering it during cutover.

Domains, DNS records, email sending reputation, scheduled jobs, queues, analytics history, logs, alerts, backups, rate limits, firewall rules, and abuse controls also sit outside the source tree. Write each one down. The awkward assets are usually the ones that turn a two-day frontend move into a six-week production migration.

Your backend choice determines the rebuild

Moving a mostly static frontend is straightforward compared with moving a managed backend. Lovable documents that its frontends can run on common Node.js or static hosting infrastructure. If the application calls portable third-party APIs and keeps little state, another host may need only a build command, environment variables, routing rules, and a custom domain cutover.

A Lovable Cloud or Supabase-backed application carries a larger service boundary. Lovable's self-hosting documentation warns that a standalone PostgreSQL server is not enough for applications that rely on Supabase-style authentication, storage, realtime updates, and edge functions. Its documented self-hosting route applies migrations from supabase/migrations/, changes the Supabase URL and publishable key, and makes your team responsible for backups, security patches, row-level security, function deployment, monitoring, scaling, and incident response.

This is the sharpest lock-in distinction in the project. Database portability asks whether you can move tables and rows. Service portability asks whether the target reproduces every behavior around those rows. Replacing managed storage with PostgreSQL alone will not make signed file URLs work. Restoring user records will not necessarily preserve sessions. Deploying an edge function's source does not recreate its schedules, secrets, network policy, or logs.

The platform's Cloud documentation says moving a Cloud project to Supabase is technically possible but not straightforward, and that some Cloud features do not exist outside Cloud. Take that qualification seriously. Before choosing a backend for a production build, make a feature map with four columns: feature used, current provider, portable equivalent, and migration test. Include authentication, storage, realtime, functions, AI calls, email, scheduled work, and administrative access.

Do not respond by avoiding every managed service. That recommendation sounds safe because commodity infrastructure feels controllable, but it often makes a small company pay an operations tax long before an exit. Managed services can be the right trade when they save months of work. The sane goal is measurable dependence: know which capabilities you rent, keep data exportable, and rehearse the path whose cost you accepted.

A clean-room exit drill exposes the missing pieces

Run the exit drill before the product becomes too important to interrupt. A developer who built the app should not be the only person performing it, because their laptop and memory contain undocumented state. Give a second engineer a fresh machine or isolated runner, the repository, a written runbook, and access only to the credentials the runbook names.

A useful drill has five stages:

1. Freeze an export commit and record the currently deployed version.
2. Build from the lockfile with network access limited to documented registries.
3. Provision a blank target from versioned infrastructure and migrations.
4. Restore sanitized production-shaped data plus representative stored files.
5. exercise sign-in, role checks, writes, background work, email, file access, rollback, logging, and alert delivery.

Capture the results as evidence, not a chat message that says "it worked." Keep build logs, infrastructure revisions, migration duration, failed checks, manual steps, and the owner of each repair. Record recovery time and how much data the process loses. You do not need invented targets copied from a larger company. Set recovery objectives that match the cost of your own outage and verify that the drill meets them.

Use a small acceptance file in the repository so the exit definition survives staff changes:

exit_test:
  source_commit: required
  clean_build: required
  database_restore: required
  object_count_check: required
  auth_role_tests: required
  background_jobs: required
  dns_rollback_plan: required
  owner: platform-lead

This fragment does not automate the migration. It prevents the team from declaring victory after the frontend loads while writes, private files, or scheduled work remain broken. Turn each requirement into a test or a signed manual check, and fail the drill when evidence is missing.

Repeat the drill after changing backend providers, authentication, billing, storage, deployment architecture, or regulated data flows. A quarterly rehearsal may suit a product with frequent infrastructure changes; a small internal tool might need one after major releases. The cadence matters less than tying it to changes that alter the exit path.

A production cutover needs overlap and a way back

A migration is not complete when the new environment passes a smoke test. It is complete when users reach the new service, new writes land in the right place, operators can see failures, and the team can reverse the change without corrupting either side. Plan the cutover as an operating event, not the final task on a development ticket.

Start with data movement. For a quiet internal app, a maintenance window and one final backup may be enough. For a customer product that changes constantly, take a bulk copy first, then capture subsequent changes until the target catches up. The mechanism might use database replication, an application-level event log, or a short write freeze. Pick one deliberately. Running two writable databases without conflict rules creates divergent records that no DNS rollback can fix.

Lower DNS time to live before the change if your provider and policy allow it, but do not pretend DNS controls every client. Browsers, corporate resolvers, mobile networks, and long-running workers can retain old addresses. Keep the old endpoint available during the overlap, and make its behavior explicit. It may remain read-only, forward requests, or reject writes with a maintenance response. Silent acceptance on both sides is the dangerous option.

Authentication deserves a separate launch plan. Test existing sessions, new sign-ins, password reset, email verification, social login, multifactor recovery, role enforcement, and logout across the cutover. If sessions cannot move, tell users they will sign in again and make support ready for locked accounts. Never weaken role or row-level checks temporarily just to get the migration through.

Define rollback before deployment. A useful rollback trigger names a symptom, a threshold, the person authorized to decide, and the last safe point for reversing writes. "Roll back if it looks bad" fails under pressure. So does a rollback that restores the old frontend while new orders already exist only in the new database.

Run both environments long enough to compare evidence. Check request errors, job completion, email delivery, file access, authorization failures, database writes, and business events such as completed purchases or submitted forms. Synthetic tests help, but compare real aggregate behavior without exposing personal data. A green home page says little about the paths that pay the bills.

After the cutover, revoke old credentials, remove obsolete OAuth redirects and webhooks, close unneeded network access, and archive the final vendor export with its checksum and contract record. Keep the old environment only for the approved retention period. An abandoned environment with production data and forgotten credentials is not a backup; it is an unmanaged breach path.

Assign one incident lead and one recorder during the change. Engineers should not reconstruct the timeline from private messages afterward. The recorder logs each migration command, decision, timestamp, and observed result. That record supports rollback during the event and turns the next rehearsal into a shorter, safer exercise.

Contract language should buy time and usable artifacts

A contract cannot make an undocumented system portable, but it can remove avoidable ambiguity when the relationship ends. Have counsel adapt the language to your jurisdiction and deal size. A founder can still identify missing subjects before legal review.

Start with ownership and license scope. The agreement should say that the customer owns its inputs, project code, generated output, application configuration, and data, while recognizing the vendor's pre-existing platform and third-party components. Confirm that your rights to use exported output survive termination. Ask who bears the risk if generated material triggers an intellectual property claim, and compare the answer with the liability cap and indemnity exclusions.

Define export as a deliverable, not a button. Name source code, commit history, schema and migrations, customer data, files, logs needed for compliance, configuration that can safely transfer, and a machine-readable format. State who may request it, how often, how long generation may take, and whether the service must remain available while you verify the export. Require reasonable notice before a breaking format change where the commercial agreement can support it.

Termination language should include an extraction window, continued read access, deletion timing, backup retention, and written confirmation after deletion. Avoid a clause that deletes everything immediately when the subscription ends. It conflicts with the practical need to validate a restore. Also avoid indefinite vendor retention "for business purposes" unless security, legal, and product teams have accepted it.

Review data rights separately from code ownership. Lovable's public terms grant a broad license to process customer data for operating and improving services and describe an opt-out for prospective model training and other business uses. The version that binds your company may differ by plan, order form, region, or effective date. Record the accepted version, exercise any required opt-out, and negotiate limits for confidential code or personal data rather than assuming an ownership sentence covers processing.

For production or regulated use, check the data processing agreement, subprocessors, breach notice, audit evidence, data location, government request handling, cross-border transfer terms, and return or deletion duties. Check service levels, support response, planned discontinuation notice, unilateral price changes, and suspension rights. Make transition assistance concrete: named activities, hourly rates or included hours, scheduling priority, and a cap. "Reasonable assistance" becomes an argument exactly when you need help fastest.

Finally, protect the domain and customer-facing identity outside the platform. Use a domain controlled by the company, keep registrar and DNS access in company accounts, and spell out what happens to any platform subdomain. Lovable's public terms state that users do not own a specific lovable.app subdomain and should use a custom domain for mission-critical applications. That is unusually direct advice, and I agree with it.

Lock-in is a cost model, not a yes-or-no label

Every productive tool creates some dependence. The useful measure is how much it would cost, how long it would take, and what might break if you had to replace it. Calling Lovable either "fully portable" or "hopelessly locked in" hides the engineering choices that control those numbers.

Estimate exit cost by workstream. Price the frontend build and deployment, backend service replacement, data and file transfer, identity migration, third-party reconfiguration, observability, security review, user communication, parallel operation, and rollback. Add vendor assistance and the revenue or staff cost of a maintenance freeze. Put a confidence range next to any work nobody has rehearsed.

Then score concentration. A platform can own no legal rights to your code while still concentrating editor access, cloud hosting, database services, deployment, and AI generation in one account. Conversely, an app may depend heavily on a managed database but remain cheap to move because the team keeps tested backups, versioned migrations, and provider-neutral boundaries. Count replaceable capabilities, not vendor logos.

Track four numbers after each exit drill: time to produce the export, time to build it cleanly, time to restore production-shaped state, and number of undocumented manual interventions. The trend is more useful than a made-up portability score. If restore time rises after every feature launch, the team is borrowing against a future migration.

There is also a staff dependency. If only the person who prompted the original application understands its behavior, exporting the repository does not transfer ownership in a practical sense. Require code review, architectural notes, incident runbooks, and named service owners as the system grows. Generated code does not excuse a company from knowing how its product works.

Stay for speed, but keep the exit credible

A startup should leave when dependence blocks a business requirement, not because self-hosting sounds more serious. Reasons to move can include data residency, unsupported compliance controls, unacceptable outage exposure, unit economics at scale, a backend feature the platform cannot provide, or an acquisition requirement. Each reason should have a measurable threshold and an owner.

Staying is rational when the platform saves more engineering time than the expected exit cost, the application fits the supported architecture, and your tests show that the important assets remain recoverable. You can lower risk without leaving: sync to a company repository, archive it independently, use a company domain, maintain database and object backups, inventory secrets, document third-party accounts, and run the clean-room drill.

The worst moment to discover the boundary is during an outage, financing deadline, or vendor dispute. Put a one-page exit register beside the architecture decision record now. Name every asset, export method, last successful restore, owner, and unresolved dependency. Update it when a feature adds a new service.

For teams that have grown by prompting faster than they can document, a Team & AI Audit from oleg.is can map the application, operating gaps, and engineering work before a migration decision. The audit is not a substitute for the drill. Its useful output is a smaller list of assumptions your own team can test.

Keep using the speed you bought. Just refuse to call source ownership an exit until another environment has proved it can run the business.