Como criar um SaaS com IA sem quebrar quando crescer

Hoje é possível chegar muito mais rápido a algo que parece um produto. Tela, login, banco, formulário, dashboard, pagamento, deploy: builders com IA e agentes de código comprimiram semanas de trabalho em dias. Essa mudança é real e excelente.

O problema é confundir "conseguimos construir rápido" com "sabemos o que precisa continuar verdadeiro quando isso tiver clientes". É aí que muitos SaaS começam a apertar. Não porque a IA escreveu código ruim, mas porque a primeira versão respondeu "isso funciona?", e alguns meses depois o produto precisa responder perguntas muito diferentes: esse dado pertence a quem? Quem pode fazer esta ação? O que acontece quando o pagamento falha? Isso continua rápido com cem mil registros? Como sabemos que uma operação aconteceu apenas uma vez?

A tese deste texto cabe numa frase: IA tornou construção mais barata, e não eliminou arquitetura de produto. O que muda é a ordem em que as decisões aparecem, e o custo de não saber quais decisões foram adiadas.

O que a IA mudou de verdade

O ganho mais interessante não é "agora não precisamos de desenvolvedores". É que agora dá para colocar uma hipótese diante de alguém muito mais cedo. Você constrói uma direção, mostra, usa, descobre que estava errada e joga fora sem ter investido meses. Errar ficou barato, e isso muda a economia de criação de software.

O que não muda: uma aplicação funcionando continua não sendo evidência de que existe um produto. Um dashboard bonito com login e CRUD prova que a aplicação funciona. Não prova que alguém precisa daquilo, muito menos que alguém pagará.

E quando construir fica barato, adicionar também fica barato, então o escopo cresce sem oferecer resistência. Vamos colocar dashboard, já faz upload também, podemos adicionar IA, e equipe, e notificações, e três planos. Em poucos dias existe bastante software e pouca evidência. Um MVP útil não é uma versão menor de todas as funcionalidades do futuro. É a menor versão que permite observar se alguém tem o problema, se a solução ajuda e se o valor é suficiente para a pessoa voltar ou pagar. O critério é existir uma cadeia clara entre problema, ação e valor. Todo o resto precisa justificar por que está entrando antes de essa hipótese ser respondida.

Uma disciplina prática ajuda desde o primeiro dia: não peça o produto inteiro num único prompt. Pedir "um SaaS completo com login, dashboard, equipes, assinatura, permissões e analytics" devolve algo impressionante e um pacote de decisões tomadas juntas, sem que ninguém saiba quais. Quando surge um problema, fica difícil isolar a causa, e a IA também não sabe magicamente qual decisão estava errada. Evoluir em fatias verificáveis, testando entre elas, não é uma regra técnica. É uma regra de redução de incerteza.

O mesmo raciocínio vale para as ferramentas. Builder com IA, banco gerenciado, autenticação pronta, serviço de pagamentos: cada abstração deveria tirar trabalho que ainda não diferencia o produto sem esconder algo que já precisa ser controlado. Se autenticação não é diferencial, solução pronta faz sentido. Se uma regra financeira crítica está sendo executada de um jeito que ninguém do time entende, a abstração já está cobrando um preço. É o trade-off tratado em O que é no-code e quando ele para de servir. E vale versionar desde cedo: quando o produto recebe alterações de builder, agente, desenvolvedor e fundador ao mesmo tempo, ter uma fonte versionada é o que impede que ninguém saiba mais qual versão é a verdadeira.

O primeiro limite: a fronteira dos dados

A aplicação parece perfeita. Cliente A entra e vê os próprios registros. Cliente B entra e vê os próprios registros. Só que existe uma pergunta mais importante: o servidor ou o banco impedem A de acessar os registros de B, ou a interface simplesmente nunca mostrou o ID certo? Essa diferença é enorme, e segurança de dados não pode depender de o frontend ser educado.

Se a aplicação usa a Data API do Supabase, por exemplo, a segurança envolve pelo menos duas camadas: grants, que determinam quais operações um papel pode executar sobre um objeto, e Row Level Security, que determina quais linhas aquele papel pode acessar. A documentação recomenda usar as duas em objetos expostos. Uma tabela em schema exposto sem RLS pode ficar acessível para qualquer role com o grant correspondente, e adicionar uma policy não remove grants existentes. O teste real não é "o botão aparece para o usuário errado?". É: se esse usuário fizer a requisição diretamente, o banco permite?

E RLS ligada não significa RLS certa. Uma policy pode permitir linhas demais, confiar num campo manipulável, proteger select e esquecer update, ou usar uma relação incorreta. A documentação do Supabase recomenda testar policies justamente porque uma regra permissiva demais devolve dados que não deveria sem produzir nenhum erro. Em SaaS multi-tenant, a policy precisa representar a relação real entre usuário, organização e recurso. Se o modelo de relacionamento estiver errado, a policy apenas formaliza o erro. Como estruturar esse modelo é assunto de multi-tenant: como isolar os dados de cada cliente.

Dois desdobramentos do mesmo problema merecem registro. Primeiro, ownership: não confie em IDs enviados pelo cliente para definir a quem um registro pertence. O cliente deveria pedir "crie este recurso", e o backend deveria derivar do contexto autenticado se aquele usuário realmente pode criá-lo ali. Segundo, permissão: no MVP, "se role é admin, mostra botão" resolve. Depois entram manager, operador, financeiro e suporte interno, e a regra passa a existir na sidebar, na tela, na API, no banco e na função ao mesmo tempo. Cada feature nova precisa lembrar de todas, e você já não tem um sistema de autorização, tem várias condições tentando representar a mesma política. Não é preciso construir RBAC enterprise no primeiro fim de semana. É preciso não confundir "escondemos o botão" com "implementamos autorização". O modelo que evita essa dívida está em permissões e papéis num SaaS.

Cobrança é o teste perfeito da diferença entre demo e produção

O padrão que um gerador entrega quando ninguém especifica é aparentemente lógico: usuário paga no Checkout, é redirecionado para a página de sucesso, e a aplicação libera o plano. Funciona na demonstração. A documentação da Stripe é explícita em desaconselhar: não dependa apenas da página de retorno para liberar acesso, porque o cliente pode concluir o pagamento e nunca carregar aquela página. Para garantir o processamento, a orientação é usar webhooks, com checkout.session.completed como evento central e checkout.session.async_payment_succeeded para formas de pagamento com confirmação posterior.

E o webhook pode chegar mais de uma vez. A própria Stripe documenta que a função de liberação pode ser chamada múltiplas vezes, inclusive de forma concorrente, para a mesma sessão. O código precisa receber "faça X" duas vezes e produzir X uma vez. É idempotência aplicada à operação, e sem ela um webhook repetido concede crédito em dobro ou executa duas operações sem que o usuário tenha feito nada de errado. A internet produz repetição suficiente sozinha.

O terceiro degrau é o estado. Uma assinatura na Stripe tem oito estados possíveis, não dois: incomplete, incomplete_expired, trialing, active, past_due, canceled, unpaid e paused. A Stripe mantém o estado financeiro; seu produto precisa decidir o que cada estado significa para a experiência. Pagamento falhou: bloqueia na hora, mantém acesso por alguns dias, permite leitura e bloqueia criação? Quem recebe o aviso? Cliente cancelou: o acesso vale até o fim do período pago, e os dados ficam recuperáveis por quanto tempo? E existe o caso que quase ninguém mapeia: se a primeira fatura não for paga em 23 horas, a assinatura vai para incomplete_expired, estado terminal em que a fatura aberta é anulada e nenhuma nova é gerada. Um SaaS que só conhece "ativa" e "cancelada" está recebendo do backend uma situação que a interface não sabe explicar, e o resultado vira acesso incorreto, tela contraditória ou ticket.

Existe também o erro simétrico: copiar os oito estados da Stripe para o banco e amarrar toda a experiência neles. Seu produto pode precisar de um modelo próprio de acesso, algo como teste, ativo, período de tolerância, restrito e encerrado, mapeando os eventos do processador para esses estados. Processador muda, um segundo meio de cobrança pode entrar, e acesso e pagamento nem sempre são a mesma coisa. Integração fornece informação. Ela não deveria determinar a linguagem interna do produto. O desenho completo dessa camada está em cobrança por assinatura sem perder pagamento.

Estados, volume e o segundo usuário

Builders são muito bons em criar o caminho esperado: usuário clicou, requisição funcionou, dado apareceu. Produto real vive nos outros caminhos. E se não houver dados? Se carregar por dez segundos? Se o usuário clicar duas vezes? Se a integração estiver fora, o pagamento estiver processando, a pessoa perder a permissão no meio da tarefa, o recurso já tiver sido excluído? São estados, e estado é uma das maiores diferenças entre demo e produto.

O volume expõe a segunda camada. Durante o desenvolvimento existem doze registros e tudo voa. Com quinze mil, a tabela leva segundos para abrir, e a causa costuma ser alguma combinação de buscar tudo, filtrar no frontend, não paginar e calcular agregações a cada renderização. Nada disso é exclusivo de IA: é o comportamento normal de decisões feitas para um volume e levadas para outro. A pergunta útil não é "quantos usuários o SaaS suporta", porque cem usuários podem gerar milhões de registros. É qual volume passa pelas operações mais importantes. Esse é o número que testa a arquitetura, e é também o que muda a interface: a tela que parecia limpa com seis transações precisa de busca, filtro, paginação, ações em lote e densidade quando a conta real tem milhares de registros com nomes parecidos.

E então aparece o segundo usuário. No começo existe "o usuário". Depois administrador, operador, financeiro, auditor. Essa evolução é o padrão em B2B, e o problema não é adicionar um item num dropdown de role: cada papel pode mudar home, navegação, permissão, ações e prioridade da informação. Uma arquitetura criada para "um usuário logado" começa a carregar exceções por todo lado. Quanto antes o produto percebe que papel é parte do modelo, menos precisa remendar a interface depois.

A IA também muda o custo da dívida

Antes, uma solução improvisada podia ser evitada porque demoraria muito para implementar. Hoje o agente responde "consigo fazer" e faz. Aparecem mais tabelas, mais automações, mais condições, mais componentes, e a aplicação cresce mais rápido do que o time consegue absorver as decisões que ela acumula. O limite deixa de ser "conseguimos implementar?" e passa a ser "ainda conseguimos explicar como isso funciona?".

Não existe número mágico de clientes que marca a mudança de fase, mas os sinais são claros: o time diz "tenho medo de mexer nisso", ninguém sabe por que algo funciona assim, toda feature quebra outra, o suporte conhece regras que Produto não conhece. Isso não significa que a primeira arquitetura foi um erro. Talvez ela tenha cumprido perfeitamente o trabalho de chegar até aqui. Arquitetura de validação não precisa virar arquitetura de escala, e reconhecer a transição é mais barato que negá-la.

O erro do outro lado é reescrever tudo porque chegaram dez clientes. Quase nunca é necessário. Dá para extrair autorização, billing, uma integração ou uma tabela problemática, reorganizar permissões sem reescrever o frontend, e continuar usando o builder onde ele ainda funciona bem. Crescer não é sinônimo de reconstrução completa. É assumir mais controle apenas onde a abstração deixou de ser suficiente.

O instrumento para decidir onde é uma revisão deliberada, feita quando o SaaS começa a ter receita. Ela cabe numa tarde de perguntas: quem é dono de cada entidade e existe isolamento real? As regras de acesso estão protegidas na camada de dados ou só na interface? Quais estados realmente existem em pagamento, assinatura, integração e importação? O que acontece se um webhook chegar repetido ou fora de ordem? Quais consultas sofrem primeiro quando os dados multiplicarem? Se uma operação crítica falhar às 3h, como alguém descobre? O que pode ser revertido, e o que exige backup e trilha de auditoria? O objetivo não é concluir que tudo precisa ser refeito. É descobrir onde o risco cresceu mais rápido que o produto.

O que adiar e o que não adiar

Se ainda não existe evidência de demanda, gastar semanas com arquitetura para milhões de usuários, RBAC granular, observabilidade enterprise, design system completo ou dez integrações é escalar uma hipótese não validada, que é uma forma sofisticada de desperdiçar. Primeiro descubra se vale preservar. Depois descubra como preservar. Isso vale inclusive para desenhar: na validação, escrever um prompt e testar no navegador pode ser mais rápido que prototipar. Depois, fluxos complexos, permissões e estados ficam caros demais para experimentar direto em produção, e prototipar volta a ser barato em relação a construir. A pergunta nunca é "Figma ou IA". É qual a forma mais barata de reduzir a incerteza atual.

Mas algumas decisões não são adiáveis, porque certas falhas não são aprendizado barato:

• segredos nunca no frontend;

• autorização real para dados sensíveis, verificada no servidor ou no banco;

• ownership claro das entidades;

• webhook verificado;

• operações financeiras idempotentes;

• backup adequado ao risco;

• dados de produção separados de teste quando clientes reais entram.

Não porque o MVP precise parecer um banco. Porque vazamento, dinheiro duplicado e cliente errado vendo informação não são hipóteses que se testa. A velocidade deixa de compensar quando o experimento coloca terceiros em risco.

O produto não precisa nascer pronto para o futuro. Precisa saber quando mudou de fase.

Essa distinção evita os dois extremos: construir a arquitetura perfeita antes de saber se alguém quer, e remendar para sempre porque continua funcionando. O primeiro gasta antes da hora. O segundo acumula risco depois da hora. O caminho melhor é construir rápido com consciência do que foi simplificado. "Usamos um único papel porque estamos validando com dez empresas" é uma ótima decisão de fase. O problema é esquecer que era de fase e tratá-la como lei permanente do produto.

A IA acelera implementação, refatoração, prototipagem e testes. O que continua sendo responsabilidade do produto: que problema vale resolver, qual comportamento está correto, quem deveria ter acesso, que risco é aceitável, o que o cliente deveria entender, o que acontece quando algo dá errado. O agente implementa a resposta em minutos. Alguém ainda precisa decidir qual resposta implementar. Um SaaS construído com IA não aguenta o crescimento por ter usado menos IA. Aguenta quando o time reconhece que velocidade de implementação e qualidade das decisões são problemas diferentes, usa a primeira para aprender rápido, e aumenta o rigor sobre as decisões quando elas ficam caras de errar.

É nessa segunda fase que a Uxbrand costuma entrar. Enquanto existe só hipótese, sem cliente e sem receita, construa com IA, coloque na mão das pessoas e aprenda barato. Quando já existe operação e as decisões começam a se cruzar, com permissão afetando navegação, billing afetando acesso, volume afetando interface e integração criando estados, fazer mais telas deixa de resolver sozinho. O produto precisa organizar as decisões que acumulou enquanto crescia, e esse é o trabalho que fazemos em SaaS, fintechs e plataformas B2B.

Para a mesma mudança vista pelo lado de custo e escopo, vale continuar por Quanto custa criar um produto SaaS.

Fontes

Stripe. Fulfill orders. A documentação atual do Checkout orienta que fulfillment não dependa apenas da página de retorno, porque o cliente pode concluir o pagamento sem chegar à landing page. Webhooks são necessários para garantir o processamento dos pagamentos. A documentação utiliza checkout.session.completed e, para formas de pagamento postergadas, checkout.session.async_payment_succeeded.

A mesma documentação ressalta que uma função de fulfillment pode ser chamada várias vezes, inclusive concorrentemente, para a mesma Checkout Session, e deve garantir que a operação seja executada apenas uma vez. Também orienta verificar payment_status antes do fulfillment.

Stripe. Using webhooks with subscriptions. Integrações de assinatura precisam tratar eventos assíncronos por webhook, incluindo falhas de pagamento e mudanças de status.

Stripe. The Subscription object. O campo status possui atualmente oito valores possíveis: incomplete, incomplete_expired, trialing, active, past_due, canceled, unpaid e paused.

Para subscriptions com collection_method=charge_automatically, uma falha no primeiro pagamento pode deixar a assinatura em incomplete. Se a primeira invoice não for paga dentro de 23 horas, ela passa para incomplete_expired, estado terminal em que a invoice aberta é anulada e novas invoices não são geradas.

Supabase. Row Level Security e Securing your API. A Data API utiliza grants para determinar quais operações um papel pode executar sobre um objeto e policies de Row Level Security para determinar quais linhas podem ser acessadas ou modificadas. A documentação recomenda aplicar ambos adequadamente nos objetos expostos.

Uma tabela em schema exposto sem RLS pode ser lida ou modificada por roles que possuam os grants correspondentes. Criar policies não remove automaticamente grants existentes.

A documentação também recomenda testes para policies. Uma regra excessivamente permissiva pode retornar linhas que não deveria sem produzir erro, enquanto uma excessivamente restritiva pode simplesmente não retornar dados.