Skip to content
← Back to the blog
productsoftware development

Base44 limitations: when should you move to your own code?

Where Base44 fits and where it pinches: backend, data access, backups, credits and code control. The signs it's time to move, and options short of a rebuild.

By Devonauts Team5 min read
Leer en español →
A weathered wooden sign with a painted yellow arrow pointing right, with hills and bushes behind it

Base44 is a good place to build and run an app while it's mostly screens, forms and straightforward data. It starts to pinch when your business depends on things it controls for you: the backend and database run on Base44's platform, the code you export still talks to that backend, automatic backups only come with the higher plans, and usage is metered in credits. It's time to plan a move when one of those starts costing you customers, money or sleep, not simply because the app has grown.

This guide explains how a Base44 app is put together, the limits that matter most in practice, the signs that you've outgrown it, and the options between "stay" and "rebuild everything".

How is a Base44 app built?

Knowing the parts makes the limits easier to judge. According to Base44's documentation:

  • The front end is a standard React app built with Vite. You can see the code in the Code tab, and on paid plans edit it in the app.
  • The data lives in Base44 tables (called entities), each defined by a JSON schema.
  • Backend logic runs as backend functions, written in TypeScript and run on Deno, plus automations triggered on a schedule or by events.
  • Login, email, file uploads and AI calls come from Base44's built-in services.
  • The connection between them is the @base44/sdk package, which the front end uses to talk to Base44's servers.

That last point is the key to most of what follows. Your front-end code is portable; the services behind it are Base44's.

Which Base44 limits matter most in practice?

You work with the data through Base44, not a database you own

You see and edit your tables on the Data page, export each one as CSV, and reach data from code through the SDK and APIs. That's enough for many apps. It gets harder when you need complex reporting across tables, a BI tool connected directly to your data, or bulk operations that are simpler in SQL.

Backups depend on your plan

Deleted records stay recoverable for 30 days. Automatic point-in-time backups, with download and restore, are available on Elite (7 days of history) and on the Business and Enterprise plans (30 days). On other plans, regular CSV exports are your backup, and you have to remember to make them. Note too that app users are kept separately from your tables and aren't part of those backups.

Usage is metered in credits

Each plan includes monthly message credits (for building with the AI) and integration credits. Base44's docs say backend operations draw on integration credits. That's predictable for steady use, but a feature that suddenly gets popular, or an automation that runs more often than you meant, uses up credits faster.

Code control comes with conditions

Two-way GitHub sync is available from the Builder plan up, and the repository's default branch must be called main. Once connected, Base44 syncs changes automatically, and you can't use Version History to go back to versions from before the connection. With two-way sync, entities are managed in Base44 and aren't stored in your repository.

The exported code still needs Base44

Because the front end uses the Base44 SDK, exporting the code doesn't give you an independent app. Base44's own CLI has an eject command that creates a separate copy of the app, but its docs say the copy starts with an empty database: entity schemas come across, the data does not.

What are the signs it's time to move?

Count how many of these are true for you:

  1. Customers or investors ask where data is stored, how it's backed up and who can access it, and the answers depend on a plan you don't have, or on features you can't configure.
  2. You've lost data, or nearly did, and the recovery depended on luck or on a manual export.
  3. Credit spending is hard to predict, and a busy month means an unplanned upgrade.
  4. Features you need keep running into the platform, such as complex permissions, heavy reporting, specific integrations or a particular database feature, and each one takes many prompts and workarounds.
  5. A developer has joined, and needs branches, code review, automated tests and a staging environment with its own data as part of daily work.
  6. The app is the business, and depending on one vendor's backend is a risk you'd now rather manage yourself.

One or two of these usually means "adjust how you use Base44". Four or more usually means it's time to plan the move.

Do I have to rebuild everything?

No. There are steps between staying and starting over:

OptionWhat it meansGood when
Stay and hardenTurn on GitHub sync, schedule CSV exports, review data permissionsThe app works and the risks are about safety nets
Upgrade the planMove to a plan with backups or the controls you needThe limits are plan features, not platform limits
Move the front end firstKeep the React code, replace Base44 SDK calls with your own API over timeThe UI is good and the backend is the problem
Full migrationNew backend and database, data imported, users movedSeveral signs above apply at once

The React front end is often worth keeping, since it's standard code. What gets rebuilt is the layer the SDK provides: the database, login, file storage, email and functions. A careful migration also keeps record IDs so links between tables survive, and plans how users will sign in on the new system.

Before deciding, take an inventory of your entities, functions, automations and integrations, and export your data (our guide on getting your data and code out of Base44 walks through it). Then compare the effort honestly. Our guide on whether to rewrite or fix an AI-built app helps with that call, and technical debt in vibe coding explains what tends to break as an app grows.

Quick answers

Can a Base44 app scale? For many apps, yes. The limits people hit are less about traffic and more about data access, backups, credit costs and code control.

Can I export my Base44 app and host it myself? You can get the code through GitHub sync or the eject command, but the exported front end uses the Base44 SDK, and ejecting copies schemas, not data. Running it fully on your own means replacing the backend.

Does Base44 back up my data? Automatic backups come with Elite, Business and Enterprise plans. Deleted records are recoverable for 30 days on any plan. Otherwise, export tables as CSV regularly.

Is it cheaper to stay on Base44? Often, while the app is small. Compare your credit spend and plan cost with hosting, database and developer time for your own stack.

Not sure whether to stay or go?

That decision is easier with someone who has read the app's code and data model. Our Base44 app service can review where you stand and what a move would involve, and our custom software development team can carry out a migration if that's the answer. Start with the free health check or tell us about your app.

Still stuck with your app?

Run the free health check on your app's URL, or get the $299 App Rescue Audit: a senior engineer reviews the code and sends you a written report in 2 business days.