← todos os posts
Segurança 5 min de leitura

"A plataforma dobrou o preço numa terça: a semana em que eu tirei um produto de lá (e o que quebrou)"

"Mudei a produção do Kallos de casa em maio de 2026. O que foi junto, o que ficou pra trás, a configuração que quase se perdeu e a lista que você faz hoje."

"O pior é que, quando tomamos o ban, perdemos todas as respostas dos leads que estavam engajando."

Quem escreveu isso no TabNews foi um rapaz de 15 anos, não programador, com um sistema de automação pra corretores. O WhatsApp restringiu a conta dele em 3 horas. O código tava inteiro. O que sumiu morava do lado de fora.

É o medo do cenário clássico: a plataforma muda o preço numa terça, e você descobre quanta coisa do seu app não tá no código.

Vou ser honesto com o título: comigo não foi preço. Foi decisão minha, sem pressa. E por isso vale contar: a lista do que quebra é a mesma. Muda quem escolhe o prazo.

O que eu mudei de casa

O Kallos é um app de gestão de salão de beleza que eu mantenho: agenda, cobrança de sinal por Pix, um robô que responde as clientes no WhatsApp. Até maio de 2026, a produção dele morava num projeto do Firebase (o serviço do Google que guarda banco, login e as funções que rodam no servidor) criado lá no começo, com um nome que não tinha nada a ver com a marca, onde teste e produção dividiam o mesmo lugar.

Pra publicar nas lojas com a estrutura definitiva, eu criei um projeto novo, só pra produção, e o antigo virou o ambiente de teste. Comecei numa quarta, 27 de maio. Terminei de conferir no sábado.

O que foi junto, e foi fácil

Tudo que estava escrito em arquivo: as regras de quem lê o quê no banco, os índices, o código das funções. Dois scripts resolveram: um publicava essas peças no projeto novo, outro copiava os 7 segredos (as senhas dos serviços ligados: WhatsApp, Instagram, a IA) de um projeto pro outro.

Os dados eu escolhi não levar. O projeto novo nasceu vazio, de propósito, porque o app ainda ia estrear nas lojas. Se você tem cliente dentro, essa escolha não existe pra você, e o trabalho dobra.

O que não estava em arquivo nenhum

A lista que eu escrevi tinha doze passos, e mais da metade era configuração feita numa tela de painel, que não mora no código:

  • O endereço do WhatsApp. A Meta manda cada mensagem das clientes pra um endereço do meu servidor, o webhook (um "me avisa aqui quando chegar mensagem"). Endereço novo exige uma verificação: a documentação da Meta diz que ela manda um pedido de teste e o servidor tem que responder com o código que ela mandou. Se eu trocasse antes de as funções estarem no ar no projeto novo, a verificação falhava.
  • Os endereços de volta do login. Instagram e Google Agenda só aceitam devolver o usuário pra endereços cadastrados. Cada um, num painel diferente.
  • O resto da lista miúda: a impressão digital do app Android (sem ela o login no celular falha), a chave de notificação do iPhone e o plano pago, obrigatório pra ter funções e segredos.

A configuração que quase se perdeu

O robô responde "recebi" pra Meta na hora e só depois pensa na resposta. A documentação do Cloud Run, o serviço do Google que roda essas funções, diz que no modo padrão o processamento "só é alocado durante o atendimento do pedido". Ou seja: o "recebi" sai e o motor quase desliga. O resultado, anotado no projeto: a cliente manda mensagem e o robô responde 5 a 10 minutos depois, em vez de 10 segundos.

A correção era um ajuste aplicado à mão, uma vez, no projeto velho. E o ajuste vale por serviço: função publicada num projeto novo nasce no padrão, sem ele.

O que me salvou foi uma nota antiga no arquivo de pendências, com o título "Config crítica (NÃO PERDER)". E mesmo ela tava desatualizada: o comando de reaplicar o ajuste apontava pro projeto antigo. Escrevi o aviso por cima dela, como primeira coisa a refazer no projeto novo.

E teve a quebra que eu não previ. No sábado, os testes automáticos que simulam o app inteiro começaram a falhar com "não encontrado". O comando que liga o simulador ainda apontava pro projeto velho. O conserto era uma palavra. Achar foi o trabalho.

A ordem que funcionou

Ligar o novo. Conferir que tá de pé (a minha lista de validação tinha um teste que imita o pedido da Meta e espera a resposta certa voltar). Só então trocar cada endereço que aponta pra ele. E não apagar o velho: tudo que fiz foi acréscimo, e voltar atrás era desfazer a troca de endereço.

Com o preço dobrado numa terça, a ordem seria a mesma. Só que com pressa e clientes dentro.

Faz hoje: a lista de quem chama o seu app

Sem migrar nada, pegue uma folha e faça três colunas:

QUEM CHAMA O MEU APP     | ENDEREÇO DE HOJE | ONDE SE MUDA
pagamento (aviso do Pix) |                  |
login com Google         |                  |
WhatsApp / e-mail        |                  |
outros                   |                  |

Pra preencher, peça à IA da sua plataforma, sem mudar nada: "Liste todo serviço externo que chama este app por um endereço (webhook, endereço de retorno de login, aviso de pagamento). Pra cada um, qual é o endereço e em que painel ele é configurado."

Confira cada linha abrindo o painel. Embaixo, anote à mão todo ajuste feito direto numa tela, que não tá no código. É essa folha que transforma uma terça de pânico numa semana de trabalho chato.

Era uma parede de várias

Essa lista cobre a troca de endereço. Ela não move banco com cliente dentro, com contagem antes e depois (os outros passos da saída estão aqui). Não troca o login sem pedir senha nova pra todo mundo. Não diz em nome de quem cada conta deve estar. Cada uma tem seu portão, nesta ordem: primeiro o que é seu, depois o que tá provado, depois o que se mantém no ar. A minha mudança levou quatro dias porque eu sabia a ordem.

Fontes