What should you ask Base44 to build first?
Start with one action you can check. For a repair service, ask for a page where a signed-in customer submits a request and can see its status afterward.
- Keep the example separateUse a new disposable app with invented names, records and test users you control. Before using the preview, check that it has no live data, service connections, payments or notification actions. Stay on paper if you cannot confirm the setup.
- Describe one request and its access rulesAsk for a request with a title and status, visible only to the customer who created it. Leave file uploads and external services out of the example. Open the table’s permissions in the dashboard and check who can create, read, edit and delete records.
- Try it as two ordinary test usersIn the isolated preview, submit a request as the first dummy user. Then test as the second dummy user and try to open that same request through the ordinary app. The first user should see it and the second should be denied. Use a paper checklist if you cannot test both roles without real users.
What can a signed-in visitor see or change?
App visibility controls who can open the app. Record permissions control what an admitted person can read or change.
Base44 provides sign-in and tables for app records. If you use the invite-only Private setting, Base44 documents that it requires Starter or higher. Check the generated rules in the dashboard before using real records.
If you connect a service later, decide whose account the app will use. A shared connector uses one connected account for everyone in the app. An app-user connector lets each person use their own account. Check the permissions granted to that connection before enabling it.
What happens to previews and data when you publish?
Publish puts the finished app version at its live address. The published app uses the live database even while you are testing in the editor.
Base44’s Test Data option on Builder or higher starts with an empty database for test records. Select it in preview before interacting with the app. A branch is a separate copy of app changes, and its preview can use live records by default. The main version and every branch share one set of test records. The app also shares user accounts between live and test, so editing a user’s profile or role in a test changes their real account. Payments, emails and other outside calls still go to the configured services. If you need to test those calls, use a separate practice app with test connections.
Workflows can act independently of the page release. Base44 documents that when you save and redeploy a backend function on main, workflows can use that new version immediately. A backend function is code that runs on the service, such as code that sends a notification. Check what runs before changing a function used by a live workflow.
What uses credits while you build and after launch?
Base44’s public app plans list message credits for AI work in the editor and integration credits for actions that use services such as built-in email. An AI request can use a varying number of credits.
The personal Free workspace has a documented limit of five message credits per day within 25 per month. An integration that uses credits can fail when its allowance runs out, even if visitors can still open the app. Check the usage breakdown in your own workspace because Base44 says the way an action is billed can vary by workspace. A separately connected service can also have its own charges.
| Workspace plan | Price | Monthly message credits | Monthly integration credits |
|---|---|---|---|
| Starter | US$16 per month, billed annually | 100 | 2,000 |
| Builder | US$40 per month, billed annually | 250 | 10,000 |
On a small screen, scroll the table sideways to read every column.
What do you get when you export?
With edit access on Builder or higher, you can download the app code as a ZIP file. If you run that code as exported on your computer or another host, it still uses the live Base44 app’s records, sign-in, server functions and connected services. Check those destinations before you run the copy.
The ZIP includes the screen code, server-side functions and table definitions, including permission settings. App users, secret credentials and the records in those tables stay outside the ZIP. Export records separately as a CSV file for each table. Check whether a filter is on before treating the file as a full copy.
Builder or higher also supports two-way GitHub synchronization for the app code. If you plan to leave Base44, decide where sign-in, files, stored records and outside connections will live. A code copy alone cannot confirm that those pieces work together on a new host.