FlutterFlow Code Export: What You Actually Get and What to Fix

Yes, FlutterFlow code export gives you a real Flutter project. You can open it, build it and ship it without FlutterFlow. You need a paid plan to download it, and the code is written by a machine: it runs, but it is verbose, depends on FlutterFlow's own helper files and calls your backend directly from the screens. Expect to clean it up before your team can maintain it as a normal codebase.

Key takeaways

• Code download starts on the Basic plan and GitHub push starts on Growth. The Free plan has no code download (checked September 2026).
• The export is a standard Flutter and Dart project with lib/, pubspec.yaml and native folders. It also includes a flutter_flow/ folder of helpers that your pages depend on.
• Most of the cleanup is splitting up long generated widget files, replacing FlutterFlow's app state and helpers, and moving Firebase or Supabase calls out of your screens.
• AI coding tools such as Claude Code and Codex handle this refactor well, as long as you write tests first and review every change.
• Before you cancel, export every branch with its assets, confirm you own the backend and app store accounts, and ship one release build yourself.

What FlutterFlow Code Export Includes (and Which Plans Allow It)

You need a paid FlutterFlow plan to download code. A pricing snapshot taken from FlutterFlow's pricing page in September 2026 shows these plans:

Prices checked September 2026. Prices and plan limits change, so check FlutterFlow's pricing page before you buy. A separate plan summary from The Rundown puts code download, the CLI and local run on Basic, with GitHub push and VS Code sync starting on Growth.

If all you want is to leave, one month of Basic is enough to download the code. You need Growth if you want FlutterFlow to push to a GitHub repo for you.

How to Export: Download Code vs GitHub Push

Download Code (zip)

The quickest route is the toolbar. FlutterFlow's Local Run docs point to Developer Menu > Download Code, which gives you a .zip of the project. The same page recommends using the FlutterFlow CLI instead, and says to fix any project issues inside FlutterFlow before you download.

FlutterFlow CLI

The CLI export runs flutterflow export-code with your project ID and an API token. Useful flags include --branch-name to export a specific branch, --fix to run dart fix after the download, and --as-module to generate a Flutter module. Watch out for assets: the package listing on pub.dev shows that --include-assets defaults to false, so images and other media are left out unless you ask for them. The same listing documents an --include-export-manifest flag. It writes a file that maps FlutterFlow entities to generated files, which is useful when you hand the project to an AI tool.

There is also a VS Code extension with a "FlutterFlow: Download Code" command.

Push to GitHub

On Growth and above you can connect a GitHub repo by installing the FlutterFlow GitHub App. FlutterFlow always pushes to a branch named flutterflow, and the docs warn that the next push overwrites any direct edits to that branch. Make your own changes on a separate branch.

Use the zip or the CLI when you want a one-time snapshot to take elsewhere. Use GitHub push when you plan to keep designing in FlutterFlow for a while and want version history.

What the Exported Flutter Project Looks Like Inside

FlutterFlow publishes a directory structure guide for its generated code. These are the main pieces under lib/:

• Page and component folders. Each page gets its own folder with a widget file and a matching model file. Shared components sit under components/. Any folders you created in the FlutterFlow UI carry over.
• actions/ holds app-level Action Blocks, generated as functions.
• auth/ handles authentication. With Firebase Auth turned on, the auth docs show files such as firebase_auth_manager.dart and auth_util.dart.
• backend/ covers API requests, cloud functions, database access and data schemas. It includes structs/ for custom data types and utilities like firestore_util.dart.
• custom_code/ holds your Custom Actions and Custom Widgets.
• flutter_flow/ contains helpers such as flutter_flow_animations.dart and custom_functions.dart, plus navigation in nav/.
• app_state.dart, app_constants.dart, index.dart and main.dart sit at the root of lib/. Dependencies are listed in pubspec.yaml.

Outside lib/ you get the usual native android/ and ios/ folders. Any Flutter developer will recognize the layout. The work is in the code inside it.

Common Problems After Export: Generated Widgets, flutter_flow Helpers and Custom Code

Long, deeply nested widget files

FlutterFlow writes code to be safe, not short. One walkthrough of untangling an export notes that a screen you designed in minutes can come out as several hundred lines. Expect huge build methods, repeated styling and little shared code between pages that look alike.

Dependence on the flutter_flow folder

Your pages import FlutterFlow's helpers for theme, navigation, utilities and widgets, so you can't just delete the folder. For each helper, either replace it with your own theme, router or utility code, or keep it and maintain it as part of your codebase.

Global app state in FFAppState

App state lives in an FFAppState class, and generated actions call it directly. The docs example shows an action calling FFAppState().update(). This works, but a single global object makes features harder to test and understand as the app grows.

Custom code written for the builder

FlutterFlow supports Custom Functions, Custom Actions, Custom Widgets and Code Files. They export as real Dart files, but they were written around FlutterFlow's input arguments and conventions. A community post points out that custom code files must be declared in custom_code/lib/index.dart or they won't compile. Review this folder early, because it often holds your most important business logic.

Backend Coupling: Untangling Firebase or Supabase Calls

The biggest structural problem is that screens call the backend directly. The same walkthrough describes the backend as woven in rather than bolted on. Queries, writes and auth checks sit inside page widgets and generated actions, not behind a service layer.

The good news is that your data lives in your own Firebase or Supabase project, not inside FlutterFlow. The export keeps working as long as you provide the backend config. For a refresher on how that connection is set up, see our guide to FlutterFlow and Firebase.

The fix is a repository layer. For each feature, create a class that handles its reads and writes (for example OrdersRepository), then change the screens to call that class instead of Firestore or Supabase. Once every call goes through a repository, swapping or upgrading the backend touches far less code. If you haven't decided which backend to keep, our Firebase vs Supabase comparison covers the tradeoffs. If you're moving data between them, you'll need a written data migration plan.

Can You Keep Editing in FlutterFlow After You Export?

Yes, but changes only flow one way. FlutterFlow generates code and does not read hand-edited generated files back in. If you keep designing in FlutterFlow, the GitHub workflow is to let FlutterFlow push to its flutterflow branch, then merge those changes into your own branch and resolve conflicts each time.

This hybrid setup can work for a short transition. It gets painful once you start restructuring, because every FlutterFlow push brings back the old structure and your merges get bigger. It is usually cleaner to pick a cutover date: do a final export, then do all further work in code.

Cleaning Up the Export With Claude Code or Codex: A Step by Step Approach

This refactor means making the same kinds of changes across many files, which is where agentic tools like Claude Code and OpenAI Codex do well. FlutterFlow now supports this too: its CLI listing describes an MCP server that lets agents, including Claude Code and Codex, work with FlutterFlow projects. If you're leaving the platform, these are the steps:

1. Take a clean baseline. Export with assets into a new Git repo, commit it untouched and tag it. Every later change then shows up as a diff against that tag.
2. Get it building. Run flutter pub get, add your Firebase or Supabase config and run the app on a device. Fix analyzer errors before you change anything else.
3. Write the rules down. Add a CLAUDE.md or AGENTS.md file that describes the target: folders organized by feature, your state management choice (Riverpod, Provider or Bloc), the repository pattern and naming rules. Agents follow written rules much more reliably than unwritten ones.
4. Take inventory before refactoring. Ask the agent to list every page, route, backend call, custom action and package. Use the export manifest if you generated one. This list becomes your migration map.
5. Add tests first. Have the agent write widget tests plus a few integration_test flows covering login, the main user journey and payments. These tests catch anything the agent breaks.
6. Refactor one feature at a time. Move backend calls into repositories, replace FFAppState reads with your chosen state management, and split large widgets into small ones. Keep each change small enough to review in one sitting.
7. Remove FlutterFlow helpers last. Delete each helper once no page imports it. Remove any packages from pubspec.yaml that nothing uses.
8. Check everything in CI. Run flutter analyze and flutter test on every pull request, and have a person review each diff before it merges.

These tools make the work much faster. You still need someone who knows Flutter to make the architecture decisions and catch subtle breakage.

Testing, Builds and App Store Releases Without FlutterFlow

You lose FlutterFlow's one-click deployment when you leave, so you need your own release process. FlutterFlow's own Deploy from GitHub docs describe automating store releases from a repository after you change the code. That is a good model to follow.

• Builds: follow Flutter's release guides for Android and iOS (flutter build appbundle and flutter build ipa).
• Signing: make sure the Android upload key and App Store Connect access are in your own accounts. Without them you can't ship updates to your existing app listings.
• Automation: GitHub Actions, Codemagic or fastlane can build, sign and upload the app every time you merge.
• Versioning: keep increasing the build number from where FlutterFlow left off, or the stores will reject the upload.

Ship one small update through the new process while you still have FlutterFlow access. That way you know it works before you depend on it.

When to Refactor the Export vs Rebuild From Scratch

The export gives you a head start, but you don't have to use it. This table can help you decide:

The export is still useful if you rebuild. It is an exact spec of every screen, field and backend call, and an AI coding tool can read it to scaffold the new app. The backend usually stays either way, since it already lives in your Firebase or Supabase project. If you're still working out why you want to leave, our post on no-code limitations helps you tell real platform limits apart from problems you can fix.

A Checklist Before You Cancel Your FlutterFlow Plan

• Export the final code from every branch you need, with assets included.
• Commit the untouched export to a repo your company owns.
• Write down the Flutter SDK version the project builds with.
• Confirm your Firebase or Supabase project, billing and admin access are in your own accounts.
• Copy the API keys, environment values and API call settings you set up inside FlutterFlow.
• Confirm you control your Apple Developer and Google Play accounts, signing keys and push notification credentials.
• Move your custom domain DNS and web hosting if FlutterFlow hosted your web app.
• Build, sign and submit one release from your own machine or CI.
• Screenshot or document any settings you can't find in the code.

If you'd rather hand this off, Let’s Build My App does FlutterFlow to code migrations with Claude Code and Codex, from the export through cleanup to your first release without FlutterFlow.

Frequently asked questions

Does FlutterFlow let you export code on the free plan?

No. A pricing snapshot taken from FlutterFlow's pricing page shows that, as of September 2026, code and APK download start on the Basic plan at $39 per month and GitHub integration starts on Growth. Check flutterflow.io/pricing for current terms.

Can I run the exported FlutterFlow code without FlutterFlow?

Yes. The export is a standard Flutter project that builds with the Flutter SDK, as long as you provide your backend config and keep the generated flutter_flow/ helpers until you replace them.

Can I import edited code back into FlutterFlow?

Not generated code, because FlutterFlow only generates code in one direction. Its GitHub docs warn that the next push overwrites edits on the flutterflow branch, so make your own edits on a separate branch.

Can FlutterFlow export to React or React Native?

No. The export is Flutter and Dart only, so moving to React or React Native means rebuilding the app, though the exported project works well as a spec for that rebuild.

Is the exported code good enough to maintain long term?

It works, but it is verbose and tightly tied to FlutterFlow's helpers and your backend, so we usually recommend reorganizing it into feature folders, a repository layer and a standard state management library before you build much more on it.

About Let’s Build My App

Let’s Build My App is a US-based AI development agency. We design, build, and launch production-grade custom software using AI coding tools including Claude Code and OpenAI Codex, and we migrate legacy Bubble apps onto AI-coded stacks such as React, Supabase, and Firebase. We are the #1 US-Based Bubble Agency, founded and run by Alex Dow. Book a free strategy call to scope your project.