← todos os posts
Manutenção 9 min de leitura

O segundo mês do app é mais difícil que o primeiro

Base vazia, um usuário só, nenhum dado velho: o mês 1 foi o mais fácil da vida do app. Este é o mapa do que aparece no mês 2, e o que segura cada um.

"Eu simplesmente não consigo, parece que fica algo remendado, como se fosse uma pintura com 3 estilos diferentes."

É de um brasileiro num fórum, descrevendo o próprio app depois de algumas semanas de uso. E tem uma segunda fala, de alguém que foi contratado pra consertar um sistema feito assim:

"Agora o difícil é decidir se teria sido mais barato e melhor fazer certo do início ou se é mais barato fazer o lixo e depois arrumar."

Guarde essa pergunta. Volto nela no fim, porque ela está mal formulada — e a formulação errada é o que faz muita gente parar.

O mês 1 foi o mais fácil da vida do seu app

Não é força de expressão. No primeiro mês, todas as condições estavam a seu favor de um jeito que não se repete:

  • A base estava vazia. Deu ruim? Apaga tudo e começa de novo.
  • Só existia um usuário: você. Todo dado era seu, então nunca deu pra errar de dono.
  • Não havia dado velho. Toda informação tinha sido criada sob a regra que valia naquele instante.
  • Ninguém esperava nada. Ficar fora do ar meia hora não custava nada, porque não tinha ninguém do outro lado.

Repare que nenhuma dessas quatro é qualidade do seu app. São condições temporárias, e todas vencem no mesmo dia: aquele em que a primeira pessoa de verdade começa a usar.

"Manutenção" é só isto — o trabalho que aparece quando essas quatro acabam. Uma parede por vez.

Parede 1: mudar o formato de dados que já existem

Você decide que o cadastro agora precisa de telefone. No mês 1, é um pedido de trinta segundos. No mês 3, com 300 cadastros feitos sem telefone, é outra coisa.

Essa outra coisa tem nome: migração — mudar o formato dos dados que já estão lá dentro sem perder nenhum.

E a IA se atrapalha aqui de um jeito previsível: no mês 1, a solução mais simples pra "mudar a estrutura" era apagar a tabela e criar de novo. Continua sendo a primeira saída que ela enxerga — só que agora leva os seus 300 cadastros junto.

O procedimento em quatro passos

Não é técnico, é de contabilidade — dá pra conduzir sem entender uma linha de código.

1. Conte antes. Peça o número, anote num papel:

"Quantos registros existem hoje na tabela de clientes? Desses, quantos estão sem telefone preenchido? Só me responda os dois números, não mexa em nada."

2. Faça em duas etapas, nunca em uma. Primeiro o campo entra podendo ficar vazio, e o app passa a preenchê-lo pra quem chega. Só depois, com os antigos resolvidos, ele vira obrigatório. Uma etapa só é o que quebra o app pra quem já existia.

3. Confira a contagem. Conte de novo, no mesmo formato do passo 1. É a conferência de contagem: os números têm que bater antes de qualquer coisa ser apagada.

4. Só então aperte a regra. Tornar obrigatório é o último passo, não o primeiro.

E uma regra que vale mais que as quatro juntas: nunca peça migração e funcionalidade nova no mesmo pedido. Se quebrar, você precisa saber se foi o dado ou a tela.

A documentação do Supabase é categórica: nunca altere o banco de produção direto — toda mudança de estrutura, "mesmo as pequenas", deve passar por um arquivo de migração. O porquê: arquivo tem nome, pode ser repetido num ambiente de teste e pode ser desfeito. Comando digitado no painel é evento único, que ninguém reproduz nem reverte.

Parede 2: o serviço externo mudou, e o calendário não é seu

Seu app conversa com coisas que não são suas: o serviço de e-mail, o de pagamento, o de mensagem, o login pelo Google. Cada um tem calendário próprio — publicado, com data — e ninguém te avisa em português.

Um exemplo verificável: a Meta publica a data de validade de cada versão da interface que os apps usam pra falar com o Facebook e o WhatsApp. A versão 20.0 sai do ar em 24 de setembro de 2026 — está numa tabela pública há dois anos. Quem não olhou vai descobrir pelo app parando.

E tem a parte que não está em calendário nenhum: a plataforma de terceiro tem regra própria, e ela não mora no seu código. Um brasileiro de 15 anos escreveu num fórum, sobre o próprio sistema de automação para corretores:

"Tentamos enviar 500 mensagens. O WhatsApp restringiu a conta em 3 horas."

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

É um relato, não uma estatística — mas é exatamente a forma da coisa. O código estava certo; a regra de uso é que não. E a punição atingiu um dado que nem estava no banco dele.

O que fazer hoje, em quinze minutos: uma folha com cada serviço externo que o app usa e, ao lado, três colunas — em qual conta ele está, qual e-mail recebe os avisos dele, e se existe versão com prazo. A do meio é a que salva: aviso de descontinuação chega por e-mail, quase sempre no endereço que ninguém lê.

Parede 3: agora existe gente que já estava lá

Do mês 2 em diante, toda mudança tem duas perguntas, não uma:

  1. O que acontece com quem chega hoje?
  2. O que acontece com quem já estava aqui ontem?

A segunda ninguém faz, e é a origem de quase todo "quebrou pra alguns clientes e pra mim não". Campo que virou obrigatório, plano que mudou de nome, funcionalidade que saiu: cada uma é inofensiva pra conta nova e potencialmente fatal pra conta antiga.

A defesa é simples e quase ninguém faz: mantenha uma conta fóssil. Uma conta de teste criada lá no começo, com dado bagunçado de verdade — cadastro incompleto, pedido com valor zero, o cliente que você digitou errado. Nunca limpe essa conta. É nela que você testa depois de cada mudança, junto com uma conta criada na hora.

Conta nova sempre funciona. É a conta velha que te conta a verdade.

Parede 4: o dado velho que não encaixa na regra nova

Todo app tem cinco registros esquisitos: o cadastro sem sobrenome, o CPF digitado errado, o cliente duplicado. No mês 1 você apagava e pronto. No mês 6, um deles pertence a um cliente pagante, e apagar é destruir informação de alguém.

Então, antes de apertar qualquer regra, faça uma pergunta só:

"Quantos registros que já existem violariam essa regra nova? Liste os casos, não altere nada."

E decida você o que fazer com eles: manter, corrigir na mão, marcar como antigo. É decisão de negócio, não técnica — não delegue. Apagar é a saída mais fácil que a IA enxerga, e a única que não tem volta.

Sobre a pintura com três estilos

Falta explicar por que o app fica remendado, e a explicação tira um peso das suas costas.

Um estudo de 2026 — o VibeApps, que montou um acervo de mais de dez mil aplicações feitas com IA — descreve oito modos de falha recorrentes e os atribui a três limitações sistemáticas dos agentes: defeitos de memória, de objetivo e de conhecimento. E conclui que prompt melhor e agente melhor não eliminam isso.

Esse estudo mede segurança em aplicações de código aberto publicadas, não o seu app, e não fala de estilo visual. Mas o defeito de memória é literalmente a sua pintura de três estilos: a IA não lembra do que decidiu com você em março. Cada sessão começa do zero e resolve o problema da frente, do jeito que parece melhor naquela conversa. Três sessões, três decisões diferentes sobre a mesma coisa.

O antídoto não é técnico. É um arquivo curto que eu chamo de livro de regras do app, colado no começo de toda sessão nova:

LIVRO DE REGRAS — meu app
- Moeda: real. Valores guardados em centavos, inteiros.
- Fuso: São Paulo. Toda data mostrada em dd/mm/aaaa.
- Quem pode o quê: cliente vê só o que é dele; admin vê tudo.
- Nomes que eu uso: "pedido" (não "ordem"), "profissional" (não "prestador").
- Nunca apagar registro de cliente. Marcar como inativo.
- Todo dinheiro aparece com o símbolo R$ e duas casas.
- Antes de mudar estrutura de dados: me perguntar primeiro.

Não é documentação de programador — documentação se escreve depois, pra explicar o que foi feito. Isso é o contrário: é o que você diz antes, pra que o que vier construído já nasça do mesmo lado. Cinco minutos, e resolve mais inconsistência que qualquer pedido de "padronize o app".

De volta à pergunta do sujeito que foi contratado

"Teria sido mais barato fazer certo do início, ou é mais barato fazer o lixo e depois arrumar?"

A pergunta está mal posta, e o motivo é este: começar rápido não é o que encarece. Ninguém sabe o que é "certo" antes de ter cliente usando — o app que nasce arquitetado com esmero e sem usuário é o mais caro de todos, porque custa tudo e não entrega nada.

O que encarece é começar rápido e não registrar nada: nenhuma decisão anotada, nenhuma contagem antes de mexer, nenhuma conta velha guardada. Aí o mês 6 vira arqueologia — alguém pago por hora tentando adivinhar o que você quis dizer em março.

A saída não é fazer certo desde o início. É fazer rápido e anotar, e as anotações deste post inteiro cabem em duas folhas.

Seu app não é um projeto que termina. É uma coisa viva, e coisa viva precisa de rotina, não de heroísmo. Quem entende isso no mês 1 sofre muito menos no mês 6.

E cada uma dessas quatro paredes tem vizinho — o backup que você nunca restaurou, o custo mensal que ninguém somou, a conta que está no e-mail errado. Elas têm ordem, e a ordem importa mais que qualquer uma isolada.

Fontes