No Capítulo 4, "Criar com a IA" anterior, algo que funciona ficou pronto. Daqui em diante é a Fase 4, "publicar" – a etapa de conferir com testes se não quebra, tapar os buracos de segurança e então lançar ao mundo. Sem se contentar com o "funcionou", leve até um estado em que outras pessoas possam usar com tranquilidade. Soa difícil, mas aqui também a IA é sua parceira.
"Pode estar incompleto. Primeiro, entregar a 1 pessoa com segurança"
"Criado" e "pronto para publicar" são coisas diferentes
Algo que funciona no seu computador e algo que aguenta o toque de outras pessoas são coisas distintas. Você conhece "o jeito certo de usar" e o opera como esperado. Mas, ao publicar, chegam entradas, ações e má-fé que você não previu. Gente que envia em branco, gente que cola uma pilha de símbolos, gente que tenta espiar os dados de outros.
Nem por isso é preciso ficar em guarda. A primeira coisa a fazer no desenvolvimento solo são só 3 pontos bem básicos: "não quebra?", "não vaza segredo?", "os dados de terceiros estão protegidos?". Este capítulo é para cumprir esse mínimo junto com a IA e publicar de cabeça erguida.
Só se toca pelo passo certo. Se der erro, você mesmo corrige. Se um dado secreto aparece na tela, você não se importa.
Chegam entradas inesperadas. Da tela de erro vazam informações internas. Com uma chave publicada por descuido, pode haver cobrança altíssima ou vazamento de dados.
Delegar testes e revisão à IA
"No desenvolvimento solo, não tem um colega sênior para revisar o código" – pois esse papel é justamente o que se deve delegar à IA. O código que você escreveu (ou mandou a IA escrever), faça a IA reexaminar mais uma vez, por outro ângulo. Quem escreveu (humano ou IA) tem dificuldade de notar os próprios erros. Por isso, pôr um "auditor" funciona.
A forma é simples. Basta colar o código e pedir assim: "Aponte os bugs, as entradas perigosas e os testes que faltam neste código." Então voltam, em lista, os buracos que você não tinha notado. Depois, corrija um a um, começando pelos de maior prioridade. Sem tentar corrigir tudo de uma vez, o segredo é corrigir 1 apontamento, conferir o funcionamento, e mais 1.
Ao pedir a auditoria à IA, deixar explícitos os seguintes ângulos aumenta a precisão.
"Em que situação ele cai?", "e se eu passar em branco ou zero?". Faça a IA buscar as condições em que quebra.
Strings maliciosas, dados gigantes, arquivos inválidos. Pergunte "se fosse um atacante, como você atacaria?".
"Que casos deveriam ser conferidos, mas não estão?". Faça-a levantar valores-limite e exceções.
"Tem chave de API ou senha escrita direto no código?". Arranque cedo os brotos de vazamento.
💡 Teste é "um mecanismo que confere automaticamente". Na rota prática, mande a IA escrever até o código de teste. Pedindo "escreva os testes desta função. O caso normal e também os casos em branco e com valores anormais", você pode, na próxima correção, reconferir com 1 botão se algo quebrou. Na rota iniciante, "tentar de propósito operações estranhas" à mão já é um passo suficiente.
Os 3 mínimos de segurança
Segurança é um campo profundo, mas decore só os 3 pontos que você deve garantir sem falta ao publicar no desenvolvimento solo. Falhar nesses 3 pode custar, de uma vez, dinheiro, credibilidade e informações de terceiros. Por outro lado, cumprindo isto, já basta para a primeira publicação.
Não escreva chaves de API, senhas e tokens direto no código. Passe-os para um arquivo de variáveis de ambiente como o .env e exclua esse arquivo da publicação (adicione ao .gitignore).
Se há login, faça de modo que a pessoa A não consiga ver dados que não são dela. Ponha, sem falta, uma verificação de dono – "este dado é mesmo desta pessoa?" – e mande a IA conferir.
Chaves de serviços externos e permissões do banco, só o necessário. Não distribua chaves que "fazem tudo". Emita chaves descartáveis, chaves só de leitura etc., com o uso restrito.
🚨 Nunca publique a chave secreta. Este é o acidente mais comum, e o mais caro, do desenvolvimento solo. Se você publica no GitHub, por exemplo, com a chave de API escrita direto no código, ela é encontrada automaticamente e abusada em minutos ou horas. Com uma API paga, já aconteceu de a pessoa perceber quando a cobrança já estava em milhares de reais. Antes de publicar, mande sem falta a IA checar "se sobrou alguma chave no código". E uma chave que você chegou a publicar uma vez, excluir não basta. Invalide-a e emita uma nova, sem falta.
Se achar "parece difícil", basta perguntar assim à IA: "Antes de publicar este código, me ensine, para iniciante, o que devo fazer em termos de segurança." Volta uma checklist concreta, ajustada ao seu código.
Rodar a automação com segurança (para a prática)
Aqui é sobretudo assunto da 🔧 rota prática. Delegar automaticamente operações de arquivo e execução de comandos a um agente de IA como o Claude Code acelera o desenvolvimento de uma vez. Por outro lado, o risco de descontrole – "apagar um arquivo importante por conta própria", "rodar um comando não intencionado" – não é zero.
Por isso é importante a ideia de "isolamento (sandbox)". Ao dar permissões fortes à IA, rode-a dentro de uma caixa em que não há problema se algo der errado. Concretamente, confine-a a uma pasta de trabalho ou container dedicado, sem acesso a dados de produção nem a informações secretas. Assim, você delega a automação à IA com tranquilidade.
📦 "Testar dentro da caixa, produção com calma" é o princípio. Não rode a execução automática da IA logo de cara sobre o ambiente de produção ou dados importantes. A forma concreta de isolar está explicada em detalhe no guia de configuração de sandbox do Claude Code. Quem está na rota iniciante, basta saber que "existe essa medida de segurança".
Publicar – do código até estar no ar
Chegou enfim a publicação. "Publicar" é pôr o que está dentro do seu computador na internet, num estado em que qualquer um abre pela URL. Isso se chama deploy. Soa difícil, mas hoje dá para colocar no ar em serviços gratuitos com uns poucos cliques.
O fluxo geral são os 3 passos a seguir. A primeira publicação no desenvolvimento solo dá para bancar inteira no plano gratuito. Gastar dinheiro fica para quando as pessoas que usam aumentarem.
Salve o código no GitHub, por exemplo. Não esqueça de excluir os arquivos secretos (.env). Esta é a base da publicação.
Integre o GitHub a uma hospedagem gratuita como a Vercel. Registre as informações secretas como variáveis de ambiente pelo painel.
Ele faz o build automaticamente na internet e emite uma URL pública. Depois, é só entregar essa URL a 1 pessoa.
✅ Mesmo incompleto, publique e mostre a 1 pessoa. "Ainda faltam funcionalidades", "o design está mais ou menos" – adiar a publicação com esse sentimento é a maior causa de um projeto solo desaparecer. 60 pontos basta. Vá até o fim, mandando a URL pública a 1 pessoa próxima. Um "aqui é difícil de usar" dessa pessoa vale mais que 100 horas de remoer.
O passo a passo concreto – do salvar no GitHub à publicação na Vercel e à configuração das variáveis de ambiente – está explicado com telas em Como criar com Claude Code / Cursor e publicar na Vercel. Se travar, basta perguntar à IA na hora "deu erro nesta tela, o que faço?", que quase sempre você sai da enrascada.
- Mesmo sozinho, a IA faz o papel de revisora. Mande auditar com "aponte bugs, entradas perigosas e testes que faltam" e corrija um a um.
- Segurança são 3 mínimos: segredos vão para variáveis de ambiente / proteger os dados de terceiros / permissões no mínimo.
- Nunca publique a chave secreta. Vazou, não é excluir, é invalidar e reemitir. Antes de publicar, cheque com a IA.
- A publicação (deploy) dá para fazer no plano gratuito. Mesmo incompleto, vá até entregar a URL a 1 pessoa.
Com isso, você chegou até "criar e lançar com segurança". Mas a verdadeira disputa começa aqui. Fazer usarem, melhorar e chegar a um formato sustentável é a fase final. Avance para o próximo Capítulo 6, "Crescer – divulgação e monetização".