Como levar um protótipo de IA para produção

Para levar um protótipo de IA para produção, você fecha a distância entre “funciona quando eu testo” e “continua funcionando quando outras pessoas usam”. Na prática, isso significa cinco coisas: testar os fluxos principais a cada mudança, controlar quem vê e altera o quê, garantir que você fique sabendo dos erros antes que os usuários avisem, fazer backup dos dados e comprovar que consegue restaurá-los, e manter o app rápido o bastante no celular. Nada disso exige reescrever tudo — é uma lista de verificação que você percorre com a mesma IA que criou o protótipo.

Protótipo versus produção: o que realmente muda

Um protótipo tem um único usuário cuidadoso: você. Você sabe em quais botões clicar, digita entradas sensatas e, se algo quebra, dá de ombros e pede à IA que corrija. A produção tem muitos usuários descuidados, alguns curiosos e, de vez em quando, um hostil. O código não precisa virar algo “corporativo”; ele precisa lidar com as situações que um protótipo nunca encontra.

O restante deste guia percorre cada linha dessa tabela.

Passo 1: Congele o escopo e anote os fluxos principais

Antes de endurecer qualquer coisa, defina o que é a versão um. Liste de três a seis fluxos que mais importam — por exemplo, “criar conta, criar um projeto, convidar um colega, pagar”. Eles viram seu roteiro de teste, seus alvos de monitoramento e o que você confere após cada mudança.

Qualquer coisa fora da lista ou é cortada, ou claramente marcada como beta. É muito mais fácil tornar quatro fluxos confiáveis do que quatorze.

Passo 2: Teste como um desconhecido e depois torne o teste repetível

Os construtores com IA são bons em produzir código que funciona no caminho feliz. Os problemas de produção vivem nos caminhos infelizes. Teste cada fluxo principal com:

• Entradas ruins: campos obrigatórios vazios, um nome com 5.000 caracteres, um e-mail sem @, uma quantidade negativa, uma data no passado.
• Atualizações e botão voltar: recarregue no meio do checkout; aperte voltar depois de enviar um formulário. Algo é criado duas vezes?
• Duas abas, dois usuários: entre com duas contas diferentes e tente abrir as páginas uma da outra trocando o ID na URL.
• Lento e pequeno: uma tela do tamanho de celular e uma conexão limitada (as ferramentas de desenvolvedor do navegador conseguem simular isso).
• Estados vazios: uma conta nova, sem dados. Protótipos costumam ser criados com dados de exemplo e parecem quebrados sem eles.

Em seguida, torne a verificação repetível. No mínimo, mantenha uma lista escrita e execute-a antes de cada versão. Melhor ainda: peça à IA que escreva testes automatizados para os fluxos mais importantes:

Adicione testes automatizados de ponta a ponta para estes fluxos: cadastro com e-mail, criação de um projeto, convite de um segundo usuário e conclusão do checkout no modo de teste do Stripe. Adicione também testes que confirmem que um usuário não consegue ver nem editar o projeto de outro usuário trocando a URL.

Testes que comprovam que um usuário não consegue fazer algo são justamente os que os protótipos mais costumam não ter.

Passo 3: Noções básicas de segurança que os protótipos ignoram

A maioria dos problemas de segurança em apps criados com IA não é exótica. São verificações que faltam. Percorra esta lista e veja também a lista completa de segurança para apps criados com IA:

• Autorização no servidor. Esconder um botão não é segurança. Toda requisição que lê ou altera dados precisa verificar, no servidor, se o usuário logado tem permissão. Se seu app usa um banco de dados com regras por linha, confira se elas estão ativadas e testadas.
• Segredos fora do navegador. Chaves de API de pagamento, e-mail ou provedores de IA pertencem às variáveis de ambiente do servidor, nunca ao código do front-end. Se não tiver certeza do que isso significa, leia o que são variáveis de ambiente e segredos.
• Validação no servidor. O navegador pode ser contornado, então repita no servidor qualquer verificação importante.
• Login feito corretamente. Use uma biblioteca ou serviço de autenticação bem testado em vez de armazenar senhas de forma improvisada. Nosso guia sobre como adicionar login ao seu app cobre as opções.
• Limites de requisições no login, no cadastro, na redefinição de senha e em tudo que envia e-mail ou chama uma API paga.
• Erros amigáveis. Os usuários devem ver “algo deu errado”; os detalhes vão para os seus logs, não para a tela.
• Troque qualquer coisa que tenha vazado. Se uma chave ativa já foi colada em um chat, em um commit ou em uma captura de tela, substitua-a no provedor.

Um prompt que cobre muito terreno de uma vez:

Revise este app para segurança em produção. Verifique se cada rota da API confirma que o usuário logado é dono do registro que lê ou altera, se nenhuma chave secreta é enviada ao navegador, se as entradas são validadas no servidor e se o login e a redefinição de senha têm limite de requisições. Liste o que encontrar antes de mudar qualquer coisa.

Pedir primeiro uma lista permite ver os problemas e decidir a ordem, em vez de receber uma mudança gigante de uma só vez.

Passo 4: Saiba quando quebra — logs e monitoramento

Na prévia você vê os erros conforme eles acontecem. Em produção, o app precisa avisar você. Três camadas, da mais barata para a mais útil:

1. Logs do servidor. Garanta que os erros sejam registrados com contexto suficiente para reproduzi-los: qual rota, qual ID de usuário (nunca a senha nem o cartão) e qual formato da entrada. Peça à IA para adicionar registro estruturado de logs se o app só imprime no console.
2. Rastreamento de erros. Um serviço como o Sentry ou ferramenta semelhante captura exceções do front-end e do back-end, agrupa-as e envia e-mail para você. Para um app pequeno, os planos gratuitos desses serviços costumam bastar; confira os limites atuais nos sites deles.
3. Verificações de disponibilidade. Um serviço externo que carrega sua página inicial e uma rota de API importante a cada poucos minutos e avisa se falharem. Isso pega os problemas que impedem o app até de registrar logs.

Adicione mais um hábito: após cada versão, abra o app no ar e execute sua lista de fluxos principais na URL real, não apenas na prévia.

Passo 5: Backups e um caminho de volta

Duas coisas diferentes precisam de proteção, e é fácil confundi-las.

• Código. Mantenha o projeto em controle de versão para que qualquer mudança possa ser desfeita. Muitos construtores com IA guardam pontos de restauração dos seus arquivos; sincronizar com um repositório Git dá uma cópia fora do construtor também.
• Dados. Reverter o código não reverte o banco de dados. Uma migração ruim ou um botão de exclusão com defeito podem destruir registros que nenhum ponto de restauração do código vai trazer de volta.

Para os dados, configure backups regulares guardados em um lugar diferente da hospedagem do app — para um banco Postgres, a abordagem comum é um pg_dump agendado para um armazenamento separado, e muitos provedores de banco gerenciados oferecem backups automáticos ou recuperação para um ponto no tempo. Depois, faça a etapa que a maioria das pessoas pula: restaure um backup em um banco de testes e confira se os dados estão lá.

Peça também à IA que torne as ações destrutivas mais seguras: uma etapa de confirmação para exclusões e “exclusão suave” (marcar registros como excluídos em vez de removê-los) para qualquer coisa que os usuários possam querer recuperar.

Passo 6: Desempenho que se sustenta no celular

Os protótipos parecem rápidos porque você é o único usuário e o volume de dados é mínimo. Antes do lançamento:

• Carregue dados de tamanho real. Peça à IA para popular milhares de linhas e veja quais páginas ficam lentas. Listas geralmente precisam de paginação, e o banco geralmente precisa de índices nas colunas que você filtra e ordena.
• Reduza as imagens. Imagens grandes são a razão mais comum para uma página carregar devagar. Peça imagens redimensionadas, comprimidas e com carregamento preguiçoso abaixo da dobra.
• Meça. Rode o Lighthouse nas ferramentas de desenvolvedor do Chrome na URL ativa, no modo celular. As Core Web Vitals do Google são uma meta sensata: Largest Contentful Paint em até 2,5 segundos, Interaction to Next Paint de 200 ms ou menos e Cumulative Layout Shift de 0,1 ou menos.
• Fique atento a atrasos de “despertar”. Hospedagens que hibernam quando ociosas economizam dinheiro, mas tornam a primeira visita após um período parado mais lenta. Para um app novo, isso costuma ser uma troca aceitável; saiba que acontece.

A página de projetos está lenta com 5.000 linhas. Adicione paginação no servidor (25 por página), adicione índices no banco para as colunas que filtramos e ordenamos, e mostre um estado de carregamento enquanto a próxima página é carregada.

Passo 7: Noções básicas de operação

Algumas pequenas coisas separam um app de hobby de um app em que as pessoas confiam:

• Um domínio personalizado com HTTPS. Veja como conectar um domínio personalizado.
• E-mails transacionais enviados de um domínio verificado para confirmações de cadastro e redefinição de senha — tratados em como enviar e-mails pelo seu app.
• Política de privacidade e termos que descrevam o que você realmente coleta. Não copie declarações de conformidade que você não cumpriu.
• Um canal de suporte — mesmo que seja um e-mail monitorado.
• Chaves de teste e de produção separadas para pagamentos e e-mail, e uma anotação clara de qual ambiente usa qual.

Passo 8: Uma entrega bem feita

Mais cedo ou mais tarde, outra pessoa vai trabalhar no app: um freelancer, um novo cofundador ou você mesmo daqui a seis meses. Facilite isso:

• Um README que explique como executar o app, quais variáveis de ambiente ele precisa (somente os nomes, nunca os valores) e como publicá-lo.
• A lista de fluxos principais e os testes automatizados.
• Uma breve nota de arquitetura: front-end, back-end, banco de dados, serviços de terceiros e onde cada um está hospedado.
• Lista de acessos: quem tem acesso de administrador ao domínio, à hospedagem, ao banco, às contas de pagamento e de e-mail. Mantenha essas contas em um e-mail corporativo, não pessoal.
• O código no Git, idealmente sincronizado com um repositório que seja seu. Se você talvez mude de hospedagem depois, leia como exportar e hospedar você mesmo um app criado com IA.

A IA pode rascunhar a maior parte disso para você:

Escreva um README para este projeto para um desenvolvedor que nunca o viu: o que o app faz, a stack de tecnologia, como executá-lo localmente, cada variável de ambiente que ele lê (apenas nomes e finalidade), como o esquema do banco de dados está organizado e como publicá-lo.

Checklist de prontidão para produção

• Fluxos principais escritos e testados, incluindo “não consegue acessar os dados de outra pessoa”
• Autorização e validação no servidor em toda rota de dados
• Nenhuma chave secreta no código do front-end; chaves vazadas substituídas
• Limites de requisições no login e em tudo que custa dinheiro
• Rastreamento de erros e alertas de disponibilidade apontando para uma caixa de entrada que você lê
• Backups do banco fora da hospedagem do app, com pelo menos uma restauração de teste bem-sucedida
• Paginação e índices verificados com dados realistas
• Domínio personalizado, domínio de envio verificado, política de privacidade
• README e lista de acessos para quem vier depois

Fazendo isso com o Mythex

Se você criou o protótipo no Mythex, a maioria dessas etapas são prompts no mesmo projeto. Digite /test e o Mythex percorre a prévia ao vivo como um usuário e informa os fluxos quebrados — veja Testes de app. As chaves vão para os segredos do projeto em vez do chat, cada turno bem-sucedido do agente salva um ponto de restauração dos seus arquivos para o qual você pode voltar, e publicar gera uma URL ativa com hospedagem, e o banco de dados é cobrado do mesmo saldo de créditos (limites de hospedagem explica como apps e bancos hibernam e voltam). Os pontos de restauração cobrem arquivos, não linhas do banco, então continue planejando os backups dos seus dados. No plano Pro, você pode conectar um domínio personalizado e exportar o código ou sincronizá-lo com o seu próprio repositório do GitHub para uma entrega.

Perguntas