← todos os posts
Dores 5 min de leitura

"O que fazer quando quebra: o plano de 1 página que todo app com gente usando precisa ter"

"Aguentar cliente não é o código nunca cair. É ter escrito, antes, o que fazer quando cai. O plano de 1 página, com 5 campos que você preenche hoje."

"Será que o que eu fiz aguenta cliente de verdade?"

Essa pergunta trava quem construiu um app, botou gente pra usar e agora vive com um medo de fundo: e se cair numa hora ruim? É a décima-quarta das paredes que esse blog mapeia, e ela não é sobre código. É sobre a noite em que algo vai dar errado — porque vai — e você vai descobrir, no susto, que não tem plano nenhum.

Aguentar cliente não é o que você pensa

A gente imagina que "aguentar cliente de verdade" é o código nunca quebrar. Não é. Todo sistema sério do mundo cai de vez em quando; o que separa o profissional do amador não é a queda, é o que acontece nos vinte minutos seguintes. E esses vinte minutos são decididos muito antes, com a cabeça fria, num papel.

Ninguém te contou isso porque todo tutorial termina no "seu app está no ar 🎉". O que vem depois — o dia em que ele sai do ar — é justamente o pedaço que dev acha óbvio demais pra escrever. Não é culpa sua não ter o plano. É que ele nunca te foi entregue.

Quando quebrar de verdade, às 23h, com o print do cliente na tela, os seis passos da noite estão aqui e são pra ler na hora. Este post é o contrário: é o que você escreve agora, com café, pra que aquela noite seja curta. Uma página. Cinco campos.

O plano de 1 página

Copie isto num bloco de notas, no papel de parede do computador, onde você vê. Preencha hoje. São cinco perguntas, e cada resposta cabe em duas linhas.

1. Quem me avisa antes do cliente?

O pior jeito de saber que o app caiu é pelo WhatsApp de um cliente irritado. O segundo pior é não saber. Toda plataforma séria tem uma página de status pública, sem login, que mostra se o problema é dela: status.lovable.dev, status.supabase.com, status.vercel.com. Essas páginas rodam num serviço chamado incident.io e têm um botão Subscribe to updates: você põe seu e-mail e recebe aviso quando elas registram uma falha. Assine as três que você usa, hoje. No campo 1 do plano, escreva: "fui avisado por quê — e-mail da plataforma? um monitor? o cliente?".

2. O que eu desligo?

Às vezes o certo não é consertar correndo. É tirar o app do ar de propósito, pra ele parar de mostrar erro ou, pior, de estragar dado, enquanto você pensa. Isso tem nome e botão em algumas plataformas. Na Vercel, dá pra pausar o projeto; quem entrar vê uma tela de erro limpa (código 503 DEPLOYMENT_PAUSED) em vez de telas quebradas, e você religa depois sem republicar. Em plataformas como a App Platform da DigitalOcean existe um "modo de manutenção" documentado, que troca o app por uma página de "voltamos já". Nem toda ferramenta de IA te dá esse botão — e se a sua não dá, o campo 2 vira "não tenho como desligar, então o plano é voltar pro ponto antigo (campo 3)". Saber disso de antemão já é meio caminho.

3. Pra onde eu volto?

Esse é o campo mais importante, e você já deve ter feito o dever de casa: o ponto de retorno, a versão que funcionava, marcada antes da última mudança. No plano, escreva o caminho exato, com as palavras que a sua plataforma usa — "History → restaurar", "Instant Rollback" — pra não precisar procurar no escuro. E um aviso que vale ouro às 23h: em várias plataformas, voltar o código não volta o banco de dados. Escreva isso no campo também, pra não ser surpresa.

4. O que eu digo pro usuário?

Escreva a frase agora, pronta pra copiar e colar. Uma coisa curta: "Oi! Vi que o sistema está com problema. Já estou olhando e te aviso em até 30 minutos." O que destrói a confiança de um cliente não é o app cair — é o silêncio depois. Ter a frase escrita antes faz você mandá-la no primeiro minuto, em vez de travar procurando palavra enquanto o relógio corre. E nunca "foi a plataforma": pro cliente, o app é seu.

5. Quando eu paro de tentar e chamo alguém?

Defina o limite antes, porque no susto a gente sempre acha que "mais uma tentativa" resolve. Um bom limite: duas rodadas de IA sem resultado, ou uma hora de relógio com gente pagante esperando, ou qualquer sinal de que o dado de cliente sumiu ou está errado. Qualquer um dos três e você para de mexer e chama um programador — com o plano preenchido na mão, que é o que transforma uma noite cobrada numa hora cobrada.

A folha

PLANO DE QUANDO QUEBRAR — meu app

1. Quem me avisa:   ____________________
2. O que eu desligo: ___________________
3. Pra onde eu volto: __________________  (o banco volta? ___)
4. Frase pro usuário: "_________________"
5. Chamo alguém quando: ________________

Cinco linhas. Uns quinze minutos pra preencher hoje, com calma. Impossível de pensar às 23h, com o cliente vendo.

Onde isso se encaixa

Esse plano é a última das perguntas do checklist que separa protótipo de produto: "você sabe o que fazer quando quebra, e está escrito em algum lugar que não seja a sua memória?". Ela vem no fim de propósito — é da fase de operar, depois de o app já ser seu, ter dado guardado e gente de fora usando. As vizinhas dela são o backup que já voltou uma vez e o custo por mês conhecido. Juntas, elas são o que faz um app aguentar cliente de verdade — não porque nunca cai, mas porque, quando cai, você já sabia o que fazer.

Fontes