App feita no Lovable: e agora, com clientes reais?

A empresa chega à conversa com a aplicação já feita. Foi construída em conversa com um modelo de IA, numa plataforma como a Lovable, funciona, mostra-se a clientes e já custou semanas de trabalho. A pergunta seguinte é sempre a mesma. Aguenta clientes reais lá dentro?

Este artigo responde a isso sem vender medo. Começa por corrigir a ideia errada mais comum, e só depois trata do que interessa mesmo.

O código já é seu. E a plataforma diz isso por escrito.

A primeira coisa que quase toda a gente nos diz é que precisa de reescrever a aplicação «para ter o código». Não precisa. A documentação da Lovable é explícita: «You own your code», e qualquer projeto pode ser sincronizado com o GitHub ou o GitLab a qualquer momento, clonado, alterado fora da plataforma e alojado onde quiser, sem restrição.

Vale a pena guardar esta distinção, porque muda o que se compra a seguir. Ter o código e ter uma aplicação em condições de ir para produção são dois problemas diferentes. O primeiro está resolvido de origem. O segundo não.

Então porque é que se reescreve?

Reescreve-se por causa daquilo que o código gerado não traz consigo. Um protótipo é feito para chegar depressa a alguma coisa que funciona no ecrã, e não para sobreviver a utilizadores mal-intencionados, a um ano de alterações ou a uma equipa nova. Vai à frente, mas leve. As razões que encontramos na prática, por ordem de frequência:

• Controlo de acessos à base de dados. É a falha número um, e a plataforma admite-o.
• Segredos no sítio errado. Chaves que deviam viver no servidor e acabam no que o browser descarrega.
• Ausência de testes. Sem testes, a primeira alteração séria parte alguma coisa que ninguém vê partir.
• Lógica de negócio no cliente. Regras de preço, de desconto ou de permissões escritas no ecrã, onde qualquer pessoa as contorna.
• Dívida de dependências. Bibliotecas fixadas em versões que já têm vulnerabilidades conhecidas.
• Tratamento de dados pessoais. Onde ficam, quem lhes acede, e o que se responde quando um titular exerce os direitos dele.

Note-se o que não está nesta lista: «o código está feio». Feio não é motivo.

Qual é a falha mais comum, em concreto?

Chama-se Row Level Security, ou RLS. As aplicações da Lovable assentam em Postgres através do Supabase, e o browser fala diretamente com essa base de dados usando uma chave pública. Essa chave é pública por desenho e não é o problema. O problema é o que está do outro lado dela.

O Supabase não deixa margem para dúvidas na sua própria documentação: «A table in an exposed schema without RLS is readable and writable by any role with a grant on it. Enable RLS on every table in an exposed schema.» Traduzindo para o que isso significa numa empresa: uma tabela sem esta proteção pode ser lida, às vezes até escrita, por quem abrir o site e souber onde carregar.

A segunda falha é prima desta: a chave de serviço. Sobre essa, a documentação é ainda mais direta: «It bypasses Row Level Security, so it must never leave your control», e nunca deve estar «a browser, even on localhost». Quando aparece no pacote que o browser descarrega, deixa de haver proteção nenhuma, por muito bem escritas que estejam as regras. Fica tudo aberto.

O que aconteceu no CVE-2025-48757, com os números certos

Existe uma vulnerabilidade registada e publicada sobre exatamente este ponto. Convém citá-la com rigor, porque anda muito número solto na internet, quase sempre em blogues de empresas que vendem o serviço de correção.

Os factos verificáveis, retirados da divulgação original de Matt Palmer: identificador CVE-2025-48757. Pontuação CVSS base: 8,26. Descoberta a 20 de março de 2025. Comunicada ao fornecedor no dia seguinte e publicada a 29 de maio de 2025. Afeta, segundo o autor, qualquer projeto Lovable com base de dados criado até 15 de abril de 2025. Um varrimento automático de 1645 projetos encontrou 303 pontos de acesso desprotegidos em 170 projetos, cerca de 10,3 por cento.

E agora a parte que quase ninguém cita, que é a ressalva do próprio autor: o varrimento analisou apenas páginas iniciais e não tentou entrar em zonas protegidas por autenticação. Ou seja, o número real pode ser maior. Ninguém o mediu. Aquele 10,3 por cento é uma fotografia de março de 2025 e não descreve o estado das aplicações de hoje. Quem o apresentar como se descrevesse está a exagerar.

A revisão de segurança é sua. Quem o diz é a plataforma.

Este é o ponto que sustenta tudo o resto, e não é opinião da RTC. Está na documentação da Lovable, que atribui a responsabilidade a quem constrói: «You are responsible for ensuring that your app meets the security requirements appropriate for its use case, especially if it handles sensitive data or performs critical functions.»

Sobre os verificadores automáticos que a plataforma oferece, a mesma documentação diz duas coisas seguidas: «These tools help identify common security issues, but they cannot guarantee complete security» e «These tools do not replace a thorough security review». No blogue oficial, a admissão é ainda mais útil para quem tem de decidir: a má configuração de RLS é apontada como a causa isolada mais comum de exposição de dados em aplicações assentes em Supabase.

Uma leitura honesta disto é simples. A plataforma faz o que promete, gera aplicações depressa e diz com todas as letras onde é que o trabalho dela acaba. A revisão a sério fica do lado de quem vai ter clientes lá dentro.

O que se verifica numa auditoria a uma aplicação gerada por IA

Área	O que se verifica
Acesso aos dados	RLS ativo em todas as tabelas expostas. Políticas que correspondem mesmo às regras do negócio.
Segredos	Nenhuma chave de serviço, token ou credencial no pacote entregue ao browser, nem no histórico do repositório.
Autenticação	Recuperação de palavra-passe, expiração de sessão, separação real entre perfis de utilizador.
Funções de servidor	Validação de entrada, limites de uso, autorização em cada função exposta.
Lógica de negócio	Regras críticas confirmadas no servidor.
Dependências	Inventário de bibliotecas, com as vulnerabilidades conhecidas por versão.
Dados pessoais	Que dados são recolhidos, onde ficam alojados, quem lhes acede, com que fundamento.
Continuidade	Cópias de segurança testadas, ambiente de testes separado do de produção, e um registo de todas as alterações feitas.
Propriedade	Repositório em nome da empresa, com a documentação necessária para outro fornecedor pegar nele.

Três caminhos, e como se escolhe entre eles

Reescrever tudo raramente é a resposta certa, e dizemo-lo antes de orçamentar. Há três saídas possíveis e a auditoria existe para saber qual delas se aplica.

Caminho	Quando faz sentido
Endurecer o que existe	A estrutura de dados está sã e as falhas são de configuração e de acessos. É o caso mais barato e acontece mais vezes do que se pensa.
Refazer o servidor, manter o ecrã	A interface serve e foi validada por utilizadores, mas as regras críticas estão no sítio errado. Aproveita-se o trabalho de desenho.
Reescrever de raiz	O modelo de dados não suporta o que a empresa precisa a seguir, ou há integrações com sistemas internos que o protótipo nunca previu.

Ninguém consegue dizer honestamente qual destes três se aplica sem ver o código. Quem der um preço de reescrita ao telefone está a adivinhar, e o risco desse palpite acaba sempre do lado do cliente.

E o RGPD, se a aplicação já tem utilizadores?

Se a aplicação recolhe dados de pessoas, as obrigações não esperam pela versão final. Contam já. Interessam três perguntas práticas: que dados são recolhidos e com que fundamento, onde ficam alojados fisicamente, e o que acontece quando alguém pede para ser apagado. A resposta a estas perguntas costuma estar por escrever num protótipo, porque não é isso que um protótipo serve para responder. Tratámos as obrigações reais das PMEs, sem mitos, num artigo dedicado ao RGPD.

Como a RTC trabalha nestes casos

Começamos sempre pela auditoria, entregue como documento próprio, com a lista de verificações da tabela acima, cada uma com o resultado e a gravidade. Esse documento é seu, mesmo que a seguir decida não avançar connosco ou entregar o trabalho a outra pessoa. Só depois se orçamenta o caminho. Com preço fechado.

A auditoria custa 750 € + IVA, com entrega em 5 dias úteis e âmbito escrito: até 15 tabelas e 10 funções de servidor. Acima disso damos preço próprio antes de começar. Nunca depois. Inclui o relatório, uma reunião de apresentação de 30 minutos e a reverificação dos pontos críticos depois de corrigidos, sem custo adicional.

Antes da auditoria há uma triagem gratuita de 45 minutos, onde olhamos para três coisas: se as tabelas expostas têm proteção ativa, se alguma credencial de servidor viajou para o browser, e se os perfis de utilizador estão mesmo separados. Caso a triagem mostre que está tudo em ordem, dizemos isso e não há auditoria nenhuma para lhe vender.

Marcamos consigo uma primeira reunião e entregamos proposta com preço fechado em 5 dias úteis, os mesmos prazos que praticamos em todo o desenvolvimento por medida. Sobre a propriedade, nada muda. A posição está publicada há muito e não muda por causa de quem gerou a primeira versão: o código é seu. Se ainda não assinou nada, vale a pena ler primeiro o que exigir num contrato de desenvolvimento, porque um contrato omisso é a forma mais comum de perder um código que se julgava próprio.

O que não prometemos

Não prometemos que a aplicação fica segura. Ninguém pode. Desconfie de quem prometer. Prometemos o método, o âmbito escrito das verificações e o prazo de entrega do relatório. Também não prometemos que a reescrita é sempre necessária, porque muitas vezes não é, e recomendar uma reescrita desnecessária seria a maneira mais fácil de faturar mais e servir pior.

Sobre a plataforma em si, também não alinhamos no exagero. A Lovable levou-o de uma ideia a uma aplicação funcional em semanas, o que há cinco anos exigia uma equipa e um orçamento. Isso não é pouco. O passo seguinte é que é outro trabalho, e a documentação da própria plataforma diz exatamente isso.

Perguntas frequentes

O código que a Lovable gera é mesmo meu?

Sim. Na documentação oficial lê-se «You own your code», com sincronização permanente para o GitHub ou o GitLab e liberdade para clonar, alterar fora da plataforma e alojar onde quiser. O que não vem incluído é a certeza de que esse código está pronto para produção.

Consigo saber se a minha aplicação tem dados expostos?

Consegue. Um técnico despacha isso depressa. Verifica-se se as tabelas expostas têm RLS ativo, se as políticas correspondem às regras reais do negócio e se alguma credencial de servidor viajou para o pacote que o browser descarrega. É a primeira coisa que fazemos numa auditoria.

Tenho mesmo de reescrever tudo?

Na maioria dos casos não. Quando o modelo de dados está são e as falhas são de configuração e de controlo de acessos, endurecer o que existe resolve, por uma fração do custo. A reescrita completa justifica-se quando a estrutura não suporta o que a empresa precisa de fazer a seguir.

Quanto tempo demora uma auditoria destas?

Depende do tamanho da aplicação e do número de tabelas e de funções expostas. Damos o âmbito e o prazo por escrito antes de começar, e não faturamos hora nenhuma antes de esse âmbito estar aceite.

A RTC trabalha com empresas fora de Bragança?

Sim. Este tipo de trabalho faz-se sobre o repositório e sobre os ambientes de alojamento, com reuniões por vídeo, e não depende de proximidade física. Temos clientes em várias zonas do país.

O passo seguinte

Preços destinados a empresas, acrescendo IVA à taxa legal em vigor.

Se tem uma aplicação construída desta forma e a dúvida é se aguenta clientes reais, o primeiro passo não tem custo: a triagem de 45 minutos, para perceber onde está e para onde quer ir. Fale connosco.