What happened

Base44, an AI app builder that lets people build software by describing what they want in chat, rolled out Branches, a way to work on a separate copy of your app without touching the live version.

Creating a branch starts a fresh copy of your app from wherever your main version currently stands. You build on that copy the same way you always build, by chatting with Base44’s AI. Design and page changes stay separate until you merge them back into main. Records and shared settings remain connected to the live app. Each branch gets its own chat and its own live preview, so you can leave a branch mid-experiment and come back to it later without losing progress.

Merging is a two-step process. First you merge a branch into main, which folds your changes into the main version. Then you publish from main, which is the separate step that actually pushes those changes to your live app. Base44 says this exists so “you stay in control of exactly what goes out and when,” meaning a merge alone doesn’t put anything in front of your users.

Why it matters

Git branches isolate work in progress from a project’s main code version. Base44 brings a version of that workflow to people who build without writing code. You can try a redesign without publishing it to real users.

Branch isolation stops at the app’s design and front-end behavior. Design and page layout are isolated per branch, so cosmetic and structural changes stay contained until you merge. Your actual data is not. Base44’s own announcement is direct about this: records, connections (the outside accounts and services your app links to, like a payment processor or an email tool), automations, workflows, in-app agents, and app settings are shared across every branch and main. “Any records you add, change, or delete while previewing a branch affect your real data everywhere.”

A preview that edits or deletes customer records touches the same database your production app uses. A branch separates design and front-end changes from the main version. It does not protect your data.

Base44’s fix is a separate feature called test data, which lets you swap in fake data for a branch’s preview instead of pointing it at your real records. According to Base44, test data is available on the Builder plan and higher, and you set it per branch, not once for the whole app. If you’re on a lower plan, that safety net isn’t available to you, so any branch that touches records is working against your live data by default.

Apps synced to GitHub, a service for storing and tracking code versions, cannot use Base44 branches at the same time. And publishing, changing your app’s data structure, and editing stored credentials, connections, or automations only happen from main, not from inside a branch.

Who should care

This matters most when you test features that read, write, or delete records in an app with real users. It also matters for teams: Base44 says branches let people work on separate features in parallel, which raises the odds that more than one person is previewing a data-touching branch against the same live records at once.

If your app is still in early development with no real user data at stake, the shared-data behavior is much lower risk, since there’s nothing sensitive to accidentally overwrite yet.

What builders should do next

Before you preview any branch that adds, edits, or deletes records, check two things: whether your plan includes test data, and whether you’ve actually turned it on for that specific branch. Test data is set per branch, so enabling it once doesn’t cover every new branch you create afterward.

If you cannot confirm test data is active, treat preview actions as actions on your live database. Design changes stay separate, but check whether previewing them triggers writes or automations. Do not delete or bulk-edit records until you have confirmed test data is on.

Keep design experiments on branches, and confirm test data is enabled on each branch before changing records.

End of article