Base44toProduction:WhatYouOwnandWhatYouCannotTake

Introduction

You pressed export and got a repository. Every screen you built is in there. The components look like components. Then you open the environment file and find two variables you did not write, and both of them point back at Base44.

That is the moment this article is for. You have the source code. You do not have the system it runs on. Those are two different things, and the entire question of whether your app is safe, portable and yours lives in the gap between them.

Nobody explains that gap well. Search for how to export your Base44 code and you'll find a dozen guides that tell you which button to press and which plan you need, all of them accurate and all of them stopping exactly where your real question starts. Search a bit harder and you'll find the opposite error, a confident claim that the export gives you nothing but the React frontend. That one isn't true either, and we checked.

This guide is built from Base44's own documentation, read on 25 August 2026, plus the public security research on the platform. It covers what Base44 generates, what the export contains down to the directory, what happens to your app the day you stop paying, what the 2025 Wiz disclosure actually means for you, and the four-stage sequence for moving off the platform if you decide you should. For the wider view across every AI builder, read our vibe coding to production pillar guide.

> The useful question isn't whether you own your Base44 code. You do. It's whether your app survives without Base44, and the honest answer today is that it doesn't, because the code you own is addressed to servers you don't.

What Does Base44 Actually Generate?

Base44 generates a complete application, frontend and backend, from a description in plain English. Per its official developer documentation the frontend is React with React Router, built by Vite, styled with Tailwind CSS on the shadcn/ui component library. The backend side is a managed NoSQL database, built-in user authentication, serverless backend functions on the Deno runtime, and realtime updates over WebSocket.

That stack is worth reading twice, because the two halves have completely different characters. The frontend half is boringly conventional. React, React Router, Vite, Tailwind, shadcn/ui. If you handed that to any React developer they'd recognise it instantly and could work on it the same afternoon. There's nothing proprietary about it.

The backend half is where Base44 is actually Base44. You don't get a database you administer, you get a managed one. You don't get an auth service you configure at the protocol level, you get one that works. And your code reaches all of it through a single package, the Base44 SDK, which the documentation describes as the interface to all Base44 backend services.

One deliberate gap in this article. We're not going to tell you which database engine sits underneath, because Base44 doesn't say. Third-party write-ups contradict each other, one claiming Postgres and another claiming MongoDB. The official documentation says managed NoSQL and that's where our claim stops. If someone tells you confidently which engine it is, ask them where they read it.

Everything that follows in this article comes back to that split. The conventional half travels. The managed half does not.

What Does the Base44 Export Actually Give You?

An exported Base44 project is a standard React and Vite application, and it contains more than most people expect. Base44's project structure documentation describes src/ holding your pages, components, hooks and utilities, with the SDK client configuration in src/api/ and Base44 integration code in src/lib/. Alongside it sits a functions/ directory containing your backend functions in TypeScript, and an entities/ directory containing JSON schema files that describe your data model.

So the claim you'll read on some competing pages, that the export is frontend-only, is wrong. Your backend function source is in there. Your schema definitions are in there. That's genuinely valuable and it makes a future move much cheaper than it would otherwise be.

There's a caveat that matters and it's easy to miss. Base44's documentation notes that when you use the two-way GitHub integration, entities are managed in Base44 and are not included in your local repository. So the ZIP path and the GitHub path don't hand you the same thing. If your schemas matter to you, and they should, check which of the two you're actually using before you assume you have them.

Here's the part nobody frames correctly. What the export gives you is source code. What it cannot give you is the running system: the database instance and every record in it, the authentication service holding your users' sessions, the file storage holding their uploads, the Deno runtime executing those functions, and the WebSocket layer pushing realtime updates. None of that is code. It's infrastructure Base44 operates, and no export button can hand over infrastructure.

The proof is sitting in Base44's own setup instructions rather than in anyone's opinion. A cloned Base44 project is configured with VITE_BASE44_APP_ID and VITE_BASE44_APP_BASE_URL, and @base44/sdk is a dependency in package.json. Read those two variables literally. They say: this code knows which app it is, and it knows which server to ask. Every login, every read, every write and every upload goes through that door.

One more thing worth knowing before you press the button. Base44's GitHub integration documentation states that the sync is permanent, that you can't disconnect it or transfer the project back to Base44, and that once connected you can no longer use Version History to revert to any version from before the integration. It also requires the Builder plan or higher. That's a one-way door. It's a perfectly reasonable door to walk through, and we'd still rather you knew it was one.

Does Base44 Own the Code You Write?

No. Base44 doesn't claim ownership of your application code, and when you connect the GitHub integration your code is pushed to a repository under your own account. If that's the question keeping you up, you can stop worrying about it tonight.

It's also the wrong question, and the reason it keeps getting asked is that ownership is the word people reach for when what they actually feel is dependency. Those aren't the same thing. You can own every line of a codebase and still be unable to run it, and that's precisely the position a Base44 export puts you in.

Think about what ownership is supposed to buy you. The ability to take the thing elsewhere. The ability to keep operating if the vendor changes direction, raises prices, gets acquired again, or simply goes away. The ability to hand a customer's auditor a straight answer about where their data lives. Owning the source code delivers none of those on its own, because the source code is the half that was never the constraint.

So the sharper question, and the one worth asking about any platform in this category, is this: if my vendor relationship ended tomorrow, what would I have to build before my app worked again? For a Base44 app the answer is a database, an authentication system, file storage, and somewhere to run your functions. That's a real project. It is also a completely knowable one, which is better than most vendor lock-in situations, and it's the reason we tell people to export early even when they have no intention of leaving.

There's a version of this article that turns that into alarm. This isn't it. Dependency is a trade, not a trap. You traded infrastructure control for speed and you got the speed, genuinely. The mistake isn't making that trade, it's making it without knowing you made it, and then discovering the terms in the middle of a security review.

What Happens to Your App If You Stop Paying?

It stops working, and the repository in your GitHub account does nothing to prevent that. The code still builds. The dev server still starts. The screens still render. And then the first thing that tries to load data fails, because the SDK call it depends on resolves to a Base44 service that no longer answers for your account.

This is the single most important operational fact about building on the platform, and it's the one most likely to be discovered at the worst possible time. A lapsed card, a billing email to someone who left, a plan change during a company reorganisation. The failure mode isn't degraded service, it's an app that renders its own shell around no data at all.

The stakes scale with what the app has quietly become. Internal tools have a way of turning load-bearing without anyone deciding they should. The spreadsheet replacement that three people used became the thing operations runs on. The customer portal built to demo an idea has real customers in it now, with real records that exist in exactly one place. That's the situation where a billing lapse stops being an inconvenience.

Two things are worth doing today regardless of whether you ever leave. Export the code, so you have an artifact rather than an intention, and check which export path you used so you know whether your entity schemas came with it. Then get a copy of your actual data out and keep it somewhere you control, on a schedule rather than as a one-off. Your records are the part that cannot be regenerated from a prompt.

How Secure Is a Base44 App?

Base44 handles authentication for you, and that removes an entire category of mistakes. Most security problems we find in hand-built applications are self-inflicted auth bugs: sessions that never expire, password resets that leak, an admin check that runs in the browser. A managed auth layer written once by people who do it professionally is better than what most teams build under deadline. That's a real advantage and it should be said first.

It also concentrates risk in a way worth understanding. In July 2025, roughly a month after the Wix acquisition, Wiz Research disclosed a critical authentication bypass in Base44. Two undocumented endpoints, one for registration and one for verification, required no authentication at all. An app_id was enough to use them, and that value isn't secret. It appears in app URLs and manifest files. With it, someone could create a verified account on a private application and walk straight past single sign-on.

Wix patched it within 24 hours, reported no evidence of exploitation, and hardened the flow with app ID validation and mandatory SSO enforcement on registration. By vendor response standards that's fast and it's the outcome you want. The disclosure isn't an argument that Base44 is careless.

The durable lesson is about position, not about this specific bug. When the platform is your entire authentication layer, a platform-level auth flaw is one you can't patch, can't detect from inside your own application, and can't disclose to your customers on your own timeline. You find out when the vendor tells you, or when a researcher publishes. For an internal tool that's an acceptable position. For an app holding other people's health records, financial data or identity documents, it's the thing your customer's security questionnaire is actually trying to find out.

That is the line to reason from. Not "is Base44 secure", which invites a yes or no answer that is not useful, but "what class of failure am I unable to respond to myself, and can I live with that given what this app holds". For a deeper look at the security patterns that break in AI-generated applications generally, read our guide on vibe coding security and our notes on running an AI code audit.

When Does a Base44 App Hit a Wall?

At the point where you need a control the platform doesn't expose, which is usually earlier and less dramatic than people expect. It's rarely a crash. It's a slow accumulation of things you can't do anything about.

You'll see numbers circulating for this. Apps going sluggish past twenty users, instability at a hundred concurrent, slowdowns past ten thousand records. We're not repeating those as fact, because every one of them traces back to unnamed anecdotes on sites that sell migration services, and we couldn't verify a single one. Borrowed precision is worse than no number at all.

The mechanism is more useful than a threshold anyway. Here's what it actually feels like. A page that used to load instantly now takes four seconds, and you diagnose it correctly as a query that needs an index, and then you discover there's no index to add because you don't administer the database. That's the wall. Not capacity. Control.

The same shape shows up in three other places. A rate limit or bulk fetch cap you can't raise, which turns a routine data import into a scheduling problem. A compliance clause about where data physically lives, which you can't satisfy because you don't choose the region. And an integration that needs to run somewhere the managed function runtime won't take it, so a piece of your system has to live elsewhere and now you're operating two things.

Notice that none of these are fixed by better prompting, and none of them announce themselves in advance. That's why the useful trigger to watch for isn't a user count. It's the first time you know exactly what the fix is and can't apply it. When that happens twice in a quarter, the platform has become the constraint.

Who Should Stay on Base44?

Most people reading this, and we'd rather say so plainly than have you spend money finding out. There are four conditions. If all four describe you, moving off Base44 buys you nothing and costs you weeks.

Your app is an internal tool behind a company login. The users are colleagues. If something breaks you walk over and tell them. The blast radius of any failure is your own organisation, which is a completely different risk profile from a public product.

You're still finding out whether anyone wants it. This is the big one. If the app exists to answer a question about demand, then portability is a solved problem for a problem you don't have yet. Every hour spent on infrastructure is an hour not spent on the question. Build the next feature. Come back to this when the answer is yes.

You hold no personal data belonging to other people and take no payments. No health records, no identity documents, no card details, no data about anyone outside your company. The reason the compliance conversation matters is other people's exposure, and if there isn't any, most of this article is theoretical for you.

No customer has ever sent you a security questionnaire. When one arrives, that's the signal, and it'll be unambiguous.

If that's you, close this tab and go build something. Revisit when one of those four facts changes, not on a calendar and not because an article made you anxious. And if someone quotes you for a migration without asking which of those four apply, you've learned something useful about them.

How Do You Move a Base44 App Off Base44?

In four stages, in this order. The order matters more than the tooling, because getting it wrong means doing the hardest part twice.

Stage one: export it and get it building locally. Not as a formality. Clone the repository, install the dependencies, and run it until it starts. You'll learn immediately whether your entity schemas came across, which depends on whether you used the ZIP or the two-way GitHub sync. You now have an artifact rather than an intention, and everything after this is normal engineering.

Stage two: turn the entity schemas into a real database schema. The entities/ directory holds JSON descriptions of your data model, which is a genuine head start. It's also a description written by a system that never had to enforce anything. Real tables need foreign keys, unique constraints, not-null rules and indexes, and this stage is where you add the integrity the platform never asked you for. It's frequently where teams discover their data has been quietly inconsistent for months.

Stage three: put one module between your app and its data. Right now your components call the Base44 SDK directly, all over the codebase. Before you change anything about the backend, route every one of those calls through a single data-access module. It's mechanical work and it feels like no progress. It's the difference between swapping the backend in one file and swapping it in ninety, and it means you can move one entity at a time with the app working throughout.

Stage four: move authentication last. Authentication is the piece with live user sessions attached to it, and it's the one where a careless cutover locks real people out of a working system. Do it when the data layer is already stable and you can roll back to something known good. Plan the session migration explicitly rather than hoping everyone logs in again.

Backend functions come along the way. They're TypeScript, and the business logic inside them usually survives with the data calls swapped out. If your destination is Postgres with a managed layer on top, our guide on scaling Supabase in production covers the decisions that come next, and Lovable Cloud versus Supabase works through the same managed-versus-owned trade in a different context.

Should You Rebuild It or Port It?

Port it. And be suspicious of anyone who says rebuild before they've read your export, because a rebuild bills more and takes longer, and that fact does not go unnoticed by the people quoting for it.

Here's the honest breakdown of what survives. The React frontend ports, because it's ordinary React with React Router and Tailwind and there's nothing proprietary in it. The entity schemas translate, because JSON describing a data model is a starting point for real tables even if it needs tightening. The backend functions mostly survive, because they're TypeScript and their logic doesn't care where the data came from once you've swapped the calls.

What genuinely has to be rebuilt is the part that was never yours: authentication, the data layer, file storage, and wherever the functions are going to run. That's a real piece of work and we're not pretending otherwise. It's also a bounded, well-understood piece of work rather than an open-ended one, and it's a much smaller number than the word rebuild implies.

The one situation where a genuine rewrite is the right call is when the application itself was never right. If the data model has grown wrong in a way no migration fixes, if the thing was a prototype that accumulated features nobody designed, if you'd be carrying three years of decisions that were only ever meant to last a fortnight. That has nothing to do with Base44 and everything to do with the app. It happens, and it's worth naming when it does.

The way to tell the difference is to read the export before deciding anything. Geminate Solutions has shipped 50+ products and we've inherited a lot of codebases that arrived with a rebuild already recommended by someone else. Most of them didn't need one. That's not a sales position, it's just what reading the code tends to reveal.

Base44 and Lovable Take Different Exits

These two get compared constantly, and for the question this article is about, the comparison has a clean answer. The difference isn't quality of output. It's where the data lives.

Lovable generates an application that talks to a Supabase project. Supabase is Postgres, and you can hold the credentials to it directly. So the hardest part of leaving Lovable is already outside the builder before you start, and the exit is closer to a handover than a migration. Base44 provides its own managed NoSQL database, authentication, storage and Deno function runtime behind the Base44 SDK, so the equivalent journey means standing up replacements for each one.

Neither trade is the wrong one. Base44's integration is genuinely tighter and that tightness is why it gets you further faster, which is the whole point of using it. Lovable's looser coupling costs a little more setup and leaves more doors open. What matters is knowing which trade you made, ideally before the quarter in which it becomes relevant.

If you're weighing this up across the whole category, our guides on taking a Lovable app to production, what Lovable actually generates, Bolt.new to production, Replit to production and v0 to production each work through the same question for a different tool.

What Changed When Wix Acquired Base44?

Wix acquired Base44 in June 2025 for an initial consideration of about USD 80 million, with earn-out payments running through 2029. Base44 had been founded by Maor Shlomo, employed roughly six people at the time, and had raised no external funding at all. As Wix described it, the deal was an expansion into intent-based software development.

For most people building on it, the day to day didn't change much. The platform gained the engineering depth, security resources and operational maturity of a public company, which is a real upgrade from six people, and the Wiz disclosure a month later is a decent illustration of that working: found, reported, patched inside a day.

What did change is the governance question sitting behind your app. Your data layer is now operated by a company with public shareholders, a broader product portfolio and its own strategic priorities. That's not a criticism. It's arguably more stable than a six-person startup. But it is a different kind of dependency, with roadmap decisions made in a context that has nothing to do with your application.

The practical read is simple. Acquisitions change the shape of platform risk rather than removing it. A larger owner is less likely to disappear and more likely to reposition, reprice or fold a product into a wider suite. Neither of those is a reason to leave. Both are reasons to know what leaving would take, which is the thing this whole article is about.

Where Does This Leave You?

With a decision that's smaller than it felt at the top of this page. You own your code. You depend on a platform for the system that runs it. Both of those were true before you read anything here, and now you know which is which.

If you're in the group described further up, internal users, no outside personal data, no payments, no questionnaires, the correct action is none. Export a copy so you have one, pull your data down on a schedule, and get back to work. That's it.

If you're not in that group, the useful next move isn't a migration, it's an assessment. Read the export, find out whether your entity schemas came with it, and get a written answer on what would actually have to be rebuilt. That answer is usually smaller than the word rebuild suggests, and knowing it turns a vague anxiety into a line item you can schedule.