Choosing a service means accepting some dependency. That is true of a host, a database, an email service, and it is true of AI development platforms. So the useful question is not "am I dependent?". It is "how much would leaving cost me, and could I do it if I decided to?".
The four layers of dependency
An app built with Lovable, Bolt, v0, Replit or Base44 rests on several layers, which do not all move the same way:
| Layer | Examples | What to check |
|---|---|---|
| The code | Interface, logic, server functions | Export available, Git repository under your control |
| The data | Database, files, users | Export method, format, account owner |
| The accounts | Domain, email, payments, hosting | Holder, administrator access, billing |
| Platform-specific services | Built-in database, in-house auth, connectors | Equivalent available elsewhere, replacement effort |
Dependency is often low on the code, higher on the data and platform-specific services, and sometimes invisible on the accounts, until the day you discover the domain belongs to a former contractor.
What the platforms say
Situations differ by tool and configuration. Lovable syncs the code both ways with a GitHub repository created in the account or organisation of your choice, private by default, and that repository stays in place if you disconnect. Lovable's GitHub documentation does not cover the database, files or secrets: those depend on Supabase or Lovable Cloud and must be inventoried separately.
Our pages on Lovable, Bolt, v0, Replit and Base44 detail, with official sources, what can be exported, what stays tied to the service and what depends on the project's configuration.
On the regulatory side, the European Data Act, applicable since September 12, 2025, creates a framework to make switching cloud providers easier. It does not solve the technical questions of a migration, but it strengthens your position to obtain your data.
How to measure your dependency
- Does the Git repository exist, and who owns it? It should sit in an organisation in the company's name
- Can you export the data today? Test it once, on a copy, with files and users
- Who holds each account? Domain, database, host, email, payments, analytics
- Which features rely on a platform-specific service? For each one, is there a standard equivalent?
- Are the variables and secrets documented? Without them, exported code will not start anywhere else
Our guide to exporting and owning your AI app's code walks through these checks platform by platform.
A concrete example
A real estate agency has been using a viewing-management app built with Base44 for a year. The app works well. A partner asks for an integration with its software, and the board wants to know what would happen if the platform changed its pricing.
The analysis shows a medium dependency: the code can be retrieved, the data exports, but authentication and two automations rely on platform-specific services. The decision: stay, move the accounts into the agency's name, schedule a monthly data export and document how to replace the two automations. Cost: a few days. The way out is known, without a migration.
The most common mistakes
- Confusing code export with independence: code without the data, accounts and configuration will not restart
- Leaving accounts in a contractor's name or under a personal address
- Never testing the data export before you need it
- Migrating on principle, with no specific need, and creating a new dependency elsewhere
- Inferring dependency from the platform alone, without looking at the project's actual configuration
The takeaway
Vendor lock-in is managed like a risk: you measure it, document it and reduce it where the stakes justify it. Staying on a platform is a legitimate choice, as long as the exit is possible and costed. The vibebusters Scan maps it layer by layer, and the Production Upgrade handles account transfers or the migration once it has been decided.