Come off the line.
Fold back in.

Sam's deliberately non-technical definition: a branch is "like having a new conversation with the builder in its own separate dedicated preview, as like a fork." Picture the app as a pathway running forwards; a branch is where you come off that pathway in a different direction. The point is that multiple people, or the same person on multiple ideas, can develop different parts of the app at the same time without touching the production version. Multiple versions of the application can be in development simultaneously, and any of them can be merged into production at any point — even if the work was done two months earlier. His headline framing: "it's like having multiple staging environments."

The entry point is intentionally tucked away. Top left of the builder, left-click the name of your app, and Branches is in that menu. From there you press create a new branch, which spins up a new preview window and a new builder conversation that sits alongside production. Sam repeated this ingress path three separate times during the session because the whole point of the stealth release is that people will not find it by accident.

"Nothing you do here will impact your production, except — and the caveat to that is — data." As with everything in Base44, the database is impacted live. The mitigation is the test data button, found in data and (Sam hedged) settings. That toggle is instanced to the branch you are in: you can be in a branch using test data while main is not, and Sam's example was "you can have three branches each with test data versions that are not the same." His explicit warning: "leaving this off means that every branch uses the current database tables. It's a key caveat."

"You can have as many branches as you want. There is no limit. You can spin up as many as you'd like." The constraint is on execution, not count: "you can only work on one conversation in one branch at one time." Sam found this live — with the redesign branch building, he could not send another prompt from main. He believes additional prompts simply queue ("I think you'll just cue if you do it otherwise") and flagged that the restriction may be subject to change. Sequential prompting across branches is completely fine: one prompt to main, then one to the branch, then back again.

Once you are in a branch, the top-right button is no longer Publish, it is Merge to main. Pressing it collapses the two pathways into one: "these two branches come down together. They fold. They collapse into one." Asked what merging actually does, Sam's explanation was that it is exactly equivalent to what the current builder already does if you had simply typed all of those prompts into main — the branch history goes into your production app. After the merge, the chat gets a written summary of what the branch changed; on the live CRM merge that note read "added a CRM dashboard CRM with eight KPI statistics and four data visualizations." Merging does not publish — after merging you would still press publish for the change to reach production users.

If main moves on after you create a branch, you have to bring the branch up to speed first. Sam: "if you make a bunch of branches and then you change your main, you must update the branch. So you go into the branch and pull the main up to speed... before you're able to merge it." The UX is an Update branch button that appears in the branch's chat. This ordering is why merge conflicts should not exist: "you can't merge to main without updating the branch to the current version of main. So there should never be a conflict." When there is nothing conflicting, the update completes immediately and shows "branch updated" with a check mark and no questions asked.

When updating a branch does conflict, the builder asks which version to keep. Sam hit this on air for the first time — he had changed the hero video and the content below it in main, while the branch carried a dark redesign — and initially misread the question. His correction, worked out live: "It wasn't asking us what we want in main. It was asking us what we want in this preview window." So the question is about what the branch keeps when main is pulled in: are you bringing across text, new pages, or the old design that may have been modified? He chose to keep the branch version, so only the content changes came across and the green-and-black redesign survived. Had he chosen the main version, "the whole of the work that we would have done would have been overridden."

The demo app was a one-prompted Algarve surf school landing page built minutes before the stream using Sam's own prompt-writing tool from the previous day's session — parallax scrolling, generated imagery and video, with the Lenis and GSAP npm packages installed from prompt one. He switched the builder off Fable and onto Auto for speed, then used voice mode for the prompts. Branch one, the redesign: "I like what we have in terms of the design of the website. It's beautiful. But I want to go for a completely different approach, a bold redesign. Please, can you redesign the entirety of the app inside and out and present me with a new vision?" Branch two, the CRM: "Please build me a back-end CRM for the app with an analytics dashboard taking into account all of our bookings, the location of the people booking, how many people are locals versus how many people are tourists and not from Portugal, all sorts of basic analytics that we would want to make a successful business." A third Halloween-themed branch was described in detail as an example but was never actually created — Sam dropped it in favour of an attendee request to demonstrate pulling main into a branch. Meanwhile he changed main itself with "regenerate the hero video into a sunset wave scene, please. Four to six seconds looping" plus a content rewrite, purely to create something to sync. He merged the CRM branch into main and deliberately did not merge the redesign branch.

The worked example: you have a production app with thousands of users, and a Base44 partner has spent six days and several hundred of your money building a CRM backend in an unpublished branch. A user reports a critical bug that needs patching now. Before branches this is a real problem. With branches: ask the partner for 5 to 10 minutes, his work on the branch pauses, you fix the front-end problems in main, you publish those changes, you hand back to him, he pulls main into his branch to sync it, and he carries on in his own lane. When he is finished he merges and the CRM slots back onto the main path. Sam — a former partner himself — added that the bigger win is not waiting on client sign-off: "the amount of times that I worked on things for me to have to go, is this in the right direction? ... and have to wait for responses and confirmation and thumbs up from the client before being able to do anything else. This prevents that entirely."

"Essentially, what this is doing for you is it's preventing you needing to revert things." Sam's own example from Card Center: he built a raffle system where scanning a Pokemon card entered you into a draw, and once the draw reached a thousand submissions a user won a free graded card in the post — a hatching incubation flow with a Togepi egg, end-to-end automated emails, branded templates and animations. He estimated "like 100 prompts" of work. It was too cheesy for the brand, so he binned it via a revert. "The bin to me then was a reversion. In this time it would be a branch." Asked directly whether branches replace reverting, his answer was that they are separate things — branches just make reverting something you need to do far less often.

Sam connected branches to a live community pain point: "there's a lot of people in the community recently that have been experiencing sort of a slowdown once apps reach like hundreds of thousands of lines of code and multiple thousand backend functions." Branches help because speculative features never enter the main codebase unless they are actually going to be used — "you're not developing things that then get underused, because they're in branches and they only get merged in if they are going to be used." His framing: it is not automatically true that if something is cool it should be in your app.

Two existing workarounds came up. The first, raised from chat, is duplicating the app and working on the copy — Sam said he had never done it that way. The second and more common one is RLS: build the feature, lock its visuals and access point to admin only, then toggle it on from an admin control panel when it is ready. "That's how you would normally deal with it. This is just a way more smooth, less bulk" approach.

To get back to the state of main from before a merge, go to version history, find the version you were happy with (in the demo, the one without the CRM), press the three dots and choose revert to this version. Sam also noted the branch list appears to be ordered newest to oldest — "or probably last edit, I'd imagine" — which caught him out live when he clicked into the wrong branch.

Beyond the missing delete and backend functions, Sam surfaced a UX complaint while demoing: "sometimes I can access other branches when I'm in one, sometimes I can't. That might be a bug." He wants to be able to click freely between main and other branches while one branch is processing, and said so directly to the team on stream. He also hit a spinning main branch he could not open, and noted that a page refresh usually clears these states.

Answering a question about the side-scrolling effect in the demo app, Sam named the two npm packages as Lenis and GSAP, and recommended installing both on any build where you care about design: the smooth scroll effect on its own is Lenis, but combining Lenis with GSAP also gives you much cleaner transitions on navigation. He pointed at the one-prompt prompt-writer app he had built during the previous day's session — you type an idea (his live example was a natural wine bar in Leeds), pick the goal (buy, book, reserve or inquire), specify photography, press write my prompt, and it returns a prompt with its knowledge of Lenis, GSAP and design principles baked in.

Asked whether to build a website in one branch and connect it to an app built in another, Sam pushed back on the whole premise. Base44 builds React JavaScript web apps, and "in 2026" the website-versus-web-app distinction is a misnomer — a Base44 app can be a landing page for a barber shop, an info box, or a full mobile-style application, and the same app can carry a website-style front end. The fix is one prompt in the builder: "build me a landing page for this application. It needs to be accessed by non-logged users and the rest of the app that we have built needs to be gated behind login and authentication." No second app, no branch required.