De quem é o código quando uma empresa ajuda a colocar seu app em produção

Um medo recorrente de quem construiu um protótipo sozinho com Lovable, Cursor, n8n ou Claude aparece assim que surge a ideia de contratar ajuda para colocar o projeto em produção: será que o código continua sendo meu? A pergunta faz sentido. Quem passou semanas conversando com a IA, testando, ajustando prompt até o app funcionar, sente que aquilo é seu de um jeito pessoal, e desconfia de qualquer empresa de fora que vá mexer nisso. O problema é que essa desconfiança costuma mirar no alvo errado.

O mito: pedir ajuda significa ficar refém de quem ajudou

A crença é a seguinte: se uma empresa entra para revisar segurança, arrumar arquitetura e colocar o app no ar, ela passa a controlar o projeto, e sair dessa relação depois vira caro ou impossível. É uma crença compreensível, porque existe um histórico real de fornecedor de tecnologia que constrói de um jeito difícil de sair, de propósito ou por descuido. Mas propriedade de código não é uma questão de quem ajudou a construir. É uma questão de onde o código mora, quem tem as chaves de acesso e o que está escrito no contrato.

Onde essa crença falha

Um protótipo feito com IA já nasce, quase sempre, com o código gerado dentro da própria ferramenta, muitas vezes sem repositório próprio nem controle de versão de verdade. Quando isso acontece, quem construiu já está numa posição mais frágil do que imagina, e o fornecedor que precisa se preocupar em resolver não é a empresa que vai ajudar depois, é a plataforma de vibe coding que hospeda o projeto desde o início. Corrigir isso é justamente o primeiro passo de qualquer trabalho sério de profissionalização: tirar o código de dentro de uma ferramenta fechada e colocar num repositório que o cliente controla.

A partir daí, três coisas concretas decidem de quem é o código, e nenhuma delas depende de quem prestou o serviço.

• Em que conta está o repositório. Se o código mora numa organização do GitHub ou GitLab que pertence ao cliente, com o próprio cliente como administrador, a propriedade é dele, independente de quem escreveu a última linha.
• Em que conta está a infraestrutura. Servidor, banco de dados, domínio e provedor de nuvem precisam estar em conta e cobrança do cliente, não numa conta da empresa contratada usada "por conveniência" enquanto o projeto roda.
• O que o contrato diz sobre entrega. Um contrato de desenvolvimento sob medida bem escrito transfere a propriedade intelectual do que foi construído para o cliente, com exceção clara do que for ferramenta interna genérica do próprio fornecedor, reaproveitada entre projetos diferentes.

Onde a dependência real se esconde

Existe uma forma de ficar refém que não tem nada a ver com quem é dono do repositório: lógica de negócio importante escondida dentro de um serviço de terceiro que só o fornecedor sabe configurar, sem documentação de como funciona por dentro. Um app pode ter o código inteiro na conta do cliente e, mesmo assim, ser impossível de manter sem quem construiu, porque a regra que decide o preço, a comissão ou o fluxo de aprovação vive espalhada em automações que ninguém documentou. Portabilidade de verdade exige as duas coisas juntas: o código na sua conta e o entendimento de como ele funciona registrado em algum lugar que outra pessoa consiga ler.

É por isso que a pergunta certa não é "o código vai continuar meu". Quase sempre vai, se as três condições acima estiverem em ordem desde o começo. A pergunta certa é "se eu precisar trocar de fornecedor amanhã, outra empresa consegue pegar esse projeto e continuar sem reconstruir do zero". Essa segunda pergunta é a que separa uma parceria de uma dependência.

O que checar antes de contratar quem vai profissionalizar o projeto

• O repositório fica, ou passa a ficar, numa organização sua, com você como administrador desde o primeiro commit revisado.
• A infraestrutura de produção, servidor, banco de dados e domínio, é aberta em nome da sua empresa, não numa conta do fornecedor.
• O contrato deixa por escrito que a propriedade intelectual do que for construído sob medida é sua.
• Existe documentação mínima da arquitetura e das automações críticas, e não só do código-fonte em si.
• Nenhuma credencial de acesso ao projeto existe apenas na cabeça ou no computador pessoal de quem prestou o serviço.

Por que isso não é sobre desconfiar de quem ajuda

Nada disso significa tratar quem vai profissionalizar o projeto como adversário. Significa entender que soberania sobre a própria tecnologia, código, dados e lógica de negócio sob controle da empresa que os usa, não é um favor que um fornecedor concede, é uma condição que se verifica antes de assinar. Uma empresa séria de engenharia não tem motivo para resistir a nenhum dos cinco pontos acima, porque nenhum deles limita o trabalho de arrumar o projeto. Eles só limitam a possibilidade de alguém, por acidente ou por má-fé, construir uma dependência que não deveria existir.

Na Atlaas, o princípio que guia o Construa com IA é esse: o protótipo é seu, e a produção segura continua sendo sua, com a gente entrando para dar a fundação que faltava, não para tomar o lugar de dono do projeto. Se a sua empresa está perto de colocar cliente de verdade dentro de um app construído com IA e quer entender se a base atual já está numa posição segura de propriedade, o diagnóstico gratuito do projeto de IA em /construa-com-ia dura 45 minutos com um engenheiro e mapeia exatamente isso, sem compromisso de contratar nada.