A FlutterFlow app is never owned in just one place. The FlutterFlow project itself has an owner, the Firebase or Supabase backend behind it has a separate owner, and the Apple and Google developer accounts the app is published under have their own owners too. This is usually what people mean when they ask what happens when their FlutterFlow developer leaves, and the FlutterFlow project is actually the easiest part of the FlutterFlow project handoff to sort out. The parts that quietly cause months of delay are the backend and the store accounts, because those live outside FlutterFlow entirely and nobody checks who controls them until the day it matters.
We get asked some version of this question every time a founder is switching from a freelancer to an agency, or bringing app development in-house after working with an outside team. It's a fair thing to worry about, and it's the real agency continuity risk behind a lot of hiring decisions that never gets said out loud. A FlutterFlow project ownership transfer sounds like it should be a simple settings toggle, and for one narrow part of it, it is. For the rest, it depends on decisions that were (or weren't) made back at the start of the project, long before anyone was thinking about an exit.
Can you actually transfer ownership of a FlutterFlow project?
Yes, FlutterFlow has a built in way to transfer project ownership to another account, but the recipient has to already hold a paid FlutterFlow plan before the transfer will go through, and once it's done it can't be undone from your side. If the account receiving ownership is still on the free tier, the transfer will not complete, which is the single most common reason people get stuck here.
The process itself is straightforward on paper: from Settings & Integrations, under Project Setup, you open the project's Team or Collaboration page, select the person who should become the new owner, and confirm. FlutterFlow's own support team cannot do this step for you; only the current owner can initiate it. Once it's confirmed, the previous owner loses owner-level rights immediately, though they can be re-added afterward as a regular editor or viewer. If you want ownership back later, the new owner has to transfer it back to you the same way. There's no in-between state and no admin override, so this is not something to click through casually at the end of a long day.
It's also worth knowing this isn't a flawless process. FlutterFlow's own public issue tracker has a documented case where a project transfer created a duplicate user entry, one with editor access and one with owner access, that left neither the old nor the new owner able to manage the project properly until FlutterFlow's support team manually cleaned it up. The team traced it to an edge case involving project branches carrying a separate set of collaborator settings that didn't sync cleanly during the transfer. It's rare, but it's a real reason to do a transfer with some buffer time before you actually need full control, not the same afternoon a contract ends.
Does transferring a FlutterFlow project also transfer team ownership?
No, and this is where most of the confusion actually lives. Project ownership and FlutterFlow team ownership are two different things, and only the project-level transfer has a documented, self-serve process. Changing who owns the team itself, the account that holds the subscription, seats, and billing, is a much less clear path.
Search FlutterFlow's own community forum for this and you'll find the same question asked repeatedly over multiple years with no official documented answer: how do you change who owns the team account, as opposed to a single project inside it. If your agency or freelancer built your app under their own FlutterFlow team rather than a team you control, transferring the individual project to your account solves part of the problem, but billing, seat management, and any projects you haven't explicitly asked to be transferred stay exactly where they were. This is exactly the kind of gap that gets missed in a verbal handoff conversation, because both sides assume "we're moving everything over" without checking whether that's even a button that exists.
What happens to the Firebase or Supabase backend when the FlutterFlow owner leaves?
Nothing happens to it automatically, and that's the problem. A FlutterFlow project transfer only moves the FlutterFlow project itself; it has no effect on who owns the connected Firebase or Supabase backend, because those live in a completely separate account, usually whoever's personal or company email created the Google Cloud project or Supabase organization in the first place.
In practice this means a founder can end up with full FlutterFlow ownership and zero ability to manage their own database, authentication rules, or storage buckets, because the backend is still sitting under a developer's personal Google account. Adding a new Owner in Firebase's IAM settings, or inviting a new member into a Supabase organization, is a five-minute task when both sides are cooperating. It becomes a real problem when the relationship has already soured, which is precisely when it tends to come up. This is the specific risk we flagged for agencies managing many client backends in our checklist on FlutterFlow white-label client onboarding , and it applies just as much to a single client project as it does to fifteen.
What happens to the app when it moves to a new Apple or Google developer account?
Most of what matters survives when you transfer an app to a new developer account, but a specific list of things does not, and both Apple and Google publish exactly what's on that list. For an iOS app, reviews, ratings, existing users, the bundle ID, subscriptions, and in-app purchases all transfer with the app under Apple's official App Transfer process. What doesn't survive cleanly includes TestFlight data (all builds and testers get wiped and must be rebuilt), Apple Pay Merchant IDs (the new account has to create its own), Game Center multiplayer groupings, and certificate-based push notifications, which keep working until they expire and then need to be reissued under the new account.
On Android, Google Play Console transfers carry over users, install counts, ratings, and reviews, but bulk export reports, estimated sales reports, and earnings reports have to be downloaded before the move because they don't come along with it. Orders placed before the transfer stay tied to the original account for refund purposes. One detail that trips people up specifically: private apps distributed through Managed Google Play cannot be transferred to a different developer account at all, which matters if your app was ever set up for enterprise distribution early on.
None of this is disqualifying. It just means "we'll transfer the app later" is a real project with real steps, not a five-minute favor, and it goes faster when the account holding the app was always meant to be temporary rather than a surprise you discover during a dispute.
Common mistakes that turn a simple handoff into a mess
Building everything under the developer's own accounts with no documented plan to move it. This is the single biggest cause of painful handoffs. It's not wrong to start fast under a freelancer's or agency's existing Apple, Google, Firebase, or FlutterFlow team account, but it needs a written understanding of when and how ownership moves to you, not an assumption that it'll happen smoothly when asked.
Confirming the new owner has a paid FlutterFlow plan only after starting the transfer. Since the transfer won't complete without one, check this first. It's a two-minute question that avoids a stalled transfer at the worst possible time.
Treating the FlutterFlow project transfer as the whole handoff. As covered above, it's one piece of at least four (FlutterFlow project, FlutterFlow team, backend, and store accounts), and each one needs to be checked separately, not assumed to follow automatically.
Not getting admin access details in writing at the start of the relationship. We touched on this from the freelancer side in our piece on FlutterFlow freelancer vs agency , and it holds just as true for an agency engagement: who owns what, and how access moves if the relationship ends, is worth ten minutes in a contract and avoids months of friction later.
Waiting until the relationship is already ending to ask these questions. Every part of this process goes faster and friendlier when both sides are still on good terms. Asking "how would we move everything to our own accounts if we needed to" during onboarding is a completely normal question, not an accusation.
How Devnixs handles ownership and handoff
We default to building under the client's own Apple Developer, Google Play, Firebase, and Supabase accounts from day one wherever that's practical, rather than our own, specifically so there's no account-ownership conversation needed later. When speed matters early on and we do start something under an account we control, usually for a first prototype before a client's own accounts are fully set up, we agree on the transfer plan and timeline up front, in writing, not as a verbal "we'll sort it out."
We also keep a shared record of every account involved in a project: the FlutterFlow team and project, the backend, and both store accounts, so a client always knows exactly what they'd need to take over and from where if they ever wanted to. You can see the kind of builds this approach supports in our portfolio . As a Certified FlutterFlow Expert Agency working on FlutterFlow app development for clients across India, the US, and Australia, we've picked up enough projects that started elsewhere to know that most handoff pain isn't about bad intentions on either side, it's about nobody writing down who owned what until it was already a problem.
FAQ
Can you transfer ownership of a FlutterFlow project to another account?
Yes. The current owner can transfer project ownership to another FlutterFlow account through Settings & Integrations, but the recipient must already have a paid FlutterFlow plan or the transfer won't complete. The action can't be undone by FlutterFlow support; it has to be reversed by the new owner transferring it back.
What happens to a FlutterFlow project if the account that created it gets downgraded or canceled?
Collaborators on that project can lose edit access and the project can become read-only, even if someone else has been actively working on it as a collaborator. This has been reported directly by users on FlutterFlow's community forum, and it's a good reason not to leave a project's ownership sitting on a free or soon-to-lapse account indefinitely.
Does moving a FlutterFlow project to a new owner also move the Firebase or Supabase backend?
No. The FlutterFlow project and its connected backend are owned separately. Transferring the FlutterFlow project has no effect on who controls the Firebase console or Supabase organization behind it; that access has to be granted separately by whoever currently owns that backend account.
Can you transfer team-level ownership in FlutterFlow, not just a single project?
There's no clearly documented self-serve process for this, unlike project-level transfer. Multiple users have asked FlutterFlow's community forum this exact question over time without a definitive public answer, so if your app lives inside someone else's FlutterFlow team, moving the one project you need is more reliable than assuming the whole team can be handed over.
Will you lose your app's reviews and ratings if you transfer it to a new Apple or Google developer account?
No, reviews, ratings, and existing users transfer with the app on both platforms. What you can lose includes TestFlight builds and testers, Apple Pay Merchant IDs, and certain reports that have to be downloaded before the move, so it's worth reviewing the current list on Apple's and Google's own transfer documentation before initiating one.
What should be agreed in writing before starting a FlutterFlow project with a freelancer or agency?
Who owns the FlutterFlow project and team, who owns the Firebase or Supabase backend, who owns the Apple and Google developer accounts the app publishes under, and what the process looks like to move all four if the relationship ends. Getting this in writing at kickoff takes very little time and prevents almost every painful handoff story we hear about secondhand.
If you're switching developers, bringing development in-house, or just want to know exactly who owns what in your current setup before it becomes a problem, talk to Devnixs today. Contact us and we'll walk through your project's actual account structure with you and give you a clear, honest plan for getting full ownership where you need it.
