FlutterFlow's real-time collaboration and Git branching work fine for a two or three person team building one feature at a time. The trouble starts once an agency has multiple developers working in parallel branches, because FlutterFlow only lets you merge a branch into the branch it was created from, its GitHub sync only pushes changes out and never reads custom code back in, and FlutterFlow's own support team has, in a documented community thread, acknowledged merges that silently dropped days of work for teams running four to fifteen developers.
We get asked about this constantly, usually by a founder or a CTO who has already hired a FlutterFlow development team and hit one of these walls mid-project. "Why did my teammate's changes disappear after we merged?" "Why can't I switch this branch to the staging environment?" "Why does old code keep coming back after we fix it?" None of these are edge cases. They're the direct, documented result of how FlutterFlow's branching model and GitHub integration are built, and almost nobody writing about FlutterFlow for agencies talks about them honestly, because most of what's published is either a basic "how to connect GitHub" tutorial or a sales page for an agency's own services. We've run multi-developer FlutterFlow projects ourselves, hit several of these exact walls, and this post is the plain-language version of what we learned the hard way.
Does FlutterFlow support real-time team collaboration?
Yes, FlutterFlow team collaboration works through real-time editing, but only on the Growth plan and above, and only within the FlutterFlow editor itself. Multiple builders can open the same project, watch each other's cursors, and edit the same page or design system component at the same time, similar to Google Docs.
That part works well for day-to-day building. The limitation shows up around scope: FlutterFlow real-time collaboration covers editing the same project interactively, not coordinating separate features being built in isolation. For that, FlutterFlow hands you off to its branching system, which is a different tool with a different, much less forgiving set of rules.
What actually breaks when multiple developers use FlutterFlow branching?
The core limitation of FlutterFlow Git branching is that it only supports merging a branch into its direct parent, the branch it was created from, and nothing else. If your team structure doesn't match that strict parent-child hierarchy exactly, branching stops working the way you'd expect from a normal Git workflow, and these FlutterFlow branching limitations show up quickly once more than one or two people are involved.
This single rule causes most of the real pain we've seen reported. A few concrete ways it bites teams:
What happens if you delete a branch with unmerged children?
You orphan the child branch and lose its direct path back to main. This is a documented FlutterFlow issue, not a hypothetical: a developer created a nested branch structure (main, then a feature branch, then a sub-branch off that feature branch), deleted the middle branch once its own work was merged, and the sub-branch was left with no parent to merge into. FlutterFlow support had to manually reassign the orphaned branch's parent to main as a one-off fix, and said at the time they were working on simply blocking deletion of any branch that still has unmerged children, rather than letting this happen in the first place.
The practical rule until that protection is airtight: merge every child branch before you delete its parent, every time, even when the parent's own work is already merged and it feels safe to clean it up.
Can a branch cause real data loss during a merge?
It has, for entire teams, and this is the most serious documented case of FlutterFlow merge conflicts going wrong. In a FlutterFlow GitHub issue about merging on a team subscription, multiple teams of four to fifteen developers reported merges that overwrote or silently dropped changes from both the source and target branches, merge screens that reported success with "no changes to merge" on a second attempt, and rebase operations that failed to apply changes at all. Some teams lost several days of work and considered leaving the platform entirely.
FlutterFlow's own founders responded in that thread, called it a top priority, and apologized for slow escalation, but no single confirmed permanent fix was documented in the public discussion. A related, narrower issue showed the same "merge appears successful but nothing changed in main" symptom on a single project; FlutterFlow support couldn't reproduce it in a blank project and treated it as project-specific rather than platform-wide. Either way, the lesson for a team is the same: never fully trust a merge confirmation on a branch that matters. Diff the actual project state after merging, not just the merge dialog's success message.
Why can't I switch a branch to my staging environment?
For a period, branches could only use the Production environment, not development or staging, which directly contradicted FlutterFlow's own documentation recommending you build on a dev environment inside a branch. FlutterFlow confirmed this was an unintended restriction introduced when branching environments launched, not a designed limitation, and said a fix was coming the following week. It's worth checking this still behaves correctly in your own project before you assume branch-level environment isolation is safely in place, especially because the same thread surfaced a second, still-relevant gotcha: environments created on a branch don't automatically exist on the main branch, and Firebase projects stay permanently linked to whichever environment they were first connected to.
Why does old code keep reappearing after you push through GitHub?
Because FlutterFlow's GitHub integration pushes changes out to a dedicated flutterflow branch but never reads custom code back into the visual editor, which makes the relationship one-directional in a way that trips up teams who assume it behaves like a normal two-way Git remote. One developer described the exact failure mode on FlutterFlow's community forum: opening a pull request from flutterflow into develop causes GitHub's automatic conflict resolution to commit its resolution back onto the flutterflow branch, and that resolution can carry old dependencies and old code forward into the next pull request, even after that code was already fixed in develop. Their stated workaround was to stop using pull requests for this step entirely and manually diff the two branches by hand instead.
A separate, related complaint from a developer managing a larger app, documented on FlutterFlow's community forum, is that any custom code written directly in a GitHub branch cannot be synced back into the FlutterFlow editor at all. If that custom code references classes or logic that live outside what FlutterFlow's editor can see, the version of the app still being maintained inside FlutterFlow can end up unable to compile, creating a permanent fork between "the app in the editor" and "the app actually being shipped." If your team needs genuine two-way custom code, that's usually the point where it makes sense to bring in custom Flutter code on specific modules rather than fighting the one-way sync, and we've written more about exactly when that threshold gets crossed and what FlutterFlow's export actually gives you to work with in our breakdown of how FlutterFlow's code export actually works.
What does branching and collaboration actually cost?
Real-time collaboration and branching are both gated to the Growth plan and above, which currently runs $80 per month for the first editor seat and $55 for each additional seat. The Business plan, at $150 for the first seat and $85 for each additional seat up to twelve total, adds extended branching limits and more team management controls on top of that.
That's a meaningful budget line for an agency, not just a feature toggle, because it scales with headcount rather than with project count. A five-developer team on Growth is paying for five seats whether they're all actively branching that week or not, which is one more reason the merge reliability problems above matter so much: you're not just risking lost work, you're paying ongoing per-seat costs for tooling that's supposed to prevent exactly that kind of collision.
Common mistakes agencies make with FlutterFlow branching
The most common mistake is treating FlutterFlow branches like a full Git workflow with the same flexibility, rebasing freely between unrelated branches, deleting parent branches as soon as their own work is merged, assuming a successful merge dialog means the diff actually applied. Each of those assumptions has a documented case where it went wrong.
The second is skipping a manual diff check after any merge that involved more than one active contributor. Given that FlutterFlow's own support team has confirmed merges that silently reported success without applying changes, a quick read-through of the merged branch's actual state takes a few minutes and avoids discovering the problem days later when someone builds on top of work that was never actually there.
The third is assuming GitHub integration gives you a real two-way code pipeline. It doesn't. Anything written as custom code on the GitHub side needs a deliberate plan for how, or whether, it ever needs to come back into the visual editor, because FlutterFlow's export and GitHub sync were built around FlutterFlow staying the source of truth, not around merging hand-written code back in.
How Devnixs handles multi-developer FlutterFlow projects
We're a Certified FlutterFlow Expert Agency, and on any project with more than one or two developers, we scope the branching structure flat and shallow on purpose, avoiding nested branch-of-a-branch setups specifically because of the orphaning risk above. We also build in a manual diff check as a standard step after any merge involving concurrent contributors, rather than trusting the merge dialog alone.
When a project genuinely needs custom code that goes beyond what the visual editor and its one-way GitHub sync can support, we plan that scope separately from day one instead of discovering it mid-build. If you're deciding between a solo freelancer and a team for a project like this, team structure and process maturity are exactly the kind of thing we cover in our honest comparison of FlutterFlow freelancer vs agency work, and if you're scaling client delivery across multiple builds, our white-label client onboarding checklist covers the related question of where manual coordination work starts breaking down as team size grows. You can see examples of multi-developer builds we've delivered in our portfolio .
FAQ
Can multiple developers work on the same FlutterFlow project at once?
Yes, through real-time collaboration on the Growth plan and above, which lets multiple builders edit the same page or design system simultaneously and see each other's changes live. For separate features built in isolation, teams use FlutterFlow's branching system instead, which has stricter rules than real-time editing.
Why did my FlutterFlow branch merge show success but nothing changed?
This has been documented in FlutterFlow's own GitHub issue tracker as a merge that reports success internally without actually applying the diff to the target branch. FlutterFlow support has been unable to reproduce it consistently and treats most cases as project-specific, so the safe practice is to manually check the merged branch's actual state rather than trusting the merge confirmation alone.
Does FlutterFlow's GitHub integration sync custom code back into the editor?
No. The integration pushes FlutterFlow's own changes out to a dedicated flutterflow branch, but any custom code written directly on the GitHub side does not sync back into the visual editor. This creates a one-directional relationship that can leave the editor version of your app unable to compile if that custom code depends on logic the editor can't see.
Can I merge a FlutterFlow branch into any other branch?
No, only into its direct parent, the branch it was originally created from. Deleting a parent branch before merging all of its child branches can orphan those children with no direct merge path, which has required manual intervention from FlutterFlow support in at least one documented case.
What plan do you need for FlutterFlow branching and team collaboration?
Both require the Growth plan or higher, currently $80 per month for the first seat and $55 for each additional seat. The Business plan, starting at $150 for the first seat, adds extended branching limits for larger teams of up to twelve seats.
Is it safe to use separate environments on a FlutterFlow branch?
Check this carefully in your own project. FlutterFlow previously restricted branches to the Production environment only, contrary to its own documentation, and confirmed this as an unintended bug rather than a designed limitation. Environments created on a branch also don't automatically carry over to the main branch, so environment setup needs to be verified on each branch rather than assumed.
If your agency is running into branch merge problems, lost work, or a custom code workflow that's starting to fight the editor instead of helping it, talk to Devnixs today. We'll look at your actual project structure and give you a clear, honest plan for fixing it, not a generic checklist.
