AI App Builder Vendor Lock-In (2026): The Five Layers, and Why Your Weakest One Sets the Bill

Quick Answer

In 2026, vendor lock-in on an AI app builder is not one property with one score. It is five separate layers, and they fail independently: your code, your data, your users and their credentials, the runtime your exported code still calls, and the terms of the exit itself. The layers do not move together. Lovable will hand you your full database structure and data and states in the same document that "User passwords are not exported in a usable form." Base44 will sync your source to your own GitHub repository and warns that the sync "is permanent" and that you "can't disconnect or transfer the project back to Base44." Bolt.new will migrate its database into your own Supabase organisation, but only if you hold an org-owner role in an account Bolt does not control. Your migration bill is set by your weakest layer, not your average, so a builder that scores strongly on code and data can still be the hardest one to leave. The tables below score six builders layer by layer.

Lock-in is five layers, not one score

Ask most people how locked in they are and they will answer with code. Can I export it, is it real framework code, is it in my repository. That is a good question and it is roughly a fifth of the answer.

Here are the five layers that actually decide what a migration costs:

1. Code. Does standard framework source leave the platform, into a repository you control?
2. Data. Does the schema leave with the rows, at full fidelity, or only a rendering of them?
3. Identity. Do your user accounts leave, and do their credentials leave with them?
4. Runtime. Once exported, does the code run without calling the vendor's servers?
5. Exit terms. What does taking the exit cost you: which plan, which role, is it reversible, and what do you lose by using it?

Layers 1 and 2 are the ones the industry scores, including us. Layers 3, 4 and 5 are the ones that surprise people, and in our reading of the primary documentation they are where the real cost sits.

The weakest-layer rule

There is a temptation to average the five layers into a single lock-in grade. Do not. Migration is a sequence, not a portfolio: every layer has to clear before the app runs somewhere else, so the process stalls at the first one that does not.

A worked example makes it concrete. Suppose a builder scores excellently on code (real React in your own repository) and excellently on data (a full PostgreSQL dump). You could reasonably call that a low-lock-in tool. Now add 4,000 registered users whose password hashes cannot leave. You can stand the app up on your own infrastructure in an afternoon, and you still cannot let a single existing customer log in. The migration is not 80 percent done. It is blocked, and the remaining work is a mass password-reset campaign with measurable churn attached to it.

So the rule is: find your weakest layer and price that, because that is the invoice. Averages hide exactly the thing you need to see.

AI app builder lock-in, scored by layer (2026)

Scored against each vendor's own public documentation, August 2026. "Not documented" means the capability is absent from the vendor's public materials at the time of writing, not that it is confirmed impossible.

A correction to our own earlier scoring. In July 2026 our code ownership comparison recorded Base44 as having no documented source export. That is now out of date: Base44 documents GitHub 2-way sync plus a local development setup, so its code layer has genuinely improved. Its runtime and exit-terms layers are a different story, below.

Layer 3, identity: the layer nobody scores

This is the finding that reordered our whole view of the question. Across six builders, the layer least likely to travel is not the code and not the database. It is your users' credentials.

Lovable says it in one clause. Its Cloud export "contains your full database, both structure and data," and in the same breath: "It does not include files in storage buckets, edge function code, or your project's secrets," and "User passwords are not exported in a usable form either" (Lovable advanced settings docs, 2026). Read the whole sentence. The database is portable. The logins are not, and neither are your uploaded files, your serverless function code, or your API keys.

Bubble is even more direct about the mechanism. "The password field is different from all other fields in that it is invisible even to you as the app developer," kept via one-way hashing and salting so that "even we do not have access to the user's original password" (Bubble manual, 2026). That is not a portability policy. That is a correct security architecture, and portability is its casualty.

The most interesting corroboration comes from an unexpected direction: a competitor's import manifest. Base44 documents inbound migration from Lovable and Bolt.new, and it specifies exactly what it can reach: "All user-created tables in the public schema (schema + data)", column schema, "Primary keys and foreign keys", the row-level-security flag, and "Frontend source from GitHub repo" (Base44 migration docs, 2026). The public schema travels. The auth schema is not on the list. And for WordPress sources, the same page imports Users with a parenthetical that says everything: "(self-hosted only)."

So there are exactly three ways identity moves, and it is worth knowing which one you have:

• The vendor hands you usable hashes. The destination then has to accept your format. Supabase, which sits under several builders in this comparison, "supports bcrypt and Argon2 password hashes," and will also take plaintext if that is what you hold (Supabase auth migration guide, 2026). Note the corollary: an import path exists on the receiving end, so when identity does not move, the blocker is usually the sending end.
• The vendor runs the migration for you.

  

  Replit is the standout here. Its documented agent flow "moves your Replit Auth user data to Clerk, including account identity details and supported sign-in credentials," waits for that to finish before touching your app, and leaves your schema alone: "It does not update your app's existing database data or schema. Your tables and relationships remain intact" (Replit auth migration docs, 2026). Expect ten minutes to an hour of agent work, and up to a couple of hours of data migration on a large user base. Read "supported sign-in credentials" carefully; supported is doing work in that sentence.
• Everybody resets their password. This always works and it is never free. It is a re-consent event across your entire user base, and a share of them will not come back.

Replit deserves a second note, because its identity layer is the category's most unusual in both directions. With Replit Auth, "when someone signs in to your app, they are creating or using an existing Replit account," the login page is Replit-branded, and signups "are added to your pending Replit Referrals" (Replit Auth docs, 2026). Your end users hold accounts with your vendor, and your signups feed the vendor's referral programme. Replit documents this plainly and offers Clerk as the alternative, describing it as giving "user accounts that are independent of Replit." One more detail worth knowing before you start: with Replit Auth, "Manual implementation is not supported," so the auth code in your project is agent-authored by design. Which identity system a builder hands you in the first place, and whose brand your users see on the sign-in screen, is scored separately in our AI app builder built-in auth comparison.

Layer 4, runtime: owning the code is not the same as running it

Here is the trap that a code-ownership scorecard cannot catch, and Base44's own documentation is the clearest illustration in the category, precisely because it is unusually complete.

Connect a Base44 app to GitHub, clone it, and the documented local setup asks you to create an .env.local containing two variables:

VITE_BASE44_APP_ID=your_app_id
VITE_BASE44_APP_BASE_URL=your_backend_url

with the worked example pointing at a base44.app host (Base44 GitHub integration docs, 2026). The source is on your laptop. It is yours. It also cannot function without the vendor, because what you cloned is a front end configured to call the vendor's backend. Run npm run dev with those variables unset and you do not have a portable application; you have a directory of components.

This is what makes an umbrella lock-in question different from a code-export question. "Do I have the code" and "can I run the code without you" are two questions, and on a managed-backend builder the answer to the first is increasingly yes while the answer to the second stays no. Lovable draws the same boundary from the other side: remove Lovable Cloud and the app loses its database, storage, authentication and edge functions, and "Removing Lovable Cloud permanently deletes your Cloud instance and cannot be undone." Even a temporary pause is not neutral: "While paused, your backend is unavailable, and your deployed app can't read or write data until you resume."

The practical test is one sentence long: can this code serve a request with every vendor-issued environment variable removed? If not, the runtime layer is where your lock-in lives, whatever the code layer says.

Layer 5, exit terms: the door has its own price list

The last layer is the one almost nobody checks, because it only becomes visible when you reach for the handle. An exit can exist and still carry preconditions, irreversibility, and a bill. Four documented shapes, from the vendors themselves:

That last row is the one to sit with, because it shows up on two independent vendors with no relationship to each other. It looks less like a quirk and more like a structural consequence: a platform can only time-travel state it fully controls, so the moment you move state somewhere it does not control, time travel stops. Portability and convenience are trading against each other, and both vendors document the trade honestly.

Two more asymmetries worth naming. Bolt's escape hatch is conditioned on a choice you make before you know you need it: Supabase connections are "available with Vite projects. Next.js projects are not supported at this time," and switching later "requires extra steps," with a warning that connecting a Supabase database over an existing Bolt database "may cause data loss" (Bolt Supabase integration docs, 2026). And the door swings one way: "There's currently no supported flow for migrating Supabase databases to Bolt databases."

Lovable's asymmetry is stated in a single sentence that is worth more than any scorecard: "There is no one-click migration from the built-in backend (Cloud) to your own Supabase project." The documented path is to "export your Cloud data, connect a Supabase project to a new Lovable project, and rebuild the schema there" (Lovable Cloud docs, 2026). Read the middle clause again. The migration is not performed in place; it starts a new project.

Meanwhile, migration in is a polished, first-class, well-documented feature nearly everywhere. Base44's inbound page brings over data, schema, keys and frontend source from Lovable, Bolt, Shopify, WordPress, Salesforce and HubSpot, and previews 100 items per entity before you commit. That contrast is not a scandal, it is just how product incentives work, and it is the most reliable tell in the category: the direction a vendor has invested in documenting is the direction it wants you to travel.

An honest note: most of this is security, not malice

It would be easy to read the identity layer as vendors hoarding your users. Mostly it is not, and the piece deserves saying plainly.

Passwords are stored as one-way salted hashes precisely so that nobody, including the vendor, can recover them. Bubble and Lovable are both describing correct practice, not a retention strategy. A vendor that cheerfully emailed you a spreadsheet of reversible user passwords would be a vendor with a much worse problem. The non-portability of credentials is a side effect of doing security properly.

What is fair to hold vendors to is narrower and more useful: whether they document the boundary clearly, and whether they build a path across it. On that test the picture is genuinely mixed and worth crediting. Lovable states the limitation in the same paragraph as the export, which is more candour than most. Replit built an actual migration pipeline for the hardest layer, which is more engineering than most. Bubble explains the mechanism rather than hiding behind it. Those are the behaviours to reward, and they are more informative than any single lock-in grade.

Verdict, August 2026

v0 by Vercel has the least lock-in in this comparison, and it achieves that by not owning any of your layers: standard Next.js, a database in your own provider account, no auth product of its own. You pay for that in setup work and operational responsibility. It is the right answer if leaving is a real scenario, and an unnecessary tax if it is not.

Bolt.new and Lovable are the two where the day-one decision dominates everything after it. Both can put your data in a Supabase project you own, and on both, retrofitting is meaningfully harder than choosing it at the start. If you think you will ever leave, connect your own Supabase project during project creation, and on Bolt confirm you hold the org-owner role and are on a Vite project before you rely on the claim path existing.

Replit is the most interesting split in the group. Its data layer is genuinely strong, real PostgreSQL with a real external door. Its runtime layer needs work to rehost, and its identity layer is the most vendor-entangled of the six by default, with your end users holding Replit accounts. It is also the only builder here that has built and documented a migration for the hardest layer. If you use Replit for something you expect to outgrow it, take the Clerk path early rather than at migration time.

Base44 has improved most on the layer people check, and its remaining lock-in sits on the two they do not. Code now leaves cleanly. The code that leaves is still a client of a base44.app backend, and the sync that gets it out is paywalled, permanent and costs you your version history. That can be a perfectly sound trade. It is not a trade you want to discover mid-migration.

Bubble is the most honest of the managed platforms because it never implies otherwise. You are buying a hosted application platform, your data comes out as files, your code does not come out, and your users stay. For a large number of internal tools and businesses that is entirely fine, for a decade or more. Just price it as renting the running application, because that is the product.

Across all six, the pattern that held up in the documentation is the weakest-layer rule. Not one of these builders is weak on all five layers, and not one is strong on all five. The useful question is never "is this tool locky." It is "which of my five layers is the worst, and what is the invoice for that one."

How to cut your lock-in before you need to

Every one of these levers is cheaper before the project matters:

• Do the exit once, early, while the app is small. A migration rehearsal at 20 rows and 3 users finds the same blockers as one at 200,000 rows, at roughly none of the cost. This is the single highest-value hour in the list.
• Test the runtime question, not the code question. Clone the repo, blank every vendor-issued environment variable, and try to serve one request. Whatever breaks is your real dependency.
• Choose your own database and auth provider at project creation. On the builders that offer it, this converts the two heaviest layers from vendor-granted to inherited, and it costs minutes on day one against days later.
• Check the exit's preconditions now, not later. Which plan tier, which role, in whose account, and is it reversible. All four are documented, and all four can change while you are not looking.
• Ask about credentials specifically, and get the answer in writing. Not "can I export my users," which almost always gets a yes. Ask: do I receive password hashes, in what algorithm, and does anything else break for a logged-in user on the other side.

Where this fits

This is the umbrella question. Two of its five layers are scored in their own right: whether the application source is yours to export and deploy, in our AI app builder code ownership comparison, and whether your data leaves with its schema intact, in our AI app builder database portability comparison. Both are worth reading before you commit a project, and the divergence between them is the whole reason the weakest-layer rule exists.