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

Rotina de manutenção de 20 minutos por semana pra app pequeno

"Erro no log, custo do mês, backup, alerta de dependência e um teste rodado: cinco conferências semanais, onde clicar em cada uma e o que anotar."

"O sistema me atende bem para a demanda atual."

É de um brasileiro que montou, em uma semana, um sistema pra própria assistência técnica de celulares, e contou num fórum. Eu gosto dessa frase porque ela é o lado bom de tudo que este blog discute: alguém que não programa fez o software que queria, e ele funciona.

A pergunta que vem depois é como continuar funcionando no mês seis. E a resposta não é heroísmo. É uma rotina chata, curta e fixa.

Por que o app "do nada" quebra

Não é do nada. App parado no ar continua mudando por fora: o serviço de e-mail chega no limite, uma peça pronta que o código usa ganha um alerta de segurança, o backup para de rodar porque o cartão venceu. Nada disso dá sinal na tela. O segundo mês do app é cheio dessas paredes, e todas têm uma coisa em comum: dão aviso antes, num lugar onde ninguém olha.

A rotina é só ir olhar. Toda semana, no mesmo dia, na mesma ordem. Eu faço na segunda de manhã, antes de abrir qualquer pedido novo pra IA.

O checklist

1. Erro no log (6 minutos)

Log é o diário que o app escreve sozinho: cada pedido que chegou, cada erro que deu. O cliente que viu erro e desistiu deixou rastro ali, mesmo sem te avisar.

  • Lovable Cloud: More → Cloud → Logs. Use o filtro de status pra ver só os erros. A janela vai de 15 minutos até os últimos 5 dias.
  • Supabase: o menu Logs do painel do projeto. O quanto ele guarda depende do plano: pela página de preços, 1 dia no grátis, 7 no Pro.
  • Vercel: Logs, na barra lateral do projeto. A documentação dá 1 hora de log no plano grátis (Hobby) e 1 dia no Pro.

Repare no problema: em vários planos grátis, o log semanal não existe, porque ele apaga antes da semana acabar. Então no grátis o item muda: você olha o que tiver (o último dia, a última hora) e, se der zero erro, não comemore, desconfie da janela. Se o app já tem cliente, esse é um bom motivo pra sair do grátis.

O que anotar: quantos erros, e o que mais se repete. Um erro repetido vinte vezes é um pedido pra IA; dá pra colar a linha do log na conversa, como a própria documentação do Lovable sugere. Mas não hoje: hoje é só anotar.

2. Custo do mês (3 minutos)

Abra a folha de seis linhas e o painel de uso de cada serviço. A pergunta é uma só: algum número subiu sem ter entrado cliente novo? Se sim, alguma coisa está rodando à toa, e é mais barato descobrir na semana 1 do que na fatura.

3. Backup conferido (3 minutos)

Toda semana, só uma conferência: existe uma cópia desta semana? No Supabase pago, Database → Backups → Scheduled tem que mostrar a data de ontem. No plano grátis não tem backup automático nenhum, então o item vira exportar a tabela principal em CSV (arquivo de planilha) e guardar fora. Uma vez por mês, troque a conferência pelo exercício de restaurar, que é o único que prova que a cópia abre.

4. Dependência: tem alerta? (3 minutos)

Dependência é peça pronta, escrita por outra pessoa, que o seu código usa: o pedaço que desenha o calendário, o que manda o e-mail. Seu app tem dezenas. De vez em quando, alguém descobre um furo de segurança numa delas.

A regra aqui é contraintuitiva: não atualize por atualizar. Atualização sem motivo é mudança sem pedido, e mudança sem pedido quebra coisa. O que você confere é se existe alerta.

Se o código está no GitHub, a documentação dele descreve os Dependabot alerts: avisos que apontam peças com falha conhecida. Pra ligar num repositório privado, Settings → Advanced Security → Dependabot alerts → Enable. Os avisos aparecem na aba de segurança do repositório.

Se tiver alerta: um por pedido, com ponto de retorno antes e teste depois. E nunca o comando que o terminal sugere com --force no fim, que troca versão sem perguntar. Se o código ainda só existe dentro do Lovable, anote "sem repositório" e siga. É um item que fica cinza, não verde.

5. Um teste rodado (5 minutos)

Rode o teste de 5 cliques na conta de teste mais velha que você tiver, aquela com dado bagunçado. Conta nova sempre funciona; é a velha que te conta a verdade. Se você já tem teste automático, o item é rodar o comando e ler o resultado.

A folha

Uma linha por semana. Papel ou planilha:

DATA     | ERROS (qtd / o que mais repete) | CUSTO SUBIU? | BACKUP DA SEMANA? | ALERTA? | TESTE OK?
20/10/26 | 3 / "email não enviado"         | não          | sim               | 0       | sim

Duas regras de uso. Primeira: a rotina só olha, não conserta. O que aparecer vira pedido separado, depois, um de cada vez. Rotina que vira sessão de conserto passa de 20 minutos pra três horas e você para de fazer na terceira semana. Segunda: o valor está na coluna repetida. Um erro que aparece em três segundas seguidas é o seu próximo pedido, e você sabe disso sem adivinhar.

Era a parte "operar"

Essa folha é o O final do jeito que eu trabalho: operar, manter vivo. Ela diz que algo está errado. Não diz o que fazer quando o item 5 falha numa sexta à noite, isso tem roteiro próprio. E não substitui as fundações que ela pressupõe: um banco que é seu, um ponto de retorno, uma conta velha guardada. Sem elas, metade das colunas fica cinza.

A ordem é essa: primeiro as fundações, depois a rotina. A rotina é a parte fácil, e por isso mesmo é a que dá pra começar segunda que vem.

Fontes