# Quanto custa reconstruir um app do Bubble > Ninguém precifica uma reconstrução de Bubble olhando a tela. Veja as quatro coisas que definem o número e como compará-lo com o que ficar já custa hoje. - Autor: Marlon Trettin - Publicado: 2026-08-21 · Atualizado: 2026-08-21 - Idioma: pt-BR - Canonical: https://yowpi.com/blog/quanto-custa-reconstruir-um-app-do-bubble --- Reconstrução de app do Bubble é precificada pela lógica acumulada, não pelo app que dá para ver. Quatro coisas definem o número: quantos workflows e desvios existem, quantas integrações externas eles tocam, quão embaralhado ficou o modelo de dados e quantas regras de permissão por papel você tem. Contagem de tela quase não mexe nisso. ## TL;DR - Quem orça uma reconstrução de Bubble vendo uma gravação de tela está chutando. O preço mora no inventário de workflows, que não é visível de fora. - Contagem de tela engana. Boa parte das telas é variação das mesmas poucas operações. - A comparação que importa é contra o custo de ficar, e parte desse custo é documentada: [US$ 0,30 por 1.000 unidades de workload](https://manual.bubble.io/account-and-marketplace/account-and-billing/pricing-plans/pricing-faq) de excedente base sem tier. - Migrar é o momento mais barato para apagar o que não serve mais. Esse apagar é a maior alavanca isolada sobre o número. ## Por que ninguém te dá um número de cara? Porque o número não é conhecível de fora, e número dado sem inventário é tática de venda, não estimativa. A documentação do próprio Bubble explica o motivo. A plataforma afirma que [os apps rodam apenas na plataforma do Bubble e que não há como exportar a aplicação como código](https://manual.bubble.io/account-and-marketplace/application-and-data-ownership). Então a reconstrução não é um port. É reimplementar regra de negócio que hoje só existe dentro de um editor visual, e ninguém dimensiona isso olhando o front. Você vai achar faixas de preço publicadas por aí. Trate como orçamento de obra dado por telefone: os honestos vêm com a ressalva de que a faixa é larga demais para servir, e os confiantes são os que devem preocupar. Nós não publicamos faixa por esse motivo, e qualquer estúdio que te dê uma antes de contar os seus workflows está precificando um projeto diferente do seu. O que dá para conseguir rápido, e você deveria exigir, é o inventário. Contar é barato. Chutar é o que fica caro depois. ## O que define o preço de verdade? Quatro coisas, em ordem aproximada de peso. **Workflows e seus desvios.** Todo workflow é lógica que alguém precisa ler, entender e reescrever, incluindo os desvios que só disparam em exceção. Contagem de desvio importa mais que contagem de workflow, porque é no desvio que mora a regra de negócio não documentada. **Integrações externas.** Cada conexão de API carrega a própria autenticação, tratamento de erro, comportamento de retentativa e modos de falha. Integração também é onde o risco da migração se concentra, porque o outro lado não está nem aí para a sua reconstrução. **Complexidade do modelo de dados.** Não a quantidade de tabelas, e sim quanto do modelo é acidental. Listas que deveriam ser relacionamentos, option sets que viraram tabela, campos que existem porque algum workflow precisava guardar um valor. Desembaraçar isso é o trabalho de cauda mais longa, porque tudo o que vem depois herda a decisão. **Regras de permissão por papel.** Privacy rules são silenciosas e estruturais. São também o que tem mais chance de ser reproduzido errado, porque a intenção original quase nunca está escrita em lugar nenhum. Repare no que não está na lista. Contagem de tela, que é por onde quase todo mundo começa, vira tarefa de design depois que a lógica está resolvida, e design é barato perto de lógica que precisa ser raciocinada duas vezes. ## Como comparar com o custo de ficar? Coloque os dois na mesma linha mensal, porque reconstrução é número de uma vez e ficar é número recorrente, e comparar em unidades diferentes é como a decisão fica adiada. O custo de ficar tem uma parte documentada e uma parte que não é. A documentada é o workload: o Bubble rastreia [doze tipos de atividade](https://manual.bubble.io/help-guides/workload/understanding-workload) que alimentam o total do mês, e o [FAQ de preços](https://manual.bubble.io/account-and-marketplace/account-and-billing/pricing-plans/pricing-faq) fixa o excedente base em US$ 0,30 por 1.000 unidades sem assinatura de tier. Puxe doze meses disso e projete contra a sua curva de crescimento, não contra o uso de hoje. A parte não documentada é o que a restrição custa ao negócio: a funcionalidade que ninguém construiu porque sairia cara, a etapa que continuou manual, o relatório que é exportado e terminado numa planilha. Esse número é maior que a fatura na maior parte das operações que vemos, e não aparece em fatura nenhuma. Existe uma terceira opção que costuma ser pulada, e muitas vezes é o primeiro movimento certo. Na [plataforma da Colo Saúde](/cases/colo-saude) o app foi estabilizado no Bubble e teve o consumo cortado em 60% antes de qualquer reconstrução começar. Parte de uma conta de workload é arquitetura, não plataforma, o que significa que parte da pressão para migrar some sem migrar. Comprar fôlego assim transforma a reconstrução de emergência em plano. ## Como deixar o número menor? Apague primeiro. Sistema que cresceu dentro de editor visual acumula workflow que existe porque alguém precisou uma vez, e migração é o raro momento em que apagar é politicamente possível. Cada workflow aposentado é um que você não escopa, não constrói, não testa e não mantém. Depois sequencie por receita. Reconstruir o app inteiro antes de entregar qualquer coisa é o caminho mais caro e o de pior modo de falha. Vire a chave por workflow, começando pelos de que o negócio depende, e deixe o resto rodando onde está. Depois decida o que continua simples. Nem toda parte de uma operação merece software sob medida, e reconstrução é boa hora para perceber qual ferramenta interna poderia ser uma planilha com regra, ou ficar na plataforma indefinidamente porque funciona e ninguém mexe. Escopar contra o inventário em vez de contra as telas é o que separa projeto que aterrissa de projeto que dobra. A sequência para conduzir está em [migrar do Bubble para código](/blog/migrar-do-bubble-para-codigo). ## Perguntas frequentes **Dá para estimar minha reconstrução vendo uma demo do app?** Não com honestidade. Demo mostra as telas, e tela é a parte barata. Estimativa precisa da contagem de workflows e desvios, da lista de integrações, dos tipos de dado com seus relacionamentos e das regras de permissão por papel. Produzir esse inventário costuma levar dias, não semanas. **Reconstruir sai mais barato do que ter feito sob medida desde o início?** Em valor absoluto, normalmente não. Mas essa comparação já não está disponível para você. O que está disponível é reconstruir agora contra reconstruir depois, num tamanho maior, e depois é sempre mais caro, porque a lógica continua se acumulando enquanto a decisão não sai. **Devo consertar o app no Bubble antes?** Muitas vezes sim, e é a opção menos discutida. Se a pressão é custo de workload, parte dessa conta vem de como o app foi construído. Estabilizar compra fôlego, e é o fôlego que decide se a reconstrução acontece com calma ou sob prazo definido por uma fatura. ## O próximo passo Se você quer o inventário antes de querer um número, o Diagnóstico de Arquitetura Operacional é uma conversa de 30 minutos para mapear o que o seu app de fato contém e o que seria preciso para movê-lo. [Agende uma conversa](/contato).