Retomar um projeto no-code ou vibe coded: por onde começar

Construíste o teu produto sozinho. Com o Lovable, com o Bolt, com o Claude ou o Cursor. Não escreveste uma única linha de código e, mesmo assim, funciona. As pessoas usam-no. Talvez já estejas a cobrar. E depois, devagar, começa a estalar. Uma página que rebenta. Um cliente que vê os dados de outro. Uma alteração que parte três outras. Se andas a perguntar-te como retomar um projeto no-code ou vibe coded sem deitar tudo fora, este artigo é para ti.

Boa notícia primeiro: não fizeste nada de mal. Validaste uma ideia depressa e barato, e é precisamente para isso que estas ferramentas servem. O problema não é teres feito vibe coding. O problema é quereres fazer passar um protótipo por um produto sem a transição que fica no meio dos dois.

Já contei em detalhe o que encontro quando retomo um projeto vibe coded: as surpresas por baixo do capô, a segurança ausente, a base de dados feita à pressa. Aqui não vou repetir o diagnóstico. Vou dar-te os passos a seguir. Concretamente, por onde começar quando decides voltar a assumir o controlo.

O clique: "só há uns bugs"

A frase que mais oiço: "Fiz tudo com IA, sem escrever uma única linha de código. Só há uns bugs para corrigir."

Esses uns bugs são, em geral, a ponta do icebergue. Não porque trabalhaste mal, mas porque uma ferramenta que gera código para ir depressa não gera código pensado para durar. Otimiza para que funcione agora, no teu ecrã, com os teus dados de teste. Não para cem utilizadores, não para os dados reais dos teus clientes, não para o dia em que estiveres ausente.

O clique é aquele momento em que sentes que já não te atreves a mexer no teu próprio produto. Em que cada alteração te causa stress. Se tens medo do teu código, isso não é um pormenor técnico, é um sinal de negócio. Quer dizer que a tua capacidade de evoluir está bloqueada. É a boa altura para voltar a assumir o controlo, não daqui a seis meses.

Passo 1: fazer um balanço honesto

Antes de reparar seja o que for, tens de saber o que tens realmente. Não a impressão que tens dele, a realidade.

Faz-te estas perguntas e escreve as respostas preto no branco:

• Quem usa o produto, e para quê? Quantas pessoas, que funções são de facto usadas, quais estão mortas.
• Que dados manipulas? Emails, palavras-passe, dados de saúde, dados de pagamento? Quanto mais sensível, mais sobe o risco, sobretudo à luz da Lei de Proteção de Dados suíça (nLPD).
• O que é que parte, e com que frequência? Anota cada bug durante duas semanas. Vais depressa ver os padrões.
• O que te faz perder dinheiro ou clientes hoje? É isso que prioriza todo o resto.

Este balanço não precisa de ser técnico. Precisa de ser lúcido. É o documento que vais entregar ao teu parceiro técnico no dia em que arranjares um, e é isso que vai poupar dias de análise.

Passo 2: garantir o acesso ao código e aos dados

Antes mesmo de falar de qualidade, tens de garantir uma coisa: que és mesmo dono do teu produto.

É o ponto cego número um dos projetos no-code. Construíste no Lovable ou no Bolt, e tudo vive dentro da plataforma. Pergunta-te a sério:

• Tens acesso ao código-fonte, em claro, exportável? Não é só a pré-visualização dentro da ferramenta. O código a sério, na tua própria conta GitHub.
• A quem pertence a base de dados? Onde estão guardados os dados dos teus clientes, sob que conta, com que acessos.
• Quem tem as chaves? Contas, palavras-passe, chaves de API, nome de domínio. Se estiver tudo na conta de um freelancer ou de um sócio que saiu, tens um problema ainda antes do primeiro bug.

Enquanto não controlares o teu código e os teus dados, não és dono do teu produto, estás a alugá-lo. Recupera esses acessos agora, enquanto está tudo bem. Mete-os num gestor de palavras-passe decente. Este passo não custa nada e protege-te da pior das catástrofes.

Passo 3: priorizar pela ordem certa

Quando se retoma um projeto vibe coded, a tentação é querer refazer tudo de uma vez. Má ideia. Há uma ordem que funciona, porque vai do mais perigoso ao mais confortável.

1. A segurança primeiro

Isto não é negociável. Uma falha de segurança não é um bug entre outros, é um risco que te pode custar a reputação e pôr-te em infração com a nLPD. O caso mais frequente que vejo: qualquer utilizador pode aceder aos dados de qualquer outro, porque a IA gerou uma autorização de fachada. Isto verifica-se sempre em primeiro lugar.

2. A base de dados a seguir

É a coluna vertebral do teu produto. Se a estrutura dos dados estiver torta, tudo o que construíres por cima fica inclinado. As ferramentas de IA adoram duplicar dados, esquecer as relações, guardar tudo a granel. Pôr a base em ordem cedo é poupar-te uma reconstrução dolorosa mais tarde.

3. A arquitetura por último

Assim que está seguro e os dados estão sãos, olhamos para como o código está organizado para que se torne agradável de evoluir. É a parte que te devolve velocidade. Mas vem depois, não antes.

O erro clássico é começar pela estética do código ou pelas novas funcionalidades, deixando a segurança para mais tarde. Mais tarde é o dia da fuga de dados.

Passo 4: reparar ou reconstruir?

A grande pergunta. E a resposta honesta é: depende, mas menos vezes do que se pensa.

Reconstruir de raiz é sedutor. É limpo, é novo. Também é demorado, caro, e perdes tudo o que o teu produto atual já aprendeu no terreno. Na maioria dos casos que retomo, reparamos e consolidamos em vez de deitar tudo fora.

Eis como decidir de forma simples:

• Repara se o produto já presta serviço, se a lógica de negócio é boa, e se os problemas estão concentrados na segurança, nos dados e na organização. É o caso mais comum.
• Reconstrói parcialmente se uma parte específica está podre ao ponto de ser intocável, mas o resto aguenta-se. Isolamos e refazemos só esse pedaço.
• Reconstrói mesmo de raiz só se a ideia mudou tanto desde o protótipo que já não estás a construir o mesmo produto. Aí, partir do zero faz sentido.

O objetivo não é ter um código perfeito. O objetivo é industrializar um projeto no-code o suficiente para que aguente a carga, seja seguro, e para que o possas fazer crescer sem ter um nó no estômago.

Passo 5: quem envolver, e quando

Não és obrigado a delegar tudo. Mas há um momento em que um olhar técnico de fora te faz poupar imenso tempo.

Envolve um parceiro técnico quando:

• Manipulas dados sensíveis e não tens a certeza de que estão protegidos.
• Utilizadores reais dependem do produto e uma falha te custa dinheiro.
• Sentes que passas mais tempo a reparar do que a avançar.

Aquilo que tu trazes é insubstituível: a visão do produto, o conhecimento dos teus clientes, o balanço que escreveste no passo 1. Aquilo que um bom parceiro traz é a transformação do protótipo em algo sólido, sem te despojar do teu produto. O bom parceiro explica-te, transmite-te os acessos, deixa-te mais autónomo do que antes. Não o contrário. Se quiseres perceber o que se esconde mesmo por baixo do capô, também falo disso em o que o teu dev não te diz.

Continua a usar o Lovable, o Bolt, o Cursor ou o Claude para prototipar as tuas próximas ideias. Estas ferramentas são geniais para isso. O que mudas é apenas o passo seguinte: a transição entre "funciona no meu ecrã" e "é um produto a sério".

Resumo: os teus passos a seguir

Se só ficares com uma coisa, fica com esta ordem:

1. Balanço honesto do que tens realmente.
2. Garantir o acesso ao teu código e aos teus dados.
3. Priorizar: segurança, depois base de dados, depois arquitetura.
4. Decidir reparar ou reconstruir, reparando na maioria das vezes.
5. Envolver um parceiro técnico na altura certa.

Retomar um projeto no-code ou vibe coded não é admitir um fracasso. É passar à etapa seguinte. É o sinal de que a tua ideia funcionou com força suficiente para merecer fundações sólidas.

Se o teu projeto no-code já não se aguenta e não sabes por onde começar, ofereço uma auditoria gratuita. Olho para o teu produto, digo-te honestamente onde estás, segurança, dados, arquitetura, e o que é preciso fazer em prioridade. Sem compromisso, sem jargão. É exatamente esse o propósito da minha oferta Do protótipo ao produto.