O seu protótipo com IA funciona na demo. Faça-o funcionar em produção.
Construiu uma aplicação com Lovable, Bolt, Replit ou Cursor e ela convence toda a gente na demo. Depois entra o segundo utilizador real e aparecem as falhas que a demo escondia: autenticação frágil, dados expostos, deploys sem caminho de volta. A Doomity audita e endurece protótipos gerados com IA sem deitar fora o seu trabalho: conservamos o que vale e reconstruímos apenas o que falharia com utilizadores reais. Âmbito fixo. O primeiro passo cabe em 5 dias.
Atualizado: julho de 2026
- 1 Dia 1 Kickoff e acessos → Inventário de evidências
- 2 Dia 2 Revisão técnica → Conclusões com provas
- 3 Dia 3 Mapa de riscos → Cada conclusão classificada
- 4 Dia 4 Opções A/B/C → Trade-offs em cima da mesa
- 5 Dia 5 Sessão executiva → Roadmap 30/60/90
Quais são as 5 falhas que aparecem quando entram utilizadores reais?
Quase todos os protótipos vibe-coded que a Doomity audita partilham as mesmas cinco falhas. São invisíveis na demo, porque a demo só tem um utilizador bem-intencionado: quem os construiu. Em produção, tornam-se inevitáveis:
- Autenticação de fachada. O ecrã de login existe; a verificação no servidor, não. Qualquer pedido direto à API passa sem credenciais.
- RLS aberta ou inexistente. No Supabase e afins, sem row-level security cada utilizador consegue ler os dados de todos os outros.
- Segredos no frontend. Chaves de API embutidas no código que o browser descarrega, visíveis para qualquer pessoa que abra as ferramentas de programador.
- Deploys sem rollback. Quando uma alteração parte a aplicação, não há caminho de volta. O erro fica em produção até alguém reescrever à pressa.
- Zero testes. Cada funcionalidade nova é uma aposta: ninguém sabe o que deixou de funcionar até um utilizador se queixar.
Reconhece duas ou mais? Faça o diagnóstico de produção: 10 perguntas, resultado imediato, sem compromisso.
O código gerado por IA é assim tão inseguro como dizem?
É, e há dados primários em vez de impressões. O relatório Veracode 2025 analisou código gerado por modelos de IA em tarefas reais: cerca de 45% das amostras introduziram vulnerabilidades conhecidas. Em cross-site scripting, os modelos falharam 86% dos casos; em log injection, 88%.
Isto não é um argumento contra as ferramentas. Nós próprios usamos IA no nosso processo de entrega. É um argumento contra lançar esse código sem uma auditoria feita por engenheiros que sabem o que procurar: o modelo otimiza para «funciona na demo»; produção exige «resiste a quem tenta abusar». São objetivos diferentes, e só o segundo protege os seus utilizadores.
Vão reescrever tudo ou aproveitam o trabalho que já fiz?
Conservamos tudo o que passa a auditoria, e dizemos-lhe por escrito o que não passa. Em regra, a interface, os fluxos de utilizador e a lógica de negócio validada sobrevivem: é onde o protótipo tem valor real, porque já foi testado com pessoas. O que costuma ser reconstruído é o que a demo nunca exercitou: autenticação, camada de dados, gestão de segredos e infraestrutura de deploy.
E uma opinião que nem sempre agrada: parte dos protótipos não merece ir para produção. Quando o custo de endurecer supera o de reconstruir sobre o que se aprendeu, dizemo-lo no relatório, com números. Preferimos perder um sprint a vendê-lo.
Como funciona o Production Readiness Sprint de 5 dias?
O Production Readiness Sprint é uma auditoria de âmbito fixo com quatro passos, sempre pela mesma ordem:
- Auditoria do código e da infraestrutura (dias 1–2). Lemos o que a IA gerou: autenticação, permissões, dados, segredos, dependências e configuração de deploy.
- Mapa de riscos (dia 3). Cada falha classificada por gravidade e custo de correção. Sem jargão: o que pode acontecer, a quem e quando.
- Plano de endurecimento (dia 4). O que se conserva, o que se reconstrói e por que ordem, com esforço estimado por item.
- Endurecimento das falhas críticas (dia 5 em diante). Começamos pelo que expõe dados ou bloqueia o lançamento. O resto fica planeado, não esquecido.
A garantia cobre o processo e os entregáveis — auditoria, mapa de riscos e plano —, nunca resultados de negócio: prometê-los antes de ler o código seria marketing, não engenharia. O método completo está documentado em como trabalhamos.
Que ferramentas de vibe coding é que a Doomity suporta?
Lovable, Bolt, Replit, Cursor, Base44 e v0. E, em geral, qualquer stack que gere código web moderno: React ou Next.js no frontend, Supabase, Firebase ou Postgres nos dados, Vercel ou Netlify no deploy. A ferramenta importa menos do que parece: as cinco falhas de cima repetem-se em todas, porque nascem da mesma causa — o modelo otimiza para a demo, não para o segundo utilizador.
Caso diferente: se a aplicação já está em produção e a partir-se com utilizadores reais, o ponto de entrada não é este sprint, é a recuperação de projetos de software. Estabilizar primeiro, endurecer depois.
O que acontece aos dados do meu protótipo durante a auditoria?
Tratamo-los como dados de produção, mesmo que «seja só um protótipo». Porque raramente é: a maioria já contém emails, nomes e por vezes pagamentos de utilizadores reais, o que os coloca sob o RGPD. Na prática: acesso ao repositório e à infraestrutura limitado aos engenheiros do sprint, com registo de quem acedeu a quê; nada de copiar bases de dados para máquinas locais; acordo de confidencialidade assinado antes de vermos uma linha de código.
Parte do relatório final é precisamente o mapa de dados pessoais: onde vivem, quem lhes toca e o que falta para cumprir o RGPD antes do lançamento.
Porquê confiar o lançamento a uma equipa externa como a Doomity?
Porque passar protótipos de IA a produção é um dos cinco serviços em que trabalhamos todos os dias, não um extra. A Doomity LLC é uma empresa de desenvolvimento de software especializada em software à medida, modernização de sistemas legados, passagem de protótipos de IA a produção, recuperação de projetos de software e due diligence tecnológica, que trabalha com clientes dos EUA, do Reino Unido, de Espanha e de Portugal. As nossas equipas construíram e operaram sistemas com utilizadores reais para a Holcim, a Canon Espanha e a Indra — ambientes onde uma falha de segurança não é uma nota num relatório, é um incidente. E usamos IA no nosso próprio processo de entrega, até 40% mais rápido: sabemos onde os modelos brilham e onde escondem o risco.
FAQ
Para a Doomity, uma aplicação está pronta para produção quando cumpre seis condições verificáveis: autenticação validada no servidor, não só no ecrã; permissões de dados por utilizador (RLS ou equivalente) testadas com contas diferentes; segredos fora do código do frontend; deploy com rollback, para que um erro não fique preso em produção; testes automáticos nos fluxos críticos, como registo, pagamento e recuperação de conta; e monitorização de erros, para saber que algo partiu antes de o cliente o dizer. Não é perfeição — é o mínimo para pôr dados de pessoas reais dentro da aplicação sem cruzar os dedos. O relatório do sprint avalia cada condição, uma a uma.
Na maioria dos casos, não — e desconfie de quem lho propõe antes de ler o código. A interface, os fluxos e a lógica de negócio validada costumam sobreviver: são o valor real do protótipo, porque já foram testados com utilizadores. O que se reconstrói com frequência é a camada que a demo nunca exercitou: autenticação, dados, segredos e deploy. A auditoria dos dois primeiros dias responde à pergunta com factos, não com opinião. E se a conclusão honesta for que reconstruir sai mais barato do que endurecer, recebe-a por escrito, com a comparação de esforço — a decisão continua a ser sua.
Por defeito, deve assumir que não. Os dados do relatório Veracode 2025 são claros: cerca de 45% do código gerado por IA em tarefas reais introduziu vulnerabilidades conhecidas, com taxas de falha de 86% em cross-site scripting e 88% em log injection. Não porque os modelos sejam maus a programar, mas porque otimizam para código que funciona, não para código que resiste a abuso — e ninguém lhes pediu o contrário. A boa notícia: são falhas conhecidas, com correções conhecidas. É exatamente o que a auditoria do sprint procura, ordena por gravidade e corrige primeiro.
O sprint tem duração fixa: em 5 dias recebe a auditoria, o mapa de riscos e o plano de endurecimento. O tempo até ao lançamento depende do que a auditoria encontrar — qualquer prazo dado antes de ler o código seria marketing. O que garantimos é a ordem: primeiro as falhas que expõem dados, depois as que bloqueiam o lançamento, por fim o resto, planeado com marcos verificáveis. Há protótipos que lançam duas semanas depois do sprint; outros precisam de mais. Se quiser uma estimativa honesta para o seu caso, <a href="/pt/reservar-chamada" class="text-primary-soft underline">reserve uma chamada</a> de 25–30 min com um engenheiro.
Lovable, Bolt, Replit, Cursor, Base44 e v0 são as mais frequentes, mas o critério real é a stack gerada, não a ferramenta: React, Next.js, Vue ou Svelte no frontend; Supabase, Firebase, Postgres ou MongoDB nos dados; Vercel, Netlify, Fly.io ou AWS no deploy. Se a sua combinação não está nesta lista, pergunte — a resposta costuma ser sim, porque as falhas de produção são as mesmas em todas. A única exceção verdadeira: código que a sua empresa não pode partilhar connosco por restrições contratuais. Sem acesso ao repositório, não há auditoria séria.
Três compromissos concretos. Primeiro, confidencialidade: acordo assinado antes de acedermos ao código, acesso limitado aos engenheiros do sprint e registado, e nenhuma cópia de bases de dados para fora da sua infraestrutura. Segundo, o relatório inclui um mapa de dados pessoais do protótipo: que dados existem, onde estão alojados, que serviços de terceiros lhes tocam e se saem do Espaço Económico Europeu. Terceiro, o plano de endurecimento lista o que falta para cumprir o RGPD antes do lançamento — consentimento, direito ao apagamento, encarregado de proteção de dados se aplicável. Não somos um escritório de advogados; somos os engenheiros que preparam a aplicação para que o seu passe a auditoria legal.
A sua app criada com IA aguenta produção? Autodiagnóstico em 10 perguntas
Dez perguntas, dois minutos. Recebe uma pontuação, uma banda de risco e as três correções a fazer antes de chegarem utilizadores reais — antes de nos deixar o seu email.
Pergunta 1 de 10
Para onde enviamos o seu resultado?
Email de trabalho. A pontuação e as ações aparecem aqui mesmo; sem newsletter.
Não conseguimos processar as suas respostas. Verifique a ligação e tente novamente.
Cada semana com o protótipo exposto a utilizadores reais sem endurecimento é risco acumulado: uma fuga de dados custa mais do que qualquer sprint, e a confiança dos primeiros utilizadores não se recupera com um patch. O trabalho que já fez tem valor. Proteja-o antes de o escalar: reserve o seu Production Readiness Sprint e lance com o mapa de riscos na mão.