Contrato de desenvolvimento de software: escopo, aceite e direitos sobre o código
Como organizar contrato de software sob medida: entregas, testes, aceite, mudanças, código anterior, titularidade, licenças, suporte e transição.
O contrato de desenvolvimento de software deve transformar a demanda em entregas verificáveis, definir teste e aceite e distinguir criação contratada de componentes anteriores e de terceiros. Direitos sobre o programa, acesso ao repositório e condições de uso são questões relacionadas, mas diferentes. Mudanças de escopo, suporte, dados e saída precisam acompanhar a execução do projeto.
A software house considera um módulo entregue; o contratante entende que a função central ainda não opera. Uma lista genérica de funcionalidades e um cronograma de pagamentos não bastam para resolver a divergência. O contrato precisa permitir comparar o que foi solicitado, o que mudou e o que efetivamente foi disponibilizado para homologação.
Que desenvolvimento foi contratado?
Identifique se haverá descoberta de requisitos, protótipo, construção integral, evolução de produto existente ou integração entre sistemas. Defina responsáveis pelas decisões de negócio, arquitetura, dados, conteúdo e infraestrutura. Se uma etapa inicial ainda produzirá o escopo, esclareça o resultado dessa etapa e como será aprovado o orçamento de construção.
Preço fechado, contratação por horas e trabalho por ciclos distribuem riscos de modo diferente. Em qualquer formato, registre critérios de priorização, documentação de decisões e limites da entrega. Um backlog sujeito a mudanças não deve coexistir com promessa vaga de que tudo estará incluído por preço fixo. A contratação sob medida também difere da assinatura de um SaaS, cujo objeto principal é acesso a produto preexistente.
Como ligar entrega, teste, aceite e pagamento?
No celular, deslize a tabela para ver todas as colunas. Pelo teclado, foque a tabela e use as setas.
| Entregável | Teste e critério | Responsável e evidência |
|---|---|---|
| Funcionalidade | Cenário esperado, entrada e resultado verificável. | Quem testa e registra ocorrência. |
| Integração | Sistema, versão, credencial e retorno esperado. | Quem fornece ambiente e relatório do teste. |
| Desempenho | Carga e condição mensurável acordadas. | Método, ambiente e resultado. |
| Segurança contratada | Requisito e verificação especificados. | Relatório e tratamento das pendências. |
| Documentação | Arquivos e instruções necessários à entrega. | Versão, destinatário e comprovante. |
Defina ambiente de homologação, forma de disponibilização, prazo razoável para teste, classificação dos problemas e reteste. Diferencie recebimento do arquivo, conclusão de teste e aceite do marco contratual. A instalação em produção precisa de plano e autorização compatíveis com o risco, sem presumir que toda utilização prova aceitação de todos os itens.
A falta de resposta do cliente pode gerar atraso e exige fluxo de comunicação. Não trate, porém, um aceite tácito automático como recomendação universal. Avalie se a entrega foi acessível, se os critérios estavam definidos, se a equipe pôde testar e quais pendências foram documentadas. Cobrança e liberação de etapa devem acompanhar o critério acordado.
Como distinguir defeito, novo requisito e dependência?
Registre solicitação de mudança com descrição, motivo, impacto no prazo, preço e entregas, além de quem pode aprová-la. Uma conversa técnica não representa necessariamente autorização financeira. O histórico precisa permitir reconhecer a versão do escopo em vigor para cada marco.
Defeito é examinado em relação ao requisito contratado e ao comportamento esperado; novo requisito pode alterar o objeto. Uma falha de terceiro ou ausência de dado do cliente exige prova de sua influência no cronograma. O contrato deve prever comunicação e providências, sem atribuir a uma parte todo atraso apenas pelo rótulo de dependência.
A empresa pede aprovação em duas etapas depois de homologar uma tela com aprovação única. A equipe compara a solicitação com o requisito aceito, documenta a mudança e seu impacto. Se a tela original nunca executou a aprovação prevista, o reparo não se torna extra apenas por receber o nome de melhoria.
Quem tem os direitos sobre o código?
O art. 4º da Lei 9.609/1998 contém regra supletiva: salvo estipulação contrária, atribui direitos ao empregador ou contratante nas hipóteses de desenvolvimento relacionadas ao vínculo e ao objeto ali descritos. Portanto, não é correto afirmar que o contratante nunca adquire direitos sem uma cessão expressa. Também não é correto supor que qualquer pagamento transfira código anterior ou todos os ativos utilizados no projeto.
No celular, deslize a tabela para ver todas as colunas. Pelo teclado, foque a tabela e use as setas.
| Camada | Pergunta contratual | Documento |
|---|---|---|
| Código preexistente | Que componentes a prestadora já possuía e qual uso será permitido? | Inventário e licença. |
| Criação contratada | Qual programa e quais entregas foram produzidos no vínculo? | Escopo, histórico e disciplina de direitos. |
| Componentes de terceiros | Que licenças e restrições condicionam uso e distribuição? | Lista de dependências e termos. |
| Derivações | Quais alterações são autorizadas e como ficam seus direitos? | Condições específicas e art. 5º da Lei do Software. |
| Repositório e infraestrutura | Como entregar, manter e transferir o acesso técnico? | Contas, histórico, documentação e permissões. |
Banco de dados, marca, conteúdo e documentação podem envolver regimes próprios. Acesso ao repositório permite continuidade técnica, mas não define sozinho titularidade ou licença. Examine também se quem contrata possui direitos suficientes sobre componentes entregues por empregados e subcontratados.
Como tratar dados e segurança durante o projeto?
Mapeie dados pessoais utilizados em desenvolvimento, migração, testes e produção. Nos termos da LGPD, controlador e operador são definidos pelas decisões e atividades efetivas. O nome software house não resolve automaticamente o papel em todo tratamento. Registre instruções, acessos, ambiente, medidas de segurança e comunicação de incidentes, conforme o tratamento contratado.
Evite copiar bases reais para testes sem examinar necessidade, fundamento e proteção. Defina quem aprova migração, confere integridade e autoriza desligar o sistema anterior. Sigilo, gestão de credenciais e retirada de acessos precisam acompanhar a rotina da equipe, inclusive de terceiros.
Garantia, suporte e transição precisam de entregas próprias
Diferencie correção de defeitos, evolução e atendimento de suporte. Estabeleça canais, horários, classificação e condições de manutenção compatíveis com a Lei do Software e com o objeto. A relação entre empresas não afasta automaticamente o CDC; sua aplicação depende do enquadramento concreto e, quando pertinente, da vulnerabilidade.
Na saída, confira código e histórico previstos, instruções de compilação e implantação, dependências, contas, dados, documentação e pendências. Defina a transferência de conhecimento e a revogação coordenada de acessos. O contrato de suporte de TI trata dos chamados e da manutenção de ambiente; ele não substitui a entrega do desenvolvimento. Uma avaliação específica de segurança pode ter escopo próprio, como na contratação de pentest.
Perguntas frequentes
Sem cessão expressa, o contratante nunca adquire direitos sobre o software?
Não. O art. 4º da Lei 9.609/1998 prevê regra supletiva para desenvolvimento relacionado ao vínculo e ao objeto ali descritos, ressalvada estipulação contrária. É necessário examinar o contrato e distinguir código anterior e componentes de terceiros.
Receber o repositório significa ser dono de tudo?
Não. Acesso técnico, titularidade e licença são questões diferentes. Componentes preexistentes, bibliotecas, dados e outros ativos precisam ser identificados.
Toda solicitação depois da entrega é serviço extra?
Não. É necessário comparar o requisito, a entrega e a ocorrência. Correção de defeito e alteração de escopo têm fundamentos distintos e precisam de registro.
Contrato entre empresas exclui automaticamente o CDC?
Não. O enquadramento concreto da relação e eventual vulnerabilidade devem ser examinados. A condição de pessoa jurídica, isoladamente, não encerra a questão.
Fontes e alcance deste guia
Fontes primárias consultadas para a edição de 30 de outubro de 2026. A aplicação ao caso depende dos documentos, da atividade e da regra pertinente ao período e ao local.
Documentos para análise
Reúna proposta, contrato, escopo, backlog, atas de decisão, entregas e testes, registros de aceite, mudanças aprovadas, inventário de componentes, licenças, repositório e plano de suporte e saída. Para dados pessoais, acrescente instruções e matriz de acessos.
O serviço de Direito Digital para empresas permite aprofundar a organização jurídica da atividade e a documentação aplicável.