Como construir um SaaS com Claude Code e Codex: do PRD ao deploy

Construir um SaaS com Claude Code e Codex é um processo em sete etapas: PRD, arquitetura, banco, autenticação, implementação em raias paralelas, testes e deploy. O agente escreve quase todo o código. Você decide o que é aceitável antes de ele escrever, e revisa na mão os quatro pontos onde errar custa caro.

Esse texto é o mapa. Cada etapa tem um guia próprio, linkado no lugar certo, e a ordem importa mais do que a ferramenta: o mesmo processo funcionou com Claude Code sozinho, funciona hoje com Claude Code e Codex juntos, e vai funcionar com o que vier depois.

Por que a ordem importa mais que a ferramenta

O erro que eu mais vejo é começar pedindo código. A pessoa abre o terminal, descreve o produto em duas frases e manda gerar. Sai algo que roda na primeira tela e desmonta na terceira, porque nenhuma decisão de estrutura foi tomada antes, e o agente tomou todas elas sozinho, uma por vez, sem saber das outras.

Coding agent é excelente em executar decisão tomada e péssimo em tomar decisão que depende de contexto que ninguém deu. Quando eu especifico antes, o agente acerta quase tudo de primeira. Quando eu não especifico, ele inventa um padrão diferente em cada arquivo e eu gasto mais tempo reconciliando do que gastaria escrevendo.

Então o método não é sobre prompt bonito, é sobre chegar na hora de gerar código com as perguntas difíceis já respondidas.

Etapa 1: o que entra no PRD antes de abrir o terminal

O PRD define o que o sistema faz, para quem, e principalmente o que ele não faz. Não precisa ser documento de vinte páginas, precisa ser específico onde o agente erraria sozinho: quem são os papéis de usuário, o que cada papel pode ver e alterar, quais são as entidades principais e como elas se relacionam, e o que acontece nos casos ruins.

Eu escrevo o PRD em markdown, no repositório, e ele fica versionado junto com o código. Quando a spec muda, o commit conta a história. Detalhei o formato que eu uso, com template, no guia de como escrever um PRD para Claude Code e Codex.

Etapa 2: quais decisões de arquitetura você não pode delegar

Existem escolhas que são baratas de fazer no começo e caríssimas de desfazer depois. Multi-tenancy é a principal: decidir se cada cliente tem schema próprio, banco próprio, ou se tudo divide as mesmas tabelas com uma coluna de tenant muda absolutamente tudo daí para frente, do modelo de dados ao custo de infraestrutura.

O agente vai escolher uma dessas se você não escolher. E ele vai escolher a mais simples de escrever, que quase nunca é a mais barata de manter. As cinco decisões que eu sempre fecho antes estão no guia de arquitetura de SaaS antes de gerar código.

Etapa 3: banco e migrations quando quem escreve é um agente

Banco é onde o estrago fica. Código ruim você reescreve numa tarde, schema ruim com dado de cliente em cima você carrega por anos. O ponto que mais me deu trabalho foi drift de nomenclatura, com o ORM falando camelCase e o Postgres falando snake_case, e o agente escrevendo query crua que não bate com o mapeamento.

A regra que eu adotei é simples: convenção de nomes escrita na spec, e migration sempre revisada por mim antes de rodar. Está tudo em banco de dados e migrations com agentes de IA.

Etapa 4: autenticação e autorização, o que eu nunca aceito sem ler

Autenticação o agente costuma acertar, porque é padrão e tem biblioteca boa. Autorização ele erra, e erra de um jeito que passa em todos os testes felizes: o endpoint valida que você está logado e esquece de validar que aquele recurso é seu.

Isso é IDOR, e num SaaS multi-tenant significa um cliente lendo o dado do outro. É o primeiro item que eu leio linha por linha, em todo projeto, sem exceção. O detalhe de como eu reviso está em autenticação e autorização em SaaS multi-tenant gerado com IA.

Etapa 5: dois agentes no mesmo repositório sem conflito

Quando o projeto tem frentes independentes, eu coloco Claude Code e Codex trabalhando em paralelo, cada um na sua worktree do Git, cada um com o seu escopo escrito. Frentes independentes de verdade, não duas pessoas no mesmo arquivo.

Uma coisa que aprendi na marra: quando os dois chegam na mesma conclusão, isso não é validação. Eles compartilham o mesmo viés de treino e concordam errado com frequência. Concordância entre agentes é conforto, não prova. O setup completo está em Git e worktrees para Claude Code e Codex em paralelo, e a divisão de trabalho entre os dois em Claude Code e Codex juntos.

Etapa 6: como debugar código que você não escreveu

Em algum momento algo quebra e o código é do agente. O reflexo errado é colar o erro no chat e mandar consertar, porque aí ele tenta um remendo, o sintoma some, a causa fica, e volta em outro lugar três dias depois.

O que funciona é diagnosticar a raiz primeiro, na mão, e só então pedir a correção já sabendo qual é. Método completo em como debugar código que a IA escreveu.

Etapa 7: o que testar primeiro quando o tempo é curto

Cobertura total é conversa de quem não tem prazo. A ordem que eu uso é por consequência do erro: autorização, dinheiro, migração de dados, e só depois o resto. Se um desses três primeiros quebrar em produção, o problema não é técnico, é cliente ligando.

Está detalhado em testes automatizados em projeto tocado por agente.

Etapa 8: segurança e deploy antes do primeiro cliente pagante

Antes de subir, eu passo um checklist fixo, porque o agente tem pontos cegos previsíveis: segredo commitado, endpoint sem rate limit, upload sem validação de tipo, webhook sem verificação de assinatura, log gravando dado pessoal. São sempre os mesmos, e por isso viram lista, não memória.

O checklist está em checklist de segurança antes de colocar um SaaS feito com IA em produção, e o caminho do container até o primeiro cliente pagando em deploy de SaaS multi-tenant.

Quanto disso dá pra delegar ao agente

Você precisa saber programar pra fazer isso?

Precisa saber ler código o suficiente pra discordar do agente. Não precisa começar sabendo, e boa parte de quem faz a travessia comigo veio de WordPress, de n8n ou de tráfego, sem base formal. Mas a ideia de que dá pra construir SaaS em produção sem nunca entender o que está escrito é falsa, e quem vende isso vai te deixar na mão exatamente no dia em que der problema.

O que muda é a curva: com método, você aprende a ler o que importa primeiro, em vez de tentar aprender tudo antes de começar.

Perguntas frequentes

Dá pra usar só Claude Code, sem Codex?

Dá, e é o que eu recomendo pra começar. O segundo agente resolve paralelismo, não qualidade. Se você ainda não tem frentes independentes o suficiente pra ocupar dois, o segundo só adiciona custo e coordenação.

Quanto tempo leva pra sair do PRD ao primeiro deploy?

Um SaaS pequeno de verdade, com um domínio bem definido, sai em dias. O que estica o prazo quase nunca é a geração de código, é decisão em aberto: escopo que muda no meio, integração de terceiro que não estava prevista, e regra de negócio que ninguém tinha escrito.

E quando o agente insiste num caminho ruim?

Isso costuma ser sintoma de spec vaga, não de teimosia. Antes de brigar no chat, eu volto na spec e escrevo explicitamente o que não pode. Funciona melhor do que repetir a instrução em maiúsculas.