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.
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. 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 que alimentam o total do mês, e o FAQ de preços 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 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.
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.
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