Contrato de desenvolvimento de software: o que precisa ter

O que um contrato de desenvolvimento de software precisa ter?

Um contrato de desenvolvimento de software precisa ter, no mínimo, dez blocos: escopo com critério de aceite, prazo e marcos, forma de pagamento, propriedade intelectual e cessão do código, contas no nome do cliente, garantia, manutenção, confidencialidade, tratamento de dados pessoais e regras de saída. Faltando qualquer um, o risco fica com quem pagou.

Foro, multa e reajuste são padrão de qualquer contrato de serviço, e o seu advogado cuida melhor disso. Os dez blocos são os que mudam num projeto de software e os que vêm genéricos em modelo da internet. Cada um tem uma seção a seguir.

Como escrever escopo e critério de aceite sem brecha?

Escopo bom lista o que o sistema faz fluxo por fluxo, o que fica de fora e como cada entrega é considerada aceita. Critério de aceite é um teste que qualquer pessoa consegue repetir: o pedido aprovado gera a nota, o relatório bate com a planilha do mês. Sem isso, pronto vira opinião de cada lado.

O escopo funciona melhor como anexo que prevalece sobre conversa de WhatsApp, com três coisas:

• O que entra, por fluxo e por papel de usuário: quem cadastra, quem aprova, quem vê o relatório. Contar telas engana; contar fluxos não.
• O que fica de fora. Aplicativo nativo, migração de dados antigos, integração com o ERP: se não vai entrar, escreva.
• Prazo e forma de aceite. Quantos dias úteis você tem pra testar cada entrega e como reporta o que não passou. Se o contrato trata silêncio como aceite, confira se o prazo é realista pra sua equipe.

E a mudança de escopo, que vai acontecer: item novo é orçado por escrito, com impacto em prazo e preço, e só começa depois da sua aprovação. Escopo fechado também facilita comparar propostas, assunto do guia sobre quanto custa um software sob medida.

Como amarrar prazo, marcos e pagamento?

Prazo e pagamento devem estar presos a marcos de entrega aceitos, e não ao calendário. Cada marco descreve o que estará funcionando, a data prevista e a parcela que ele libera. Assim você paga pelo que testou, e o fornecedor tem um motivo concreto pra cumprir cada etapa dentro do prazo combinado.

Uma estrutura que funciona em projeto fechado: entrada pra reservar a equipe, parcelas vinculadas a marcos e a última depois do aceite final, já em produção. Pagar tudo adiantado tira o seu poder de negociação.

Escreva também o atraso dos dois lados: se a software house atrasa, desconto na parcela; se o atraso é seu, o prazo anda junto. Se o modelo for por hora, exija teto mensal e relatório de horas por tarefa.

De quem é o código de um software feito sob encomenda?

Depende do que o contrato diz. A Lei do Software atribui ao contratante os direitos sobre o programa desenvolvido em contrato destinado a isso, mas a regra começa com "salvo estipulação em contrário". Por isso a cessão do código precisa estar escrita, de forma total e definitiva, em vez de ficar presumida.

Essa regra está no art. 4º da Lei 9.609/98, que no art. 2º aplica ao software o regime dos direitos autorais. E a Lei 9.610/98 é rigorosa: o art. 49 só admite transmissão total e definitiva mediante estipulação contratual escrita, e o art. 4º manda interpretar restritivamente os negócios sobre direitos autorais. Na dúvida, a leitura tende a ser a mais estreita. A cláusula boa diz quatro coisas:

• Cessão total e definitiva dos direitos patrimoniais sobre código-fonte, banco de dados, documentação e design criados no projeto, sem limite de prazo ou território.
• O momento da cessão: na assinatura, a cada marco pago ou no pagamento final. Atrelar ao pagamento é justo; deixar indefinido não é.
• Os componentes prévios do fornecedor. Software house reaproveita código interno, e isso barateia o projeto; o contrato lista esses componentes e dá a você licença perpétua e irrevogável pra usá-los no sistema.
• As bibliotecas de código aberto usadas e suas licenças.

Por que repositório e contas devem ficar no nome do cliente?

Porque ter o direito sobre o código no papel não adianta se o código está numa conta que só o fornecedor acessa. Repositório, nuvem, domínio, banco de dados e conta do gateway de pagamento devem ser abertos no nome e no CNPJ da sua empresa desde o primeiro dia, com o fornecedor entrando como convidado.

• Repositório numa organização da sua empresa, com commits desde a primeira semana.
• Nuvem e hospedagem com faturamento no seu cartão ou CNPJ. Se o fornecedor paga e repassa, a conta é dele.
• Domínio no CNPJ da empresa no Registro.br.
• Gateway de pagamento, como Stripe ou Mercado Pago, na conta da sua empresa: é ali que cai o dinheiro dos seus clientes.
• Credenciais num cofre de senhas compartilhado, e não na memória de um desenvolvedor.

Escreva isso como obrigação: o fornecedor não mantém ativos do projeto em contas próprias. Quando um fornecedor resiste a essa cláusula, é o sinal de alerta mais claro da negociação. O guia de software houses traz essa pergunta entre as da primeira conversa.

O que a garantia e a manutenção precisam cobrir?

Garantia é o período depois do aceite em que o fornecedor corrige, sem custo, o que não funciona como o escopo descreve. Manutenção é outro serviço, pago, que cobre atualização, monitoramento, correções fora da garantia e evolução. Misturar os dois no mesmo parágrafo do contrato é uma origem frequente de cobrança surpresa depois da entrega.

Não há um prazo de garantia certo, então negocie e escreva. Um critério útil: cobrir pelo menos um ciclo completo do processo que o sistema atende, contado do aceite em produção. Se o sistema calcula comissão no fim do mês, garantia de 15 dias não chega a ver o primeiro fechamento.

Defina também defeito (o sistema não faz o que o escopo diz) e mudança (faz, mas você quer outra coisa). Defeito entra na garantia; mudança é orçada. Na manutenção, confira o que a mensalidade cobre e como encerrar.

Como tratar confidencialidade e LGPD no contrato?

Confidencialidade protege o seu negócio: processos, preços, base de clientes e o próprio código não podem ser usados nem divulgados pelo fornecedor, e a obrigação continua depois que o contrato acaba. A LGPD protege as pessoas cujos dados o sistema trata, e o contrato precisa dizer quem decide e quem executa esse tratamento.

Na LGPD, a Lei 13.709/2018, a sua empresa costuma ser a controladora e a software house que acessa dados pessoais atua como operadora, tratando os dados em nome do controlador (art. 5º, VI e VII). O art. 39 manda o operador seguir as instruções do controlador, e o art. 42 o torna solidariamente responsável pelos danos quando descumpre a lei ou essas instruções. Escreva as instruções:

• Pra que o fornecedor pode usar os dados, e que fora disso não pode.
• Medidas de segurança, como pede o art. 46: acesso individual e registrado, nada de base de produção copiada pra notebook.
• Dados fictícios ou anonimizados em desenvolvimento sempre que possível.
• Aviso de incidente de segurança à sua empresa em poucas horas.
• Eliminação dos dados no fim do contrato, com confirmação por escrito.

O aviso rápido tem motivo. A página da ANPD sobre comunicação de incidentes, consultada em outubro de 2026, informa que a obrigação de comunicar a autoridade e os titulares é do controlador, em três dias úteis, conforme a Resolução CD/ANPD nº 15/2024. Se o fornecedor leva uma semana pra contar, o seu prazo já passou.

O que acontece se a software house sumir?

Se o repositório e as contas estão no seu nome e a documentação foi entregue a cada marco, o fornecedor sumir vira um problema de troca de equipe, e o sistema continua seu. Se não estão, você pode ficar com um sistema no ar que ninguém sabe atualizar, ou nem isso. O contrato decide qual dos dois cenários você vive.

• Documentação a cada marco. Pra transferência de tecnologia, o parágrafo único do art. 11 da Lei do Software lista código-fonte comentado, memorial descritivo, especificações funcionais internas, diagramas e fluxogramas. É um bom modelo do que pedir.
• Rescisão por abandono: sem resposta num prazo definido depois de notificado, você rescinde, contrata outra equipe e não deve as parcelas futuras.
• Transição assistida pra nova equipe, com prazo e horas combinados, e revogação de acessos no fim.

Se quem fez já sumiu, dá pra recuperar: é o trabalho de manutenção de sistemas da VTA, que assume sistema feito por outra equipe começando pela leitura do código.

Quais cláusulas conferir antes de assinar?

Use a tabela abaixo com a minuta aberta ao lado. Pra cada cláusula, confira se o texto responde o que está na coluna do meio. Se aparecer o que está na última coluna, é ponto de negociação antes da assinatura, e em alguns casos motivo pra procurar outro fornecedor.

Preciso de advogado pra revisar o contrato de software?

Sim, sempre que o projeto for relevante pro seu negócio. Este guia mostra o que um contrato de desenvolvimento precisa cobrir do ponto de vista técnico, mas não substitui a leitura de um advogado, que vai ajustar foro, multas, limites de responsabilidade, tributos e a redação de cada cláusula ao seu caso.

Levar a tabela acima já conferida economiza horas de revisão.

Na VTA a proposta sai fechada, com escopo, prazo e preço por escrito, e a resposta ao primeiro contato vem no mesmo dia. Projetos começam em R$ 20 mil; abaixo disso, um freelancer com contrato bem escrito ou uma ferramenta pronta pode ser a escolha certa, como comparamos em no-code, IA ou software house. Se cabe, veja sistemas sob medida ou peça o orçamento.

Perguntas frequentes