Modelos de trabalho

De quem é o código do seu app? Como contratar sem virar refém de quem desenvolve

Equipe iatize · 2026-07-16 · 8 min de leitura

Existe um momento clássico e horrível: o produto está no ar, funcionando, dando dinheiro. Você quer mudar de fornecedor — porque o preço subiu, porque o atendimento piorou, porque simplesmente cresceu. Aí você descobre que o código está no GitHub da agência, o servidor está no cartão de crédito dela e o domínio foi registrado em nome de um funcionário que saiu de lá em 2024.

Você não tem um fornecedor. Você tem um dono. E o pior: quase sempre isso não foi maldade — foi só ninguém ter combinado nada, e o silêncio do contrato favorecer quem construiu.

As 3 chaves que definem quem manda no seu produto

Esqueça o juridiquês por um minuto. Na prática, controlar um software é ter três coisas. Quem tem as três, manda:

1. O código-fonte: as instruções que fazem o produto existir, e o histórico de como ele chegou até aqui.
2. As contas: onde o produto roda, onde os dados moram, onde o domínio está registrado, onde ficam os serviços que ele usa.
3. O deploy: a capacidade de colocar uma nova versão no ar. Sem isso, você tem o código mas não consegue mudar nada.

A parte jurídica, sem juridiquês

Código feito sob encomenda não é automaticamente seu

Essa é a surpresa que pega quase todo mundo. Existe uma intuição — paguei, logo é meu — que não se sustenta sozinha. Quem escreve o software tem direitos sobre o que escreveu, e a transferência precisa estar escrita. Sem cláusula, você comprou o direito de usar o produto, não necessariamente a propriedade dele.

Registro no INPI não é patente (e a diferença importa)

Muita gente diz que vai patentear o app. Software no Brasil não se patenteia como se patenteia uma máquina — o que existe é o registro de programa de computador no INPI, que é uma prova de autoria e data. Isso ajuda a provar que o código é seu numa disputa. Não impede alguém de criar um concorrente parecido, e não protege a sua ideia. Protege o seu código.

O que precisa estar escrito no contrato

• Cessão total e definitiva dos direitos sobre o código desenvolvido pra você, sem prazo e sem limitação de uso.
• Que você pode modificar o código e contratar terceiros pra fazer isso — sem precisar de autorização de quem construiu.
• Entrega do código-fonte completo, com histórico, ao fim do projeto (e não uma pasta zipada com a versão final).
• Titularidade das contas: hospedagem, domínio, serviços de terceiro e loja de aplicativos no seu nome ou da sua empresa.
• O que acontece no fim da relação: prazo pra transferir tudo, entregar documentação e remover os acessos do fornecedor.
• Sigilo sobre o seu negócio e seus dados — e o que acontece se for quebrado.

As red flags de lock-in

Nenhuma delas é ilegal. Todas são formas de te prender:

• O repositório está na conta da agência e você não tem acesso. Prender o código é a forma mais direta.
• A hospedagem está no cartão deles. Enquanto for assim, o botão de desligar seu negócio está com outra pessoa.
• O domínio foi registrado em nome do fornecedor ou de um funcionário. Isso é mais comum do que deveria e é venenoso.
• Só eles conseguem publicar uma nova versão. Você tem o código, mas ele é um enfeite.
• Zero documentação, e a explicação é que o código se explica sozinho. Não se explica.
• O produto foi feito numa plataforma no-code presa à conta deles. Você não tem código nenhum pra levar.
• Contrato que fala em licença de uso em vez de cessão de direitos. Repare nessa palavra: licença significa que você aluga o que pagou pra construir.
• Não aceitam colocar propriedade do código no contrato. Aqui a conversa acabou.

Sendo justo com o outro lado

Nem toda retenção é armadilha. Existem situações legítimas, e reconhecê-las te faz um cliente melhor:

• Componentes internos reutilizados: uma boa fábrica tem bibliotecas próprias que usa em vários clientes. Ela te licencia o uso, mas não vai te ceder a ferramenta dela — e isso é justo. O que é seu é o seu produto.
• Enquanto não estiver pago: reter entrega até a quitação é prática comercial normal, não sequestro.
• Manter acesso pra dar suporte: se você contratou manutenção, ele precisa de acesso. A diferença é ser acesso concedido por você, não posse.
• Bibliotecas de código aberto: boa parte de qualquer software é feita de peças de terceiros com licença própria. Isso não é lock-in, é como o mundo funciona.

A distinção é simples: acesso é saudável, posse é o problema. O fornecedor deve ter as chaves da sua casa porque você deu — não porque a casa está no nome dele.

E o medo de roubarem a sua ideia?

Essa é a pergunta que mais aparece e a que tem a resposta mais dura: ideia não vale quase nada. O que vale é tirar do papel. Todo mundo que constrói software ouve dez ideias por semana, e ninguém tem tempo nem vontade de largar o próprio negócio pra tocar a sua — que, além de tudo, depende do seu conhecimento de mercado pra dar certo.

Se ainda assim você quer se proteger: um NDA resolve a conversa inicial e é razoável pedir. Mas invista sua energia no que realmente protege — cláusula de cessão de código, contas no seu nome e velocidade de chegar ao mercado. Quem chega primeiro e entende o cliente melhor vence. Não é quem teve a ideia primeiro.

Já estou preso. E agora?

1. Não brigue ainda. Você precisa das coisas antes de ter a conversa difícil.
2. Faça um inventário: liste onde está cada peça (código, domínio, hospedagem, dados, lojas) e em nome de quem.
3. Comece pelo mais fácil de mover: domínio e contas de serviço costumam sair sem grande resistência.
4. Peça a transferência por escrito, num tom de organização, não de acusação. Boa parte dos fornecedores transfere sem drama porque nunca quis reter nada.
5. Se houver resistência real, é hora do advogado — e o contrato original vai definir sua força.
6. Se não houver contrato, aceite o prejuízo de negociar e nunca mais comece um projeto sem essa cláusula.

Como a gente trabalha (pra você poder comparar)

Já que o artigo cobra transparência, é justo dizer o nosso lado. O produto que construímos pra você é seu — código e contas no seu nome. Nosso modelo Sócio Tech, quando faz sentido, é uma sociedade combinada e transparente sobre o sucesso do produto, acordada antes de começar. É o oposto de refém: refém é quem não sabe o que assinou.

Fazer meu diagnóstico gratuito