Checklist de produção SaaS:14 verificações antes de lançar
Checklist de produção SaaS: 14 verificações técnicas (SSL, backups, regras de segurança, chaves secretas, rollback) antes de os usuários reais chegarem.
Antes de o seu SaaS entrar no ar, rode um checklist de produção SaaS: regras de segurança ativadas e testadas em todas as tabelas do banco de dados, chaves secretas fora do código, SSL ativo, backups verificados e um rollback que você realmente ensaiou. O marketing de lançamento leva toda a atenção — mas são as verificações sem glamour antes de entrar no ar que decidem se seus primeiros usuários reais vão encontrar um produto funcionando ou um vazamento de dados.
Esta é a metade técnica do lançamento. A metade de marketing — o anúncio, os canais, o embalo — está no roteiro da semana de lançamento. Hoje o assunto é garantir que aquilo que você está anunciando não caia.
Por que você precisa de um checklist de produção
Seu produto viveu até agora num mundo tolerante: um banco de dados de desenvolvimento que você pode apagar e reconstruir, regras de segurança aplicadas sem rigor, mensagens de erro detalhadas, nenhum dado real de usuário em jogo. Produção é o mundo oposto — pessoas reais, dados reais, segurança rigorosa e nenhuma segunda chance para uma chave vazada ou um banco de dados perdido.
O perigo é que um app pode parecer pronto e estar a uma caixinha não marcada do desastre. Tudo nesta lista é invisível numa demo. Tudo nesta lista é questão de sobrevivência em produção.
O checklist de produção SaaS em 14 pontos
Este é o checklist que eu rodo antes de qualquer produto entrar no ar, traduzido para linguagem simples:
| # | Verificação | Por que importa |
|---|---|---|
| 1 | Todas as migrations do banco de dados rodaram com sucesso | O esquema de produção bate com o que o app espera — nada de tabelas faltando no primeiro dia |
| 2 | Row Level Security ativado em todas as tabelas | O próprio banco de dados se recusa a entregar os dados de um cliente para outro |
| 3 | Políticas de segurança testadas, não só escritas | Uma política que existe mas está errada parece idêntica a uma certa — até o vazamento |
| 4 | Índices criados para performance | Consultas que pareciam instantâneas com 10 linhas de teste se arrastam com 10.000 reais |
| 5 | Autenticação configurada para o seu domínio oficial | Links de cadastro e de redefinição de senha precisam apontar para o seu site real |
| 6 | Buckets de armazenamento de arquivos criados com políticas de acesso | Os uploads funcionam — e cada usuário só consegue ler os próprios arquivos |
| 7 | Funções do lado do servidor publicadas | A lógica de backend existe mesmo em produção, não só na sua máquina |
| 8 | Segredos configurados para essas funções | Chaves de terceiros ficam em configurações protegidas, nunca no código |
| 9 | Templates de e-mail personalizados | E-mails de confirmação e de redefinição levam a sua marca, não um padrão genérico |
| 10 | Rate limiting configurado | Um único script abusivo não consegue martelar seu login nem inflar sua conta |
| 11 | Backups verificados e rodando | Backups diários automáticos existem — confirmados, não presumidos |
| 12 | Alertas de monitoramento ativados | Você fica sabendo de picos de erro e consultas lentas antes de os usuários te mandarem e-mail |
| 13 | Connection pooling, se necessário | Muitos usuários ao mesmo tempo não esgotam as conexões do seu banco de dados |
| 14 | Chaves de API guardadas com segurança — nunca no código | Uma chave no seu repositório é uma chave na internet |
Cada verificação é uma pergunta que você pode fazer à IA: "Mostre que o Row Level Security está ativado em todas as tabelas e liste as tabelas onde ele não está." Você não precisa saber consertar cada item à mão. Precisa se recusar a lançar até que todas as respostas sejam sim.
12 semanasA sua carreira corporativa nunca foi o planoCandidate-se à Aceleradora de EUpreendedores.Candidatar-se →As três verificações que os fundadores mais pulam
Row Level Security (verificações 2 e 3). É o muro entre os dados dos seus clientes — o banco de dados se recusando, no próprio nível, a entregar os registros do usuário A para o usuário B. É a verificação com a pior forma de falhar, e por isso tem um guia só para ela. Ativado não basta; teste tentando ler os dados de outra conta e confirmando que não consegue.
Chaves secretas (verificações 8 e 14). Seu app tem chaves públicas (seguras no navegador) e chaves secretas (acesso total a tudo). As secretas pertencem às configurações protegidas do seu provedor de hospedagem. Se uma chave secreta já foi escrita no seu código alguma vez, considere-a comprometida e troque-a antes do lançamento.
O ensaio de rollback. Não está na lista acima porque é um treino, não uma configuração: publique e depois pratique voltar para a versão anterior pelo painel da sua hospedagem. Leva uns 30 segundos, sem nenhum tempo fora do ar — mas só parece uma rede de proteção depois que você já fez. Esse ensaio também é a base de publicar sem medo depois do lançamento.
Verificações do lado da hospedagem: domínio, SSL, ambiente
Do lado da hospedagem, quatro itens fecham a entrada no ar. Seu domínio próprio está conectado — mudanças de DNS levam de 10 a 30 minutos para se propagar. O SSL está ativo, e sua hospedagem emite de graça e automaticamente em 5 a 10 minutos; nenhum usuário deveria ver um aviso de "não seguro". As variáveis de ambiente de produção estão configuradas no painel com valores reais, separadas de quaisquer valores de staging. E o rastreamento de erros e o analytics estão ligados, para que desde o primeiro usuário você veja o que quebra e o que é usado — o mesmo encanamento por trás de monitorar seu SaaS como fundador solo.
Backups e recuperação: imagine o pior uma vez
No plano gratuito de uma plataforma como o Supabase, os backups rodam diariamente e ficam guardados por 7 dias. O plano Pro (US$ 25/mês) amplia a retenção para 30 dias e acrescenta recuperação a um ponto no tempo — restaurar seu banco de dados para qualquer momento, como cinco minutos antes de uma mudança ruim. Tire dez minutos para escrever seu plano de recuperação enquanto está calmo: banco de dados corrompido → restaurar o último backup e verificar. Parece paranoia até o dia em que parece genialidade.
Quanto tudo isso custa: normalmente nada
A parte tranquilizadora. Os planos gratuitos são de nível de produção de verdade: a minha própria estrutura roda 3 sites em produção com 300 a 500 builds e 50 a 100 GB de banda por mês — por R$ 0 de hospedagem. Os sinais de que você passou do gratuito são concretos: um banco de dados acima de 500 MB, banda acima de 5 GB/mês ou a vontade de ter retenção de backup mais longa — e aí são US$ 25/mês. Para a maioria dos produtos solo, o plano gratuito te leva por meses ou anos. O checklist custa uma tarde. Pular pode custar o negócio.
O livroA Revolução do EUpreendedorLuis Gonçalves sobre como construir um negócio de EUpreendedor com IA sem largar o emprego.Quero o livro →Perguntas frequentes
O que devo verificar antes de lançar um SaaS?
Catorze itens técnicos em cinco áreas: banco de dados (migrations rodadas, Row Level Security ativado e testado, índices criados), autenticação (configurada para o seu domínio oficial, e-mails com a sua marca), segurança (chaves secretas fora do código, rate limiting), resiliência (backups verificados, um rollback de 30 segundos ensaiado) e visibilidade (rastreamento de erros e alertas de monitoramento ligados).
Preciso de um plano pago para entrar no ar?
Normalmente não. Os planos gratuitos são de nível de produção: banda ilimitada do lado da hospedagem, backups diários com retenção de 7 dias do lado do banco de dados. Passe para o plano de banco de dados de US$ 25/mês quando ultrapassar 500 MB de dados ou quiser retenção de 30 dias com recuperação a um ponto no tempo. Meus três sites em produção rodam com R$ 0 de hospedagem.
Qual é a verificação mais esquecida?
Testar o Row Level Security — não só ativá-lo. Os fundadores ligam, não veem nenhum erro e lançam. Mas uma política errada se comporta exatamente como uma certa até alguém ler os dados de outro cliente. Antes do lançamento, tente ativamente acessar dados entre contas e confirme que o banco de dados recusa.
Como funcionam os backups para um fundador solo?
Automaticamente, depois de verificados. Plataformas gerenciadas fazem backup do seu banco de dados todo dia sem nenhuma configuração — retenção de 7 dias no gratuito, 30 dias mais recuperação a um ponto no tempo no plano de US$ 25/mês. Seu trabalho tem duas partes: confirmar que os backups estão rodando de fato antes do lançamento e escrever o procedimento de restauração enquanto nada está pegando fogo.
Quão preso você está, de verdade?
Faça o Índice de Sufocamento Corporativo, a avaliação gratuita para saber se você está pronto para ser um EUpreendedor.