Pular para o conteúdo

Seu app feito com IA está pronto para usuários reais?

A verificação de prontidão para produção da Plutonapps dá uma nota de 0 a 100 a um app feito no Lovable ou em qualquer construtor com IA, em cerca de três minutos. Responda 19 perguntas sobre segurança, dados, releases, monitoramento, pagamentos, privacidade e propriedade, e veja os três riscos a corrigir primeiro. É gratuita, e suas respostas ficam nesta página, a menos que você peça o relatório completo por e-mail.

As perguntas

Segurança e acesso

Quem pode fazer login e o que o banco de dados deixa cada um ler.

1.Como as pessoas fazem login no seu app?

Login é autenticação: provar quem alguém é.

2.A autenticação multifator está ativada em todas as contas que podem mudar a produção — Supabase, hospedagem, GitHub, Stripe, seu domínio?

Uma única senha roubada por phishing em qualquer uma delas abre caminho para tudo.

3.A segurança em nível de linha está ativada em todas as tabelas com dados de usuários, com políticas que você testou como um segundo usuário?

O RLS é o que impede um usuário logado de ler as linhas de outro pela sua API pública.

4.Onde fica a chave service-role (secreta) do seu Supabase?

A chave service-role ignora completamente a segurança em nível de linha.

5.Onde ficam seus outros segredos — a chave secreta do Stripe, as chaves de API de e-mail e de IA?

Um segredo em um repositório Git fica no histórico mesmo depois que você o apaga.

Segurança dos dados

Se seus dados sobrevivem a um deploy ruim, a um prompt ruim ou a um dia ruim.

6.Se uma mudança ruim apagasse uma tabela às 15h, o que você conseguiria restaurar?

Backups diários perdem tudo desde o último; a recuperação point-in-time não.

7.Você já restaurou um backup em um projeto separado para provar que funciona?

Um backup que ninguém restaurou é uma esperança, não um plano.

8.Como as mudanças no banco de dados chegam à produção?

Uma migration é um arquivo SQL versionado, aplicado do mesmo jeito em todo lugar.

Releases e testes

Como uma mudança é verificada antes de seus usuários a verem.

9.Existe um ambiente de homologação, com banco de dados próprio, onde as mudanças são verificadas primeiro?

Homologação (staging) é uma cópia privada da produção onde cada release é testada antes de ir ao ar.

10.Testes automatizados cobrem seus fluxos principais — cadastro, pagamento e a principal coisa que seu app faz?

Testes de regressão pegam a funcionalidade que você não tocou quebrando por causa de uma que você tocou.

11.Como o código chega à produção?

CI/CD roda as mesmas verificações a cada mudança e só faz deploy do que passa.

Operação no ar

Saber que quebrou antes que seus usuários avisem, e o que acontece depois.

12.Se o app quebrasse para os usuários agora, como você ficaria sabendo?

Observabilidade é saber o que o sistema em execução está fazendo, a partir de logs, métricas e erros.

13.Cadastro, login e tudo o que envia e-mail ou chama uma API paga (como um modelo de IA) têm limite de requisições?

Sem limite, um único script pode estourar sua conta ou bloquear seus usuários.

14.Se a produção caísse hoje à noite, há uma pessoa definida e um plano escrito?

Resposta a incidentes é decidir, antes de acontecer, quem age e como.

Pagamentos

Receber dinheiro sem guardar dados de cartão nem confiar no navegador.

15.Como seu app recebe pagamentos?

Quem guarda os dados do cartão decide quanto trabalho de conformidade cai sobre você.

16.Os webhooks recebidos são verificados pela assinatura e seguros para chegar duas vezes?

Os provedores reenviam webhooks, então o mesmo evento pode chegar mais de uma vez.

Privacidade e conformidade

O básico do GDPR e um registro de quem mudou o quê.

17.Você tem o básico do GDPR: uma política de privacidade que cita seus provedores, um acordo de tratamento de dados com cada um e uma forma de excluir os dados de um usuário quando ele pedir?

Se você tem usuários na UE ou no Reino Unido, isso é obrigação legal, não extra.

18.Você consegue dizer quem mudou o quê na sua área administrativa, e quando?

Um log de auditoria é um registro, só de inclusão, das ações importantes.

Propriedade

Se o app é seu para mover, entregar e manter funcionando.

19.O código está em um repositório Git que é seu, e outra equipe conseguiria fazer o deploy sem a pessoa que o construiu?

Se só uma ferramenta ou uma pessoa consegue publicar, você está preso.

0 de 19 respondidas

Como a nota funciona

Cada pergunta tem um peso fixo, e os pesos somam 100. Sua resposta ganha todo, parte ou nada desse peso; “Não sei” não ganha nada. Uma pergunta que não se aplica ao seu app fica de fora e as demais são reescalonadas para 100. Qualquer falha crítica limita a nota a 49. As regras são as mesmas no seu navegador e no nosso servidor, e não há IA no processo.

Peso de cada área, de 100
ÁreaPerguntasPeso
Segurança e acesso525
Segurança dos dados320
Releases e testes315
Operação no ar315
Pagamentos210
Privacidade e conformidade210
Propriedade15

Faixas: 90 ou mais é pronto para produção, 75 a 89 quase lá, 50 a 74 precisa de trabalho, abaixo de 50 não está pronto. O significado de cada termo está no nosso glossário.

Perguntas sobre a verificação

O que a verificação de prontidão para produção mede?

19 perguntas em sete áreas que decidem se um app é seguro para usuários reais: segurança e acesso, segurança dos dados, releases e testes, operação no ar, pagamentos, privacidade e conformidade, e propriedade. Cada resposta é pontuada contra um peso fixo, e as áreas somam 100.

Como a nota é calculada?

Cada pergunta tem um peso, e os pesos somam 100. Sua resposta ganha todo, parte ou nada desse peso. "Não sei" não ganha nada, porque, se você não pode dizer que está feito, a suposição segura é que não está. Uma pergunta que não se aplica ao seu app, como pagamentos quando você não cobra nada, fica de fora e as demais são reescalonadas para 100. Uma falha crítica, como uma chave service-role no navegador, limita a nota a 49. As mesmas regras rodam no nosso servidor, sem nenhuma IA envolvida.

Que nota conta como pronto para produção?

90 ou mais é pronto para produção, 75 a 89 é quase lá, 50 a 74 precisa de trabalho antes do lançamento, e abaixo de 50 não está pronto para usuários reais. Uma única falha crítica mantém o app abaixo de 50, não importa o que mais esteja no lugar.

Vocês guardam minhas respostas?

Não, a menos que você peça o relatório por e-mail. A nota é calculada no seu navegador. Se você pedir o relatório, guardamos seu e-mail, o nome e o endereço do app que você informar, suas respostas, sua nota, se você marcou a caixa para receber novidades, as tags de campanha do link e a página que trouxe você (nenhuma das duas se o seu navegador enviar Do Not Track ou Global Privacy Control), e um hash irreversível do seu endereço IP, por 24 meses. Enviamos o relatório uma vez e avisamos nossa equipe. Só enviamos qualquer outra coisa se você marcar a caixa. Nunca visitamos nem escaneamos o endereço do seu app.

É só para apps feitos no Lovable?

Não. Funciona para qualquer app feito com um construtor de apps com IA, como Lovable, Bolt, v0 ou Replit, ou feito à mão. Algumas perguntas citam o Supabase porque a maioria dos apps feitos com IA roda nele, mas as mesmas verificações valem para qualquer app com banco de dados, login e pagamentos.

O que devo corrigir primeiro?

Comece pelos três riscos que a verificação mostra. Falhas críticas vêm primeiro, depois as respostas que mais perderam pontos. Cada uma leva a uma definição em linguagem simples no nosso glossário. Se preferir que engenheiros corrijam, é isso que um plano da Plutonapps faz.

Prefere que engenheiros corrijam para você?

Você continua desenhando no Lovable. Os engenheiros da Plutonapps deixam o produto real seguro, testado e pronto para produção, por assinatura.

Ver os planos