Checklist de produção SaaS:14 verificações antes de lançar
Checklist de produção SaaS: 14 verificações técnicas (SSL, cópias de segurança, regras de segurança, chaves secretas, rollback) antes dos utilizadores reais.
Antes de o teu SaaS entrar em produção, corre uma checklist de produção SaaS: regras de segurança ativadas e testadas em todas as tabelas da base de dados, chaves secretas fora do código, SSL ativo, cópias de segurança verificadas e um rollback que tenhas mesmo ensaiado. O marketing do lançamento fica com toda a atenção — mas são as verificações pouco glamorosas da entrada em produção que decidem se os teus primeiros utilizadores reais encontram um produto que funciona ou uma fuga de dados.
Esta é a metade técnica do lançamento. A metade de marketing — o anúncio, os canais, o embalo — é o manual da semana de lançamento. Hoje trata-se de garantir que aquilo que estás a anunciar não cai.
Porque é que precisas sequer de uma checklist de produção
O teu produto tem vivido num mundo tolerante: uma base de dados de desenvolvimento que podes apagar e reconstruir, regras de segurança aplicadas com pouca rigidez, mensagens de erro generosas, nenhum dado real de utilizadores em jogo. A produção é o mundo oposto — pessoas reais, dados reais, segurança rigorosa e nenhuma segunda oportunidade quando uma chave é exposta ou uma base de dados se perde.
O perigo é que uma app pode parecer terminada estando a uma caixa por assinalar de um desastre. Tudo nesta lista é invisível numa demo. Tudo isto é existencial em produção.
A checklist de produção SaaS em 14 pontos
Esta é a checklist que corro antes de qualquer produto entrar em produção, traduzida para linguagem corrente:
| # | Verificação | Porque é importante |
|---|---|---|
| 1 | Todas as migrações da base de dados correram com sucesso | O esquema de produção coincide com o que a tua app espera — nenhuma tabela em falta no primeiro dia |
| 2 | Row-level security ativada em todas as tabelas | A própria base de dados recusa-se a servir os dados de um cliente a outro |
| 3 | Políticas de segurança testadas, não apenas escritas | Uma política que existe mas está errada parece idêntica — até à fuga de dados |
| 4 | Índices criados para o desempenho | Consultas que pareciam instantâneas com 10 linhas de teste arrastam-se com 10.000 reais |
| 5 | Autenticação configurada para o teu domínio real | Os links de registo e de reposição de palavra-passe têm de apontar para o teu site real |
| 6 | Buckets de armazenamento de ficheiros criados com políticas de acesso | Os uploads funcionam — e cada utilizador só consegue ler os próprios ficheiros |
| 7 | Funções do lado do servidor publicadas | A lógica de backend existe mesmo em produção, não apenas localmente |
| 8 | Segredos definidos para essas funções | As chaves de terceiros vivem em definições seguras, nunca no código |
| 9 | Modelos de email personalizados | Os emails de confirmação e de reposição levam a tua marca, não um padrão genérico |
| 10 | Limitação de pedidos configurada | Um script abusivo não consegue martelar o teu login nem inflacionar a tua fatura |
| 11 | Cópias de segurança verificadas e a correr | Existem cópias de segurança diárias automáticas — confirmadas, não presumidas |
| 12 | Alertas de monitorização ativados | Ficas a saber de picos de erros e consultas lentas antes de os utilizadores te enviarem um email |
| 13 | Connection pooling, se for preciso | Muitos utilizadores em simultâneo não esgotam as ligações à tua base de dados |
| 14 | Chaves de API guardadas em segurança — nunca no código | Uma chave no teu repositório é uma chave na internet |
Cada verificação é uma pergunta que podes fazer à IA: "Mostra-me que a row-level security está ativada em todas as tabelas e lista as tabelas onde não está." Não precisas de saber corrigir cada item à mão. Precisas de te recusar a lançar até cada resposta ser sim.
12 semanasA tua carreira corporativa nunca foi o planoCandidata-te ao Solopreneur Accelerator.Candidatar-me →As três verificações que os fundadores mais saltam
Row-level security (verificações 2 e 3). É a parede entre os dados dos teus clientes — a base de dados a recusar-se, ao seu próprio nível, a entregar os registos do utilizador A ao utilizador B. É a verificação com o pior modo de falha, e por isso tem um guia só para ela. Ativada não chega; testa-a tentando ler os dados de outra conta e confirmando que não consegues.
Chaves secretas (verificações 8 e 14). A tua app tem chaves públicas (seguras no browser) e chaves secretas (acesso total a tudo). As secretas pertencem às definições protegidas do teu fornecedor de alojamento. Se uma chave secreta alguma vez foi escrita no teu código, trata-a como comprometida e substitui-a antes do lançamento.
O ensaio do rollback. Não está na lista acima porque é um exercício, não uma definição: faz um deployment e depois pratica a reversão para a versão anterior a partir do painel do teu alojamento. Demora cerca de 30 segundos, sem tempo de inatividade — mas só parece uma rede de segurança depois de o teres feito. Esse ensaio é também a base de fazer deployment sem medo depois do lançamento.
Verificações do lado do alojamento: domínio, SSL, ambiente
Do lado do alojamento, quatro itens completam a entrada em produção. O teu domínio personalizado está ligado — as alterações de DNS levam 10–30 minutos a propagar. O SSL está ativo, e o teu alojamento emite-o de graça e automaticamente em 5–10 minutos; nenhum utilizador deve alguma vez ver um aviso de "não seguro". As variáveis de ambiente de produção estão definidas no painel com valores reais, separadas de quaisquer valores de staging. E o registo de erros e as estatísticas estão ligados, para que desde o primeiro utilizador vejas o que se parte e o que é usado — a mesma canalização por trás de monitorizar o teu SaaS como fundador a solo.
Cópias de segurança e recuperação: assume o pior uma vez
No plano gratuito de uma plataforma como o Supabase, as cópias de segurança correm diariamente e são guardadas durante 7 dias. O plano Pro (25 dólares/mês) alarga a retenção para 30 dias e acrescenta recuperação para um momento específico — repor a base de dados em qualquer instante, por exemplo cinco minutos antes de uma alteração má. Passa dez minutos a escrever o teu plano de recuperação enquanto estás calmo: base de dados corrompida → repor a última cópia de segurança e verificar. Parece paranoia até ao dia em que parece genialidade.
Quanto custa tudo isto: normalmente nada
A parte tranquilizadora. Os planos gratuitos são genuinamente de nível de produção: a minha própria configuração corre 3 sites em produção, com 300–500 builds e 50–100 GB de largura de banda por mês — por 0 € de alojamento. Os sinais de que já não cabes no gratuito são concretos: uma base de dados acima de 500 MB, largura de banda acima de 5 GB/mês, ou quereres a retenção de cópias de segurança mais longa — e aí são 25 dólares/mês. Para a maioria dos produtos a solo, o plano gratuito aguenta-te durante meses ou anos. A checklist custa uma tarde. Saltá-la pode custar o negócio.
O livroThe Solopreneur RevolutionLuis Gonçalves sobre como construir um negócio de EUpreendedor com IA sem deixar o emprego.Quero o livro →Perguntas frequentes
O que devo verificar antes de lançar um SaaS?
Catorze itens técnicos em cinco áreas: base de dados (migrações corridas, row-level security ativada e testada, índices criados), autenticação (configurada para o teu domínio real, emails com a tua marca), segurança (chaves secretas fora do código, limitação de pedidos), resiliência (cópias de segurança verificadas, um rollback de 30 segundos ensaiado) e visibilidade (registo de erros e alertas de monitorização ligados).
Preciso de um plano pago para ir para produção?
Normalmente não. Os planos gratuitos são de nível de produção: largura de banda ilimitada do lado do alojamento, cópias de segurança diárias com retenção de 7 dias do lado da base de dados. Passa para o plano de base de dados de 25 dólares/mês quando ultrapassares 500 MB de dados ou quiseres retenção de 30 dias com recuperação para um momento específico. Os meus três sites em produção correm com 0 € de alojamento.
Qual é a verificação mais esquecida?
Testar a row-level security — não apenas ativá-la. Os fundadores ligam-na, não veem erros e lançam. Mas uma política errada comporta-se exatamente como uma certa até alguém ler os dados de outro cliente. Antes do lançamento, tenta ativamente aceder a dados entre contas e confirma que a base de dados recusa.
Como funcionam as cópias de segurança para um fundador a solo?
Automaticamente, depois de verificadas. As plataformas geridas fazem cópia de segurança da tua base de dados diariamente, sem configuração — retenção de 7 dias no plano gratuito, 30 dias mais recuperação para um momento específico no plano de 25 dólares/mês. O teu trabalho tem duas partes: confirmar que as cópias de segurança estão mesmo a correr antes do lançamento e escrever o procedimento de reposição enquanto nada está a arder.
Quão preso estás, a sério?
Faz o Índice de Sufocamento Corporativo, a avaliação gratuita para saberes se estás pronto para ser um EUpreendedor.