Lovable vs Base44: What Each Platform Actually Lets You Take With You

The table below compares the two on the things that determine whether you can actually leave: source code, backend, data and users. | | Lovable | Base44 | |---|---|---| | Source code out | GitHub or GitLab two-way sync on all plans, or ZIP download on paid plans | ZIP download or GitHub sync, Builder tier and above (US$40 a month, about A$61) | | What you get | Standard Vite and React project, build with `npm run build`, output to `dist/` | React and Vite frontend plus custom backend function source | | Schemas included | Yes, as SQL migrations covering tables, columns, indexes, row-level security policies, functions and triggers | No. Entity schemas are excluded from the GitHub repository | | Backend | Supabase-compatible: Postgres, Supabase Auth, Storage, Realtime, Edge Functions | MongoDB-compatible database, Deno functions, auth, storage and agents, all hosted by Base44 | | Can you self-host the backend | Yes, on your own Supabase project, managed or self-hosted | No. The exported frontend calls Base44 through the SDK | | Data export | CSV per table, or a full database export capped at 5 GB, one per 24 hours | CSV per table only, maximum 5,000 items per request since 27 November 2025 | | User passwords | Cannot be exported | Cannot be exported | | Vendor's stated position | "You are never locked in" | Not verifiable, terms of service not retrieved | The row that decides it is the backend. Lovable's backend is Supabase, which is a product you can run yourself. Base44's backend is Base44. That is not a difference of degree.

Lovable's documentation states: "Lovable is intentionally built so that you are never locked in. You can export your code, migrate your data, self-host parts or all of your stack, or move to another provider at any time. We want you to stay with Lovable by choice, never by necessity." That is unusually direct for a platform vendor, and the technical detail behind it holds up. The same docs say "You own your code. All Lovable projects can be continuously synced to GitHub or GitLab at any time... You can clone your repository, modify it outside Lovable, deploy it on your own infrastructure, or fully self-host without restriction." On data: "You own your data. Your database, storage, and configuration are portable... Lovable does not rely on proprietary data stores." The generated stack matches the claim. Lovable's deployment documentation describes its output as "standard Vite + React projects built on open-source technologies", building with `npm run build` into a `dist/` directory on Node 22, with client-side routing via React Router. Repositories it creates are private by default on every plan. Sync runs in both directions, one branch at a time. We are quoting the vendor at length here on purpose. When a company writes down a commitment this specific, it is checkable, and the check passes: a Lovable export runs on your own infrastructure against your own Supabase project. That is a materially better starting position than most of this category offers, and it deserves credit.

Every data read, every login and every backend call in a Base44 app goes through the Base44 SDK to Base44's servers. Export the code and that stays true, which is why the exported frontend still needs a `VITE_BASE44_APP_BASE_URL` environment variable pointing back at Base44. Base44's quickstart shows the shape of it: create a client with your app ID, then call `base44.entities.Products.list()` for data and `base44.auth.loginViaEmailPassword()` for sign-in. Those are network calls to a runtime you do not host and cannot replicate from the files you downloaded. The documented stack behind them is a MongoDB-compatible database ("allowing you to use all MongoDB operators when querying through the SDK"), Deno-based serverless functions, and built-in authentication covering registration, login and session management. Hosting supports "Single Page Applications (SPAs) only", so there is no server-side rendering, which is a standing problem for anything that needs to rank in search. The CLI adds a trap. The `base44 eject` command sounds like an exit. Per the documentation it gives you the frontend, entity schemas, backend functions and config, and then creates a new backend on Base44 with a new app ID and an empty database. It moves you sideways, not out. A poster in a Black Tech Entrepreneurs group put the situation more plainly than any documentation does: "I did a prototype on base 44. I really like my prototype. But the moment I take it off base 44 platform I have no backend."

Lovable's documentation says it directly: "you cannot export user passwords, so you need to trigger a password reset flow. We recommend you plan the migration before onboarding real users." Base44 has the same problem, because user accounts export as CSV rows while the private authentication record behind each one does not. That second sentence from Lovable is the single most useful fact in this comparison, and it is the vendor's own advice. Read it as what it is: the platform is telling you that the cheap window for leaving closes at your first real user. The reason is not a policy choice. Password hashes are deliberately non-portable in most auth systems, and a platform that handed them over would be doing something questionable. So the cost is structural, and it lands on your customers rather than on your engineering time. Every active user has to receive an email, open it, and choose a new password before they can get back in. On a product people use daily, most will. On something used monthly, a meaningful share simply will not come back. This reframes the whole ownership question. The decision that matters is not which platform you pick. It is when you move, because the price steps up sharply the moment there are real accounts, real uploaded files with live URLs, and real automations carrying state. Same app, much bigger job. That is worth deciding on deliberately rather than discovering it, and it applies whichever of the two you are on.

Lovable's portability is real but bounded, and the boundary is Supabase. Their documentation states that while the underlying database is Postgres, "Migration to plain PostgreSQL or other database providers would require implementing equivalent authentication, storage, and edge services and is not supported out of the box." So Lovable to Supabase, managed or self-hosted, is a documented path. Lovable to your own Postgres with your own auth is a rebuild of the auth, storage, realtime and edge function layers. That is still far better than having no path at all, but it is not the same as being backend-agnostic, and it is worth knowing before you promise a client you can put their app on any database they like. The operational limits matter too. Database exports are capped at 5 GB with one export permitted per 24 hours, so a large database plus a mistake costs you a day. Authentication providers, environment variables and secrets, table data, and storage files are all listed as manual steps in Lovable's own migration table. And `VITE_`-prefixed environment variables are embedded at build time rather than read at runtime, which surprises people expecting to change configuration without rebuilding. There is one genuine data-loss trap, documented by Lovable: "Download your export and your storage files before removing Cloud from the project; exports saved to Cloud storage are no longer accessible afterwards." If you park your export in Cloud storage and then remove Cloud, the export goes with it. Do the download to a machine you control first, verify it opens, then touch the project settings. Lovable also notes that the editor and AI agent themselves are a managed service and "cannot be self-hosted or deployed inside a customer VPC". You can take the app. You cannot take the tool that built it.

If portability is a factor in your choice, Lovable is the better starting point of the two, and the gap is architectural rather than a matter of policy. If you are already on Base44 and the app matters, plan the move before you have a user base to migrate. That said, do not treat portability as the only axis. Base44 is fast, and for a prototype, an internal tool or anything with no search requirement and no long horizon, the lock-in may never cost you anything. Plenty of software should be disposable. The mistake is building something you intend to run for five years on a runtime you cannot host, and only working that out in year two. For anything you do intend to keep, the useful test is simple and it has nothing to do with marketing copy: could you run this application next Monday if the vendor disappeared on Friday? On Lovable, with your GitHub sync live and your Supabase project under your own account, the answer can genuinely be yes. On Base44, as the architecture stands, it is no. Security is the other thing worth checking before you move anything. Escape scanned 5,600 publicly available vibe-coded applications on 29 October 2025 and reported 2,038 highly critical vulnerabilities, more than 400 exposed secrets and 175 distinct instances of exposed personally identifiable information including bank account data. Their sample included roughly 4,000 Lovable apps and around 159 Base44 apps. Escape noted their scanning was passive, so the findings "reflect only a subset of exploitable issues". Migrating an insecure app onto new infrastructure just moves the exposure. If you want the platform-specific mechanics rather than the comparison, the Base44 migration guide and the Lovable migration guide cover the sequencing in detail.

Do you actually own your code on Lovable? Yes, in the meaningful sense. Lovable's documentation states "you are never locked in" and "You own your code", and the output is a standard Vite and React project you can clone, modify outside Lovable, deploy on your own infrastructure or fully self-host. GitHub or GitLab two-way sync is available on all plans, with repositories private by default, and paid plans can also download a ZIP. Do you own your code on Base44? You hold the frontend source and your custom backend function source. What you cannot take is the runtime those files depend on, because the database, authentication, storage, automations and agents all run on Base44 and are reached through the SDK. The exported app still needs `VITE_BASE44_APP_BASE_URL` pointing at Base44. We could not retrieve Base44's terms of service, so this is an architectural assessment, not a legal one. Can I move a Lovable app to plain Postgres? Not without extra work. Lovable's documentation says migration to plain Postgres or other database providers "would require implementing equivalent authentication, storage, and edge services and is not supported out of the box". Moving to your own Supabase project, managed or self-hosted, is the supported path. Anything else means rebuilding the auth, storage, realtime and edge function layers yourself. Will my users have to reset their passwords when I migrate? On both platforms, yes. Lovable's own documentation says "you cannot export user passwords, so you need to trigger a password reset flow", and adds "We recommend you plan the migration before onboarding real users." Base44 exports user rows as CSV but not the private authentication record behind them. Budget for the reset email and expect some users not to return. Is there a limit on how much data I can export? On Lovable, database exports are capped at 5 GB and limited to one per 24 hours. On Base44, the CSV export runs one table at a time and the API has returned a maximum of 5,000 items per request since 27 November 2025, so larger tables need a paginated script. Base44 also retains deleted records for only 30 days before permanent deletion. What is the biggest mistake people make when leaving either platform? Saving the export somewhere that disappears. Lovable's documentation warns to "Download your export and your storage files before removing Cloud from the project; exports saved to Cloud storage are no longer accessible afterwards." The second biggest is treating the export as the migration. Copying files feels like progress, but nothing is testable until authentication works on the new stack.