Até pouco tempo atrás, a primeira pergunta de quem queria criar um SaaS era “quem vai programar?”. Hoje o autocompletar do Google mostra outra coisa: “como criar um SaaS com IA”, “com Lovable”, “no Claude”, “sem código”. A barreira da tela caiu. Em uma tarde, um gerador de aplicações entrega cadastro, login, painel e um endereço publicado na internet.
O que não caiu foi a parte que não aparece na demo. Este guia percorre o roteiro de negócio que continua valendo, compara os três caminhos de construção e se detém no ponto que os tutoriais de “SaaS do zero” pulam: a regra que decide quem pode ler e gravar cada linha do banco. É ali que um caso real, registrado no banco oficial de vulnerabilidades dos Estados Unidos, mostra onde termina o trabalho da IA e começa o do dono.
O que é um SaaS, e o que muda quando a IA escreve o código?
SaaS (software as a service) é o software que o cliente usa pelo navegador ou pelo celular, sem instalar nada, pagando uma assinatura. Quem vende cuida de servidor, atualização, cópia de segurança e suporte. Quem compra paga enquanto usa. O modelo de receita recorrente é o que torna o negócio atraente, e também o que o torna exigente: o cliente reavalia a compra todo mês.
Um SaaS tem três camadas. A interface, que é o que o usuário vê. O banco de dados, onde ficam os cadastros, as transações e tudo o que o produto guarda. E as regras entre uma coisa e outra: quem pode entrar, o que cada pessoa enxerga, quem pode alterar o quê, quando a cobrança libera ou bloqueia o acesso.
Os geradores de aplicação com IA aceleram muito a primeira camada e montam a segunda com um clique, normalmente sobre um banco Postgres hospedado (o Supabase é o mais comum nessas ferramentas). A terceira camada é a que mais depende de entendimento do negócio, e é justamente a que a IA escreve com menos contexto. Ela não sabe, a menos que alguém diga com precisão, que o cliente A nunca pode ver a fatura do cliente B.
Como criar um SaaS do zero: qual roteiro não muda com a IA?
A IA encurta a construção, não as decisões. O roteiro que separa um produto que vende de um projeto que fica parado continua o mesmo, e cada etapa tem uma pergunta que precisa de resposta antes da próxima:
- Problema. Quem tem a dor, com que frequência, e quanto ela custa hoje? Um problema que aparece uma vez por ano raramente sustenta assinatura mensal.
- Validação. Converse com quem tem o problema antes de construir. A pergunta útil não é “você usaria?”, e sim “o que você faz hoje para resolver e quanto paga por isso?”.
- Escopo mínimo. Defina a menor versão que resolve o problema principal de ponta a ponta. Tudo o que não serve para provar a hipótese vai para depois.
- Construção. Escolha o caminho (IA, no-code ou código) pelo que o produto precisa guardar e proteger, não só pela velocidade.
- Cobrança. Plano, preço e meio de pagamento recorrente, com o gateway informando ao sistema quem está em dia.
- Métricas. Ativação, retenção mês a mês, cancelamento e receita recorrente. Sem elas, não dá para saber se o produto está melhorando.
O critério para decidir quando o MVP já provou o que precisava, e quando é hora de parar de acrescentar funcionalidade, está detalhado no artigo sobre o critério de parada do produto mínimo viável. Aqui o foco é outro: o que muda na etapa 4 quando quem escreve o código é uma IA.
Qual a diferença entre criar um SaaS com IA, com no-code e com código?
Os três caminhos chegam a um produto funcionando. A diferença está em quem escreve as regras de acesso, onde elas ficam e quem consegue revisá-las depois:
| Gerador com IA (Lovable, Bolt, Claude) | Plataforma no-code | Desenvolvimento com código | |
|---|---|---|---|
| Velocidade até a primeira tela | Horas | Dias | Semanas |
| Quem escreve a regra de acesso | A IA, a partir do que foi pedido no prompt | Quem configura, em telas de permissão da plataforma | O time, em código revisável |
| Onde a regra fica | No banco (políticas de RLS) e no código gerado | Dentro da plataforma | No servidor e no banco |
| Código exportável | Em geral sim | Depende da plataforma | Sim |
| Risco típico | Tabela sem política ou com política permissiva demais | Dependência da plataforma e da conta de uso | Prazo e custo maiores no início |
| Quando faz sentido | Validar a ideia com usuários reais, sem dado sensível | Ferramenta interna ou fluxo simples | Produto com dado sensível, cobrança e escala |
Comparativo elaborado pela Alliance Comunicação com base na prática de desenvolvimento de MVPs.
A linha que mais pesa é a segunda. Num gerador com IA, a regra de acesso nasce do prompt. Se o prompt não descreveu quem pode ver o quê, a IA preenche a lacuna com uma suposição, e suposição não é política de segurança. A conta de uso das plataformas no-code, que cresce depois que o app funciona, foi tratada no artigo sobre a conta que chega depois nas ferramentas no-code.
O que é Row Level Security e por que ela decide quem vê os dados?
Row Level Security (RLS, ou segurança em nível de linha) é um recurso do banco Postgres que filtra, linha por linha, o que cada usuário pode ler, inserir, alterar ou apagar. Em vez de confiar que a tela só mostra os pedidos do usuário logado, o próprio banco recusa entregar os pedidos dos outros.
Isso importa muito na arquitetura que os geradores usam. O navegador do usuário conversa direto com o banco, por uma API, usando uma chave pública que vai embutida no código do site. A chave é pública por desenho: qualquer pessoa que abra as ferramentas do navegador consegue vê-la. O que protege os dados, nessa arquitetura, não é a chave. É a política de RLS de cada tabela.
Daí saem duas regras que valem para qualquer SaaS sobre esse tipo de banco. Primeira: tabela sem RLS, em schema exposto, é tabela aberta. Segunda: a chave secreta pula todas as políticas, então se ela aparecer no código do navegador, todas as regras caem de uma vez. A IA pode escrever as políticas. Conferir se elas correspondem ao negócio é trabalho de quem conhece o negócio.
O que a CVE-2025-48757 mostrou sobre os SaaS gerados por IA?
CVE é o identificador público de uma vulnerabilidade, e o NVD (National Vulnerability Database), mantido pelo NIST, é o banco oficial do governo americano que as cataloga e pontua. Em 2025, uma entrada tratou exatamente do problema descrito acima, num gerador de aplicações com IA:
O detalhe que mais interessa a quem está criando um SaaS está na última frase. A entrada não foi simplesmente aceita: ela traz a marca de contestada, e o motivo da contestação é que a proteção dos dados é do cliente da plataforma. Não cabe a este artigo arbitrar a disputa. Cabe registrar o que ela significa na prática: nas duas versões da história, quem responde pelos dados do seu SaaS é você.
O pesquisador que registrou a falha publicou um relato com a cronologia e o tipo de dado exposto. Vale ler com a ressalva de que ele é profissional da Replit, plataforma que também gera aplicações com IA. É mais um motivo para cruzar o relato com a entrada oficial, que registra também a posição do fornecedor:
Dois pontos do relato merecem atenção. O primeiro: a seção de resolução do mesmo texto diz que não há correção disponível na plataforma e que a mitigação principal é revisar e criar as políticas de RLS em cada projeto. Ou seja, mesmo com ajustes do lado do fornecedor, o conserto acontece no banco de cada cliente. O segundo: o exemplo de “status de pagamento” alterável. Num SaaS, a coluna que diz quem pagou é a coluna que libera o acesso. Se o visitante consegue gravar nela, ele dá a si mesmo o plano pago.
De quem é a responsabilidade quando o app gerado vaza dados?
A posição do fornecedor, registrada na própria CVE, resume o arranjo de quase todas as ferramentas desse tipo: a plataforma entrega a ferramenta, e o cliente responde pelo que constrói com ela. Os termos de uso costumam dizer o mesmo com outras palavras. Para o cliente final do seu SaaS, isso nem entra em discussão: ele contratou a sua empresa, não o gerador que você usou.
No Brasil, quando a tabela aberta guarda nome, e-mail ou dado de pagamento de pessoas, o assunto entra na LGPD. Quem decide sobre o tratamento dos dados, ou seja, a empresa dona do SaaS, é quem precisa adotar medidas de segurança e lidar com o incidente se ele acontecer. Ter usado IA para escrever o código não muda o papel. O ponto de partida para organizar isso é saber quais dados o produto guarda e por quê, como explica o artigo sobre o inventário de dados que falta nas empresas.
A IA escreve a tela em uma tarde. A regra de quem vê qual linha continua tendo dono, e o dono é quem cobra a assinatura.
O que o gerador entrega e o que continua com você?
Uma forma simples de organizar o trabalho é separar o que a ferramenta acelera do que ela não tem como saber. A coluna da esquerda é a que aparece na demonstração. A da direita só aparece quando alguém tenta abrir o que não devia:
Nada disso exige abandonar a IA. Exige tratar o que ela gera como primeira versão, não como versão final. O mesmo raciocínio vale para o código gerado por IA em geral, tema do artigo sobre onde o vibe coding cabe e onde não cabe.
Como criar um SaaS com IA na prática, sem deixar o banco aberto?
O checklist abaixo é o mínimo antes de cadastrar o primeiro cliente pagante. Não substitui uma revisão de segurança completa, mas fecha as portas que a CVE-2025-48757 mostrou abertas.
1. Descreva as permissões antes de pedir as telas
Escreva, em português simples, quem pode ver e alterar cada tipo de dado: “o usuário vê só os próprios projetos”, “o administrador da conta vê os projetos da equipe”, “ninguém de fora vê nada”. Esse texto vai no prompt e, depois, vira o roteiro de conferência das políticas.
2. Habilite RLS em toda tabela, sem exceção
Abra o painel do banco e confira tabela por tabela, inclusive as que a IA criou para uso interno, como logs, convites e configurações. Tabela que ninguém lembra que existe é a que fica sem política. RLS habilitado sem política nenhuma bloqueia tudo, o que é seguro, mas quebra a tela; a solução é criar a política certa, nunca desligar o RLS.
3. Desconfie da política que libera tudo
Ter política não é o mesmo que ter a política certa. Uma regra que libera a leitura para qualquer usuário, sem condição, faz o painel funcionar e deixa a tabela aberta do mesmo jeito. Para dados de cliente, a condição costuma ser “esta linha pertence ao usuário logado” ou “à conta dele”.
4. Tire a chave secreta do navegador
Procure no código publicado qualquer chave que não seja a pública. A chave secreta, que ignora o RLS, só pode existir no servidor ou em funções do lado do servidor. Se ela já foi publicada alguma vez, troque-a: apagar do código não desfaz a exposição.
5. Deixe o pagamento ser gravado pelo servidor
O status de assinatura deve ser atualizado a partir do aviso do gateway de pagamento, recebido no servidor, e nunca por uma gravação que parte do navegador. Na tabela de assinaturas, o usuário pode no máximo ler a própria linha.
6. Teste como visitante anônimo e como outro cliente
Crie duas contas de teste e tente, com a conta A, abrir dados da conta B. Depois repita sem login nenhum. O teste que importa não é “a tela mostra o que deveria”, e sim “o banco recusa o que não deveria entregar”.
Quais são os erros mais comuns de quem cria SaaS com IA?
- Confundir chave pública com segurança. A chave que vai no navegador é pública por desenho. Quem protege os dados é a política do banco.
- Testar só o caminho feliz. O app funciona para quem usa direito. A falha aparece para quem modifica a requisição, e esse teste raramente é feito.
- Aceitar o aviso de “RLS ativo” como prova. O pesquisador da CVE observou que o verificador de segurança da plataforma conferia a existência de alguma política, não se ela correspondia à lógica do app.
- Guardar segredo em tabela. Chaves de API de terceiros numa tabela acessível ao navegador foram um dos tipos de dado expostos no caso Lovable.
- Misturar dado público e sensível na mesma linha. RLS filtra linhas inteiras. Se o perfil público e o dado de pagamento estão na mesma linha, quem lê um lê o outro.
- Deixar a cobrança no banco aberto. Status de pagamento gravável pelo cliente é plano pago de graça para quem souber editar uma requisição.
- Publicar e esquecer. Cada nova tabela que a IA cria numa iteração precisa passar pela mesma conferência.
Quanto custa criar um SaaS e quando vale chamar um time de desenvolvimento?
O custo de um SaaS tem três partes: construir, manter no ar e manter seguro. A IA derrubou a primeira, mas não as outras duas. Um gerador cobra assinatura pela ferramenta; o banco e a hospedagem cobram por uso; o gateway cobra por transação. E a revisão de segurança cobra horas de alguém que entende o que está olhando. Em vez de uma tabela de preços que mudaria em semanas, vale olhar o que cada fase exige:
| Fase do produto | Caminho que costuma bastar | O que não pode faltar | Sinal de que é hora de time técnico |
|---|---|---|---|
| Validação com poucos usuários convidados | Gerador com IA ou no-code | Dados fictícios ou mínimos; RLS em todas as tabelas | Usuários pedem para guardar dado real de clientes deles |
| Primeiros clientes pagantes | Gerador com IA revisado por quem conhece banco | Checklist completo deste artigo; cobrança via servidor | Mais de um perfil de acesso por conta (equipe, administrador) |
| Crescimento | Código revisável, com ou sem IA na escrita | Revisão de segurança, testes automatizados, plano de incidente | Integrações, dado sensível, contrato com cliente corporativo |
| Cliente corporativo | Time de desenvolvimento dedicado | Questionário de segurança respondido com evidência | O cliente pede relatório de teste de invasão |
Referência elaborada pela Alliance Comunicação a partir de projetos de MVP e SaaS.
Para apps publicados nas lojas da Apple e do Google, há ainda o prazo de revisão das lojas, tratado no artigo sobre quanto custa criar um aplicativo. E quando a decisão é entre continuar no gerador ou reconstruir com time próprio, o serviço de desenvolvimento de MVP da Alliance começa justamente pela revisão do que já foi gerado: o que aproveita, o que reescreve e o que precisa ser fechado antes do próximo cliente.
O que muda para um micro SaaS?
Micro SaaS é o SaaS de nicho, tocado por uma pessoa ou por uma equipe pequena, com custo baixo e foco num problema estreito. É exatamente o perfil de quem mais usa geradores com IA, e por isso o perfil mais exposto ao problema deste artigo: não há ninguém no time cuja função seja olhar o banco.
A boa notícia é que um micro SaaS costuma ter poucas tabelas. Revisar dez tabelas com o checklist acima leva uma tarde. O erro é achar que, por ser pequeno, o produto não interessa a ninguém. A varredura do caso Lovable não escolheu alvos pelo tamanho: percorreu, de forma automática, todos os projetos de uma vitrine pública.
Por onde começar hoje
- Escreva em uma página o problema, quem paga por ele e como você vai saber que a solução funcionou.
- Liste os dados que o produto vai guardar e marque quais são pessoais ou financeiros.
- Descreva as permissões em português simples antes de pedir as telas à IA.
- Gere a primeira versão e confira RLS e política tabela por tabela.
- Procure chaves no código publicado e mova a cobrança para o servidor.
- Teste com visitante anônimo e com um segundo cliente antes de aceitar o primeiro pagamento.
Criar um SaaS ficou mais rápido, e isso é bom: mais ideias chegam à frente de clientes reais. O que não mudou é que o cliente confia os dados dele ao seu produto, não à ferramenta que o gerou. Se quiser enxergar onde o SaaS se encaixa no plano de marketing e de vendas da empresa, o diagnóstico de marketing gratuito organiza as prioridades na ordem certa.