Base44 apps, reviewed, hardened and moved off the builder when it is time
Review of a Base44 app's access rules, data and integrations, fixes for what the builder leaves open, and a migration to a backend you own when the app has outgrown the platform.
Base44 is an AI app builder that ships the whole stack at once: you describe the app, and it generates the screens, the database, the sign-in and the hosting together. That is why a Base44 prototype can be in front of a team the same afternoon, and why people stop thinking of it as software with a backend at all.
The backend is the part to understand before real data goes in. The database, the authentication and the platform's integrations live inside Base44. Reports and the vendor's own plan descriptions indicate that code export, where available on your plan, covers the front end, while the data and the server-side logic stay on the platform. Check what your current plan actually exports, because it changes. A working app and an app you could move are two different things.
We have not published a client engagement on Base44, and we hold no partnership with it. What we bring is the review and hardening method from our vibe coding to production service, applied to this tool's shape: access rules first, then data, then the dependency on the platform's backend. If the honest answer is that the app should stay on Base44, we will say so.
What we build on Base44
A written review of who can read and change what
Each entity gets the same three questions: who can list it, who can read one record, and who can change or delete one. We test them signed in as an ordinary user, as a user from a different company, and signed out, because a screen that hides a button is not an access rule. What comes back is a ranked list, with the ones that expose other people's data at the top.
Roles and ownership that the data actually enforces
Moving the rule from the screen to the data, so a record belongs to a user or an organisation and a request for someone else's returns nothing. Admin rights get one explicit, audited route instead of being a flag a user can edit on their own profile.
A map of what the app depends on the platform for
Database, sign-in, file storage, scheduled jobs, email and model calls, each marked as portable, replaceable or tied to Base44. That map is the real answer to whether you are locked in, and it is also the scope of a migration if you want one.
Migration to a backend you own
Where the app has earned its place, the data model is rebuilt on your own database and your own sign-in, the screens are carried over, and the new version runs in your accounts, with tests on the parts that touch money or permissions. We write the migration so the old app keeps running until the new one has been checked against it.
What goes wrong on Base44
The patterns that turn up on this platform specifically, and what we do about each one.
- 01
The data cannot leave when the front end can
A repository on GitHub feels like ownership, but if the database and the server-side logic stay on the platform, the repository on its own does not run anywhere else. We find this out in the audit rather than during an outage or a dispute over the price, and we scope what moving it would take so the decision is made with the cost in front of you.
- 02
Credits spent by usage you did not plan for
Separate allowances cover building the app and running it, and a live app that sends email, calls a model or generates files draws on the second one as real users arrive. The fix is to know which features spend credits, cap the ones that can run away, and move the expensive calls to something priced by use before launch, not after the first month's surprise.
- 03
Permissions written as prompts
Asking the builder to make sure users only see their own records can produce a screen filter and no rule at all. We read the rule where it is enforced, and where it is not, add it where the data lives. If the honest answer to "where is this enforced?" is "somewhere in the screens", the permission layer needs rewriting, not patching.
- 04
Integrations holding keys the whole app can read
Payment, email and model keys end up wherever the generated code put them. We move them into server-side secrets, rotate any that were ever visible, and put spend limits at the provider, because a key that can be read can be used.
Where Base44 is the wrong answer
Leave it on Base44 if the app is an internal tool for a handful of colleagues, the data is not sensitive, nobody outside the company signs in, and the cost of an hour of downtime is a mild inconvenience. A migration is real money and real risk, and a small tool that works and is cheap to run is not improved by being rebuilt. The case for moving gets strong when outside customers sign in, the data is personal or financial, you need integrations the platform handles awkwardly, or you want to be able to hire anyone to change it. If you are not sure which side you are on, the review is the cheap way to find out.
Projects that did not use Base44
Here for the argument rather than as evidence of Base44 work. Each one bears on a decision above, and the note says which.
Related reading
Base44, specifically
Usually yes, but it is a rebuild of the backend rather than a file copy. The front end can be carried across; the database, sign-in and server-side logic have to be recreated on infrastructure you own, and the data moved with them. We start with a written review that says what moves cheaply and what does not, so you can decide before any of it is spent.
Not on the strength of it working. Whether it is safe depends on whether each record can only be read and changed by the people who should, whether secrets are out of reach, and whether anything backs the data up. Those are the things we test, signed in as the wrong kind of user, before saying yes.
What can be exported depends on your plan, and Base44 changes its plans, so check its current documentation. Reports indicate that export covers the front end and that the database and backend stay on Base44. Treat any export as the start of a migration, not the end of one.
No. We hold no partnership with Base44 and none of this page is an endorsement or a criticism. It is a fast way to learn whether an idea is worth building, and we treat what comes out of it as a prototype that needs the checks any prototype needs.
A review of a typical single-purpose app is a matter of days, not weeks. We do not publish prices; a quote follows a short conversation about what the app does, who uses it and what it holds. The report is written so that you can act on it yourself or hand it to another developer.
Page copy drafted with AI assistance. Skofi is accountable for it. Editorial policy
Tell us about the process that keeps costing you.
A 15-minute call is usually enough to say whether this is an automation, an integration, or something that should be built, and whether we are the right people for it.
What happens on the call
- 15 minutes, no deck
- We map the process on the call
- A written scope, or an honest no