A source-code download can look like the end of a migration. There is a folder on your computer, perhaps a repository under your company's name, and a reassuring sense that the app is now yours to run.
Then someone tries to use it elsewhere. The home page loads, but a sign-in callback points to the old address. Uploaded files still live in another service. An AI feature depends on a connection the original platform managed. The code has moved; the operating arrangement has only partly moved with it.
These are illustrative possibilities, not incidents from a client project. They explain why a founder evaluating an AI app builder needs a more precise meaning for the word “export.”
Three different kinds of freedom
Possessing a copy of the source gives a developer something concrete to inspect and maintain. Deploying that source on a different host gives the team another way to deliver the application. Running independently of the builder's services goes further: the systems behind sign-in, stored files, data access and integrations must also be accounted for.
An app can achieve the first two while deliberately keeping its existing backend. That can be a sensible arrangement. A team may want its own release process without taking on database operations at the same time.
Lovable's current Git sync documentation describes automatic two-way synchronization between a project and a repository the user owns. Its hosting and ownership documentation separately describes moving the frontend, moving backend services, and completing a move away from Lovable. Those are different scopes of work, even when all three begin with the same codebase.
The distinction matters more than a simple export checkbox in a comparison table. A download answers whether files can leave. It does not, on its own, show which services the application will still call tomorrow.
A working app has a service map
The visible screens tell only part of the story. Behind them are the places where customer records live, the service that verifies a user's identity, the account paying for an AI request, and the destination receiving a payment notification.
For a business buyer, a useful migration conversation follows that map. Each dependency needs an owner and a decision: keep it, move it, or replace it. Keeping a service is a valid choice when access, cost and responsibilities are understood. Replacing one deserves its own estimate rather than being hidden inside “deploy the code.”
Credentials deserve particular care. A developer needs a documented way to configure the new environment, not a source repository filled with production secrets. Configuration instructions and access to an appropriate secret store serve different purposes from committing passwords to code.
Data has its own timeline as well. A copy taken on Monday does not include Tuesday's new records. A migration plan therefore needs to explain what happens to changes made while the move is under way, and when the old system stops accepting them.
Backups can be narrower than their names suggest. Bolt's backup documentation explicitly says restoring an earlier project version does not change the current Bolt or Supabase databases. Reversing a code change and reversing its effect on stored data are separate operations. That distinction should shape any rollback plan.
Independence comes with an operating job
Managed hosting can be valuable precisely because another team handles parts of the operating work. Moving away transfers some of that responsibility: someone must own releases, monitoring, backups and incident response. A cheaper hosting bill is only one part of the calculation.
Portability is therefore useful even when a business never intends to leave its builder. It makes dependencies visible, gives a future maintainer a clearer starting point, and helps a buyer distinguish an available option from a ready-to-use migration.
A practical definition of “we can leave” names the boundary. Perhaps the team can move the website while keeping its current database. Perhaps it can operate the entire application independently, with documented replacements for platform services. Both statements can be honest; they promise different amounts of work.
When a team records that boundary clearly, it can keep the convenience of an AI builder without confusing a folder of source files with a complete operating business system.