FlutterFlow: o que é, quanto custa e o código que a empresa leva

O FlutterFlow aparece em quase toda conversa sobre app sob medida com prazo curto. A promessa é boa: construir visualmente, como num no-code, e ainda assim sair com código Flutter de verdade, sem ficar preso à plataforma. É a frase que as escolas e as agências repetem.

A frase é verdadeira, mas incompleta. O código só sai a partir de um plano pago, o repositório que permite a um time manter o app só aparece num plano mais caro, e os dados dos usuários nunca estiveram no FlutterFlow. A seguir, o que a ferramenta é, quanto custa em 2026 e a lista do que a empresa precisa ter em mãos para que "o código é seu" seja um fato, e não uma frase de venda.

O que é o FlutterFlow?

O FlutterFlow é uma plataforma visual para criar apps móveis, web e desktop que gera, por trás das telas montadas, código no framework Flutter. Em vez de escrever cada widget à mão, quem desenvolve arrasta componentes, configura navegação, liga as telas a uma base de dados e define as ações (login, gravação, envio de notificação) por um construtor de lógica visual.

O diferencial em relação a ferramentas como Bubble ou Glide está no que sai do outro lado. Nessas, o app existe dentro da plataforma; no FlutterFlow, o projeto pode ser exportado como um projeto Flutter comum, que abre num editor de código e compila sem a ferramenta. É por isso que ele costuma ser escolhido para MVPs e apps de cliente que talvez, um dia, sejam assumidos por uma equipe de desenvolvimento.

A plataforma é um produto comercial da FlutterFlow, Inc. Na página de preços, a empresa diz ter mais de 3,3 milhões de usuários construindo na ferramenta, número declarado por ela mesma.

Flutter e FlutterFlow são a mesma coisa?

Não. Flutter é o framework: um conjunto de bibliotecas de código aberto, escrito na linguagem Dart, para criar apps que rodam em Android, iOS, web e desktop a partir de uma única base de código. O próprio site do Flutter o apresenta como mantido com o apoio do Google e aberto a todos.

FlutterFlow é a ferramenta visual que escreve código Flutter por você. A relação é parecida com a de um editor visual de sites com o HTML que ele gera: o resultado usa a tecnologia aberta, mas a ferramenta que o produz é de uma empresa e é paga a partir de certo uso. Daí vem a resposta para uma dúvida comum: o FlutterFlow não é do Google. O Flutter, sim.

Essa distinção importa para a decisão. Se a ferramenta deixar de servir, o que sobra é um projeto Flutter, que qualquer desenvolvedor Flutter consegue manter. Se a empresa não tiver baixado esse projeto, não sobra nada.

O FlutterFlow é no code ou low code?

É low code. Dá para construir um app inteiro sem escrever uma linha, mas a ferramenta foi desenhada para aceitar código: há expressões e funções personalizadas, widgets e ações escritas em Dart, e importação de APIs. Na prática, um app simples sai sem código; um app de produção quase sempre recebe algum.

Isso tem consequência no time. Ferramentas no-code puras miram quem nunca programou. O FlutterFlow rende mais nas mãos de quem entende o básico de estado, banco de dados e APIs, e rende muito mais quando há alguém que lê Flutter para resolver o que o visual não alcança. Quem compara com o custo das ferramentas no-code depois que o app funciona vai notar a diferença: aqui a conta pesa menos na plataforma e mais nas pessoas.

Quanto custa o FlutterFlow em 2026?

Os valores abaixo estão na página oficial de preços do FlutterFlow, consultada em 12 de outubro de 2026, em dólar e com cobrança mensal. A mesma página oferece cobrança anual com desconto de cerca de 25%. Preço de plataforma muda; confira antes de fechar orçamento.

Há ainda planos Enterprise e de educação, negociados à parte. Para a maioria das empresas, a escolha real fica entre Basic e Growth, e o critério não é o número de telas: é quem vai cuidar do código depois.

Para quem está no Brasil, a cobrança é em dólar no cartão internacional. O custo em reais varia com o câmbio do mês e com os impostos sobre compra no exterior, e esse número precisa entrar na planilha junto com o backend, que é cobrado separadamente.

O que significa, na prática, "o código é seu"?

A frase vem da própria empresa. Na documentação "Application Data Ownership", o FlutterFlow diz seguir o princípio "Own Your Code" e afirma que quem constrói na plataforma é dono do resultado do trabalho. É uma posição clara, melhor do que a de muitas plataformas low code, em que o app é configuração guardada no fornecedor.

Há dois detalhes nesse texto que os guias costumam pular. O primeiro: ser dono do resultado não adianta se o resultado nunca saiu da plataforma. Propriedade sem cópia é um direito que não se exerce. O segundo: o código exportado não é só código do FlutterFlow. Ele traz pacotes de terceiros, e a própria documentação recomenda seguir as práticas normais de licenciamento, porque esses pacotes podem mudar de termos.

Para um app interno, a revisão de licenças é rotina. Para um app que é o produto da empresa, vendido a clientes ou distribuído em loja, ela entra na lista de diligências, ao lado de marca e contrato com o fornecedor.

Em que plano a empresa realmente leva o código?

Há três formas de o código sair do FlutterFlow, e cada uma aparece num degrau de preço. Entender a diferença entre elas evita pagar pelo plano errado ou, pior, achar que está protegido quando não está.

1. Download do código (a partir do Basic)

É uma fotografia do projeto naquele momento: um arquivo com o projeto Flutter, que abre num editor e compila fora da plataforma. Resolve o risco de perder o app, desde que alguém baixe de novo a cada versão importante e guarde em lugar da empresa. Não resolve o histórico: cada download é uma cópia solta.

2. Integração com o GitHub (a partir do Growth)

O FlutterFlow envia o código para um repositório no GitHub, e cada envio vira um registro no histórico. É o que permite a um time de desenvolvimento acompanhar mudanças, revisar e trabalhar em paralelo. Segundo o guia oficial de integração com o GitHub, o envio vai sempre para um branch chamado flutterflow, e o que for editado à mão nele é sobrescrito no envio seguinte.

3. CLI (no Business)

A linha de comando exporta o código direto para uma pasta, inclusive de um branch específico, e aceita um arquivo .flutterflowignore com a lista de arquivos que não devem ser sobrescritos, como configurações nativas de Android e iOS, conforme a documentação da exportação pela CLI. É o recurso de quem já tem rotina de engenharia em volta do app.

Onde ficam os dados dos usuários do app?

Esta é a parte que mais surpreende quem chega ao FlutterFlow vindo de no-code: os dados não ficam nele. O FlutterFlow monta as telas e a lógica; o banco de dados, a autenticação e o armazenamento de arquivos vêm de um serviço à parte, quase sempre Firebase ou Supabase, que a ferramenta integra nativamente.

Isso é bom para a propriedade e cria uma pergunta que precisa ser feita no primeiro dia: em nome de quem está o projeto do Firebase ou do Supabase? Se a agência ou o freelancer criou na conta pessoal, com o cartão dele, os dados dos clientes da empresa moram numa conta que a empresa não controla. O código pode até estar no GitHub da empresa; sem o banco, ele abre vazio.

O backend também tem conta própria. Firebase e Supabase cobram pelo uso, em planos que não têm relação com o FlutterFlow. Orçamento que lista só a assinatura da ferramenta está incompleto.

O que acontece quando o desenvolvedor mexe no código exportado?

É aqui que muito projeto se complica sem perceber. O FlutterFlow gera o código a partir do projeto visual; se alguém edita o código gerado e, depois, a equipe volta a mexer no visual e exporta de novo, a edição manual pode ser apagada.

O próprio FlutterFlow descreve o caminho para evitar isso. No GitHub, o código da ferramenta chega no branch flutterflow; o código personalizado vive num branch separado, como develop; cada atualização vinda da ferramenta entra por pull request, com os conflitos resolvidos por alguém que lê Flutter; e o que vai para produção sai do main. Na exportação pela CLI, o .flutterflowignore protege os arquivos que foram ajustados à mão.

No FlutterFlow, o código é seu desde o primeiro clique. A cópia dele, o repositório e o banco só passam a ser seus quando alguém providencia.

A consequência prática: o FlutterFlow funciona muito bem enquanto o visual é a fonte da verdade, e funciona bem também quando a equipe assume o código de vez. O meio-termo, metade no visual e metade à mão sem um fluxo de branches, é onde o retrabalho aparece.

Quando o FlutterFlow faz sentido, e quando não faz?

A pergunta "vale a pena usar o FlutterFlow?" só tem resposta quando se compara com as alternativas reais: uma ferramenta no-code pura ou um desenvolvimento tradicional em Flutter ou nativo.

O FlutterFlow tende a ser a melhor escolha quando o app precisa estar nas lojas, o prazo é curto e existe um horizonte em que um time vai assumir o código. Tende a não ser quando ninguém da empresa ou do fornecedor lê Flutter (o primeiro problema fora do visual vira bloqueio), ou quando o app é o coração do negócio, com regras tão particulares que a maior parte seria escrita à mão de qualquer jeito. Para apps internos de processo, plataformas do ecossistema que a empresa já usa costumam render mais, com as ressalvas que discutimos em as três saídas do low code que ninguém desenha.

Na consultoria de low-code e no-code da Alliance, a escolha da ferramenta vem depois de três perguntas: quem vai manter, onde os dados vão morar e qual é o plano se a ferramenta deixar de servir.

Quais os erros mais comuns ao contratar um app em FlutterFlow?

• Ficar no Free "até lançar". O app é construído inteiro num plano sem download de código e, no dia em que se pensa em sair, não há nada para levar.
• Deixar o projeto na conta do fornecedor. Projeto do FlutterFlow, repositório e backend criados no nome da agência. O contrato diz que o código é da empresa; na prática, a empresa precisa pedir.
• Contar só a assinatura no orçamento. Firebase ou Supabase, contas de desenvolvedor das lojas e o tempo de quem mantém o app ficam de fora e aparecem depois.
• Editar o código gerado no branch errado. A próxima exportação apaga o ajuste, e o problema volta sem que ninguém entenda por quê.
• Tratar o código exportado como livre de licenças. Os pacotes de terceiros têm termos próprios, e a documentação do FlutterFlow avisa que eles podem mudar.

Como medir se o app está realmente sob controle da empresa?

Propriedade se verifica, não se presume. Quatro indicadores simples resolvem:

1. Data do último código exportado, ou do último envio ao repositório, comparada com a data da última versão publicada nas lojas.
2. Número de pessoas da empresa com acesso de administrador ao projeto do FlutterFlow, ao repositório e ao backend (o mínimo saudável é duas).
3. Se o projeto exportado compila numa máquina que não é a do fornecedor, testado ao menos uma vez por semestre.
4. Lista de pacotes de terceiros do projeto com a licença de cada um, revisada a cada atualização grande.

Por onde começar hoje

Se o app ainda não existe, defina o plano pela pergunta "quem vai manter o código", não pelo número de telas. Se já existe, use o checklist abaixo como auditoria.

1. Confirme em que plano o projeto está e se ele permite baixar o código; se for o Free, a primeira decisão é subir de plano antes de investir mais horas.
2. Crie o repositório na conta GitHub da empresa e dê acesso ao fornecedor, não o contrário. Se a equipe vai manter código à mão, adote o fluxo de branches que o FlutterFlow documenta.
3. Transfira, ou crie, o projeto do Firebase ou do Supabase na conta da empresa, com pelo menos duas pessoas como administradoras.
4. Baixe o código, guarde junto com a documentação do app e peça a alguém de fora do fornecedor para compilá-lo uma vez.
5. Monte a lista de pacotes de terceiros e licenças, e coloque a revisão no checklist de cada versão.

O app em FlutterFlow é uma peça da operação, não um projeto isolado. Se a dúvida é onde ele se encaixa na estratégia digital da empresa, o diagnóstico de marketing gratuito da Alliance mostra em que ponto tecnologia e automação estão travando o resultado, e por onde vale começar.