Migrar do Bubble para código: como decidir
Migre do Bubble para código próprio quando a plataforma começa a decidir o que deveria ser seu: quanto o app custa para rodar, quando ele sai do ar e com que velocidade você consegue mudá-lo. O gatilho não é decepção com o Bubble. É o ponto em que a sua regra de negócio cresceu além de um runtime que você não controla.
Quando é hora de sair do Bubble?
Quando a plataforma passa a tomar decisões que são suas. O Bubble é bom no que se propõe, e a maior parte dos apps que saem dele não deveria ter saído antes. A pergunta não é se a ferramenta é boa. É se você ainda controla as variáveis das quais o negócio depende.
Três sinais importam, e só um deles é sobre dinheiro.
O primeiro é o trabalho medido. O Bubble cobra atividade de servidor em unidades de workload, e o FAQ de preços fixa a taxa base de excedente em US$ 0,30 por 1.000 unidades para quem não tem assinatura de tier. Isolado, é uma linha de custo. Vira problema porque o consumo acompanha como o app foi construído, e não quanto ele fatura: um workflow ineficiente vira conta recorrente em silêncio.
O segundo é mais duro e está na mesma página. Com o overage desligado, ao atingir o limite o Bubble informa que o app é tirado do ar e volta no início do próximo ciclo de cobrança. Disponibilidade vira função de uma configuração de cobrança.
O terceiro não tem número. É o momento em que o time para de propor mudanças porque mudar qualquer coisa ficou caro ou arriscado. Esse costuma chegar antes dos outros dois e ser percebido depois.
O que o Bubble deixa você levar?
Dados, sim. Design, em parte. Lógica, não. O Bubble é incomumente claro nisso, e ler a documentação vale mais do que o folclore sobre aprisionamento.
Sobre posse, o Bubble afirma que você é dono dos seus dados, incluindo o design do app e o que seus usuários subiram, enquanto o Bubble mantém a posse do código que faz o app funcionar. Sobre exportação, a mesma página é direta: apps do Bubble rodam só na plataforma do Bubble, e não há como exportar a aplicação como código. Para os dados, ela documenta exportação automática em CSV e a API do Bubble para acesso via script. E diz que a empresa ajuda a exportar o design e fará o possível para ajudar quem quiser sair.
Existe até uma salvaguarda que quase ninguém lê: se o Bubble encerrasse as operações, o código-fonte seria liberado sob licença aberta, para que os apps continuassem rodando em servidor Bubble auto-hospedado.
Então o enquadramento honesto é mais simples que a história de terror. Um runtime que você não escreveu é um runtime que você não leva embora. Toda plataforma dessa categoria funciona assim. O que separa uma migração fácil de uma difícil é quanta regra de negócio você colocou lá dentro.
O que realmente encarece a reconstrução?
A lógica, não as telas. Contagem de tela é o número que os times usam porque é visível, e é o número que engana.
Faça o inventário de quatro coisas: workflows e seus desvios, conexões com APIs externas, tipos de dado com seus relacionamentos, e regras de permissão por papel. Essa lista é a área real do projeto, e costuma ser bem menor do que a contagem de telas sugere, porque boa parte das telas é variação das mesmas poucas operações.
É também a hora de decidir o que não reconstruir. Sistema que cresceu dentro de editor visual acumula workflow que existe porque alguém precisou uma vez. Migrar é a licença rara para apagar, e apagar é o trabalho mais barato do projeto inteiro.
Uma ressalva sobre consumo: o Bubble rastreia doze tipos de atividade que alimentam o total do mês, e a mesma funcionalidade consome de formas bem diferentes dependendo de como foi construída. Parte da sua conta é arquitetura, não destino, o que significa que parte da pressão para migrar pode ser aliviada antes da migração.
Como mudar sem parar a operação?
Em sequência, e acertar a ordem importa mais do que qual stack você escolhe no fim.
Exporte e modele os dados primeiro. O CSV e a API entregam os registros, mas registro não é esquema. O que chega é a estrutura de dados do Bubble, e reconstruí-la igual importa as restrições das quais você queria escapar. Três perguntas separam o modelo real dos seus acidentes. Quais campos existem porque o negócio precisa, e quais existem porque algum workflow precisava de um lugar para guardar um valor? Quais listas deveriam ser relacionamentos? Quais option sets viraram, na prática, uma tabela?
Depois reconstrua a lógica contra o inventário e rode os dois sistemas em paralelo sobre trabalho real antes de virar a chave. O paralelo só paga o próprio custo quando você compara saídas: pegue os números em que o negócio já confia, aqueles de um relatório que alguém lê toda semana, e concilie entre os dois sistemas até baterem. As divergências são a especificação que ninguém escreveu.
Dois casos nossos mostram formatos diferentes disso. Na plataforma da Colo Saúde o primeiro movimento foi ficar: o app foi estabilizado no Bubble e teve o consumo cortado em 60%, e só então começou a reconstrução em Next.js e Supabase. No sistema da UniTrust o trabalho foi na direção de um sistema construído para sustentar a operação de uma corretora de seguros nos Estados Unidos. O que decidiu cada caminho foi fôlego: quanto tempo a operação aguentava enquanto a reconstrução acontecia.
O que você perde ao sair?
Velocidade de mudança, pelo menos no começo. No Bubble, uma edição pequena leva minutos. Num sistema próprio, ela passa por um desenvolvedor e por um release. Quem disser o contrário está vendendo alguma coisa.
Você também abre mão de uma hospedagem que outro mantém e assume decisões de infraestrutura que antes não precisava tomar. Isso é custo real e entra na comparação com honestidade.
O que volta para você é o controle das três variáveis lá de cima: quanto custa rodar, se fica no ar e até onde dá para crescer. Para um app que ainda está descobrindo o próprio formato, essa troca costuma ser ruim. Para uma operação da qual um negócio já depende, costuma não ser.
Se a dúvida ainda é anterior a essa, sobre trocar controle manual por sistema, o caminho começa em quando trocar planilhas por um sistema interno.
Perguntas frequentes
Dá para exportar o código-fonte do meu app no Bubble?
Não. A documentação do Bubble afirma que os apps rodam apenas na plataforma e que não há como exportar a aplicação como código. Você exporta seus dados, e o Bubble oferece ajuda para exportar o design, mas a lógica é reconstruída.
Migrar significa reescrever tudo de uma vez?
Não, e fazer assim é o erro mais comum. Reconstrua a lógica contra um inventário, rode o sistema novo em paralelo com o antigo sobre trabalho real, e vire a chave por workflow, não pelo app inteiro.
Devo consertar o app no Bubble antes ou já sair?
Muitas vezes vale consertar antes. Se a pressão é custo de workload e o app foi construído de forma ineficiente, parte dessa conta é arquitetura e não plataforma. Estabilizar compra fôlego, e é o fôlego que decide se a reconstrução vai ser calma ou apressada.
O próximo passo
Se você está pesando essa decisão e quer uma segunda leitura do seu próprio inventário antes de fechar um plano, o Diagnóstico de Arquitetura Operacional é uma conversa de 30 minutos para percorrer isso com você. Agende uma conversa.
Leia também
Cases relacionados
Reconheceu a sua operação neste artigo?
Agende o Diagnóstico de Arquitetura Operacional: 30 minutos para mapear onde está o gargalo da sua operação. Sem compromisso.
Agendar diagnóstico