Construindo um SaaS do zero, parte 5: colocando no ar sem quebrar no primeiro dia

O app funciona no ambiente de desenvolvimento, a cobrança está ligada e o acesso por plano funciona. Falta a etapa em que quase todo projeto perde um fim de semana: colocar no ar com domínio próprio, sem chave exposta e sem quebrar autenticação.

Esta quinta parte da série Construindo um SaaS do zero cobre a configuração de produção e o checklist que evita os erros que só aparecem depois que o app sai do localhost.

Domínio e DNS

Registre o domínio, depois aponte para onde o app está hospedado. Dois tipos de registro resolvem quase tudo:

Três coisas que costumam travar essa etapa:

Propagação leva tempo. Mudança de DNS pode demorar horas para valer em toda parte. Testar de outra rede ou pelo celular na rede móvel ajuda a distinguir propagação incompleta de configuração errada.

Escolha uma versão canônica. Ou www ou raiz, com a outra redirecionando. Servir as duas sem redirecionamento divide sinal de SEO e gera sessão perdida no login.

Certificado leva alguns minutos depois do DNS resolver. Erro de certificado logo após apontar o domínio quase sempre é impaciência.

Variáveis de ambiente

Aqui mora o erro mais caro dessa etapa. Existem dois tipos de chave e eles nunca se misturam.

Variável com prefixo público, como VITE_ ou PUBLIC_, entra no pacote enviado ao navegador. Qualquer pessoa lê. Colocar a chave de serviço numa variável com esse prefixo entrega o banco inteiro.

A chave de serviço só existe dentro de edge function ou backend. Se ela vazou em algum momento, gere uma nova no painel e troque em todos os lugares. Chave vazada não se conserta removendo do código, porque ela continua no histórico do repositório.

Configuração de produção do Supabase

Quatro ajustes que não existem em desenvolvimento e que quebram o app no dia do lançamento:

Site URL e Redirect URLs. Precisam apontar para o domínio real. Enquanto estiverem em localhost, o link de confirmação de e-mail e o retorno do login social mandam o usuário para lugar nenhum.

SMTP próprio. O envio padrão serve para teste e tem limite baixo. Sem SMTP configurado, recuperação de senha simplesmente para de funcionar quando o volume sobe.

RLS em toda tabela com dado de usuário. Confira tabela por tabela. Tabela criada no meio do caminho por uma iteração da IA costuma ser a que ficou sem proteção.

Buckets de storage. O padrão privado é o correto para arquivo de usuário. Bucket público significa que qualquer pessoa com a URL acessa o arquivo, sem login.

Checklist antes de abrir

O quinto item merece atenção especial. Criar conta nova é o caminho que você menos percorre depois da primeira semana de desenvolvimento, e é o primeiro que todo usuário faz.

Erros que só aparecem em produção

CORS. Requisição que funcionava local passa a ser bloqueada porque a origem mudou. A correção é liberar o domínio novo na configuração da função, não desligar a checagem.

Redirect de login social. O provedor precisa conhecer a URL de callback com o domínio de produção. Cada provedor tem sua própria lista, e o Supabase tem a dele.

Fuso horário. Servidor em UTC, usuário no Brasil. Data que aparece um dia atrasada geralmente é conversão faltando na hora de exibir. Grave sempre em timestamptz e converta na apresentação.

Cold start. Função sem uso demora mais na primeira chamada. Se o primeiro clique do usuário depende dela, mostre estado de carregamento em vez de deixar a tela parada.

Cache de build. Alteração publicada que não aparece costuma ser cache do navegador ou da CDN. Teste em aba anônima antes de suspeitar do deploy.

Observabilidade mínima

Não precisa de painel sofisticado no primeiro dia. Precisa de três coisas:

Log de erro do lado do servidor, com o log das edge functions acessível e lido de verdade nas primeiras semanas.

Captura de erro no front, para saber quando a tela quebrou para o usuário sem ele reportar.

Um alerta por e-mail para falha de webhook de pagamento. Cobrança que falha em silêncio é receita perdida sem aviso.

Plano de rollback

Antes de publicar, saiba como voltar. No Lovable isso é o histórico de versões do projeto. Em migração de banco, é o script reverso escrito antes de aplicar a mudança.

Publicar sexta à noite sem plano de rollback é a receita clássica de fim de semana perdido. Publique em dia e horário em que você consegue acompanhar.

As primeiras 48 horas

O que observar, em ordem de importância:

Cadastros iniciados contra cadastros concluídos. Diferença grande aponta problema no e-mail de confirmação.

Erros nos logs, agrupados por mensagem. Um erro repetido cem vezes vale mais atenção que cem erros diferentes.

Primeira ação relevante depois do cadastro. Usuário que cria conta e não faz nada indica que a tela inicial não deixou claro o próximo passo.

Fatura de infraestrutura no segundo dia. Pico inesperado aparece rápido e é mais fácil de corrigir na primeira semana.

O que vem depois

Com o produto no ar, a série entra na fase que decide se ele sobrevive: os primeiros usuários, o que medir e o que mudar com base no que eles fazem. A parte 6 trata disso.

Se você chegou até aqui com as cinco partes, tem ideia validada, banco modelado, interface funcionando, cobrança ligada e produto publicado. O que falta agora não é código.