Um contrato de desenvolvimento de software protege a empresa contratante quando deixa por escrito seis pontos: o que será entregue (escopo e critérios de aceite), de quem é o código-fonte (cessão de direitos), como os dados pessoais serão tratados (papel de operador na LGPD), quanto e quando se paga (marcos ligados a entregas), o que acontece quando algo dá errado (garantia, correção e multas proporcionais) e como sair do contrato sem perder o sistema (rescisão com transição e entrega de tudo o que foi produzido). Sem essas cláusulas, valem as regras gerais da lei, que nem sempre favorecem quem pagou pelo software.

Este guia explica cada cláusula em linguagem de negócio, mostra o que a legislação brasileira já define e traz um checklist para revisar a minuta antes de assinar. Ele não substitui a análise de um advogado: as regras citadas vêm de fontes oficiais, mas a redação final do contrato deve ser validada por um profissional jurídico que conheça o seu caso.

Por que o contrato de software exige mais cuidado que outros serviços

Software é um serviço que vira um ativo. A empresa contrata horas de trabalho, mas recebe ao final um bem intangível que precisa ser mantido, corrigido e, às vezes, transferido para outro fornecedor. Se o contrato tratar o projeto apenas como “prestação de serviços”, ficam sem resposta perguntas como quem pode alterar o sistema depois, onde ficam as senhas dos servidores e quem responde por um vazamento de dados.

Outro ponto é que o escopo de software muda. Durante o desenvolvimento, a equipe descobre regras de negócio que ninguém tinha mencionado, e o usuário pede ajustes ao ver as primeiras telas. Um contrato bem feito prevê como essas mudanças entram, quanto custam e quem aprova.

Por fim, software envolve dados. Quase todo sistema empresarial guarda nomes, CPFs, e-mails ou dados financeiros de clientes e funcionários. Isso coloca o fornecedor na posição de operador de dados pessoais, com obrigações definidas pela Lei Geral de Proteção de Dados (LGPD). O contrato é o lugar certo para registrar as instruções que a empresa dá ao fornecedor sobre esses dados.

O que a lei brasileira já define antes de você assinar

Algumas regras se aplicam ao contrato mesmo que ele não fale nada sobre elas. Conhecer essas regras ajuda a entender o que precisa ser escrito e o que já está coberto.

A Lei do Software é de 19 de fevereiro de 1998, mesma data da Lei de Direitos Autorais. As duas se complementam: a de direitos autorais se aplica a programas de computador no que couber, conforme o art. 7º, XII, da Lei 9.610/1998. Na prática, isso significa que a forma de ceder o código segue as exigências de escrita e especificação da lei de direitos autorais.

Um ponto merece atenção. O art. 4º da Lei do Software fala em “salvo estipulação em contrário”. Isso quer dizer que o contrato pode inverter a regra e deixar o código com o fornecedor. Há minutas que fazem exatamente isso, de forma discreta, ao falar em “licença de uso” em vez de “cessão”. Se a sua empresa quer ser dona do código, o contrato precisa dizer isso com todas as letras. Vale validar a redação com um advogado, porque a aplicação do art. 4º a contratos entre empresas tem nuances de interpretação.

As cláusulas essenciais, uma a uma

As cláusulas abaixo seguem a ordem em que costumam aparecer numa minuta. Para cada uma, o texto explica o objetivo, o que costuma dar errado e o que pedir ao fornecedor.

1. Objeto e escopo

O objeto diz o que será construído. O erro mais comum é descrever o sistema em uma frase genérica, como “desenvolvimento de plataforma de gestão”. Uma frase assim permite que cada parte entenda uma coisa diferente.

O melhor caminho é anexar ao contrato um documento de escopo: lista de funcionalidades, perfis de usuário, integrações com outros sistemas e requisitos não funcionais (desempenho, segurança, navegadores e aparelhos suportados). Esse documento costuma sair de uma etapa de descoberta, conhecida como discovery, feita antes do desenvolvimento. O guia sobre processo de discovery no desenvolvimento de software explica como essa etapa reduz incerteza.

2. Gestão de mudanças

Mudanças vão acontecer. A cláusula deve definir como um pedido novo é registrado, como o fornecedor estima horas e prazo e quem na empresa tem autoridade para aprovar. Sem isso, pequenos pedidos feitos por mensagem se acumulam e viram discussão na hora da fatura.

Peça que toda mudança aprovada gere um registro simples, com descrição, horas estimadas e impacto no cronograma. Isso protege as duas partes e dá previsibilidade ao orçamento.

3. Propriedade intelectual e código-fonte

Esta é a cláusula que mais protege a empresa no longo prazo. Ela deve dizer que os direitos patrimoniais sobre o código desenvolvido para o projeto são cedidos à contratante, em caráter definitivo, para todas as modalidades de uso, incluindo alterar, adaptar, integrar e contratar terceiros para manter.

A cláusula também deve tratar de três exceções comuns. Primeiro, bibliotecas de código aberto, que seguem suas próprias licenças. Segundo, componentes que o fornecedor já tinha antes do projeto e reutiliza em vários clientes; aqui o normal é uma licença perpétua e gratuita para o uso no sistema. Terceiro, serviços de terceiros pagos, como APIs de mapas ou de inteligência artificial, que ficam em nome da contratante.

Além do direito, a cláusula precisa garantir o acesso físico ao código: repositório em conta da empresa ou entregas periódicas do código atualizado, com instruções de compilação e implantação. Ter o direito sem ter os arquivos não resolve nada.

4. Contas, acessos e infraestrutura

Quem é o titular da conta de nuvem, do domínio, do repositório de código e da conta de desenvolvedor nas lojas de aplicativos? Se essas contas estiverem no nome do fornecedor, a empresa depende dele até para renovar um certificado.

O recomendável é que todas as contas fiquem no nome da contratante, com acesso concedido ao fornecedor durante o projeto. No caso de aplicativos, a publicação deve ser feita na conta de desenvolvedor do cliente na App Store e no Google Play.

5. Prazos, marcos e cronograma

O contrato deve ter marcos verificáveis, e não apenas uma data final. Entregas parciais frequentes permitem que a empresa veja o produto crescer e corrija o rumo cedo. Um modelo comum é a entrega de uma versão para teste a cada duas semanas.

Inclua também o que acontece quando o atraso é causado pela própria contratante, por exemplo quando ela demora a enviar informações ou a aprovar telas. Cronogramas justos dependem das duas partes.

6. Critérios de aceite

Aceite é o momento em que a empresa confirma que uma entrega está de acordo com o combinado. A cláusula deve definir quem testa, em quantos dias úteis, como os defeitos são reportados e o que acontece se a empresa não se manifestar no prazo. Muitos contratos preveem aceite tácito após um período sem resposta; isso é razoável, desde que o prazo seja suficiente para testar.

Critérios objetivos evitam briga. Em vez de “sistema funcionando”, prefira “fluxo de pedido concluído do início ao fim, com nota emitida no ambiente de homologação, sem erro bloqueante”.

7. Preço, forma de pagamento e reajuste

O preço pode ser fechado, por hora ou por equipe mensal. A cláusula deve deixar claro o que está incluído (por exemplo, testes, implantação e documentação) e o que é cobrado à parte (licenças, nuvem, serviços de terceiros). Pagamentos ligados a marcos aceitos dão mais segurança do que pagamentos apenas por data.

Para contratos longos, defina o índice e a periodicidade de reajuste. O artigo sobre quanto custa contratar uma software house ajuda a entender as faixas praticadas no mercado.

8. Garantia e correção de defeitos

Depois do aceite, defeitos ainda aparecem. A cláusula de garantia define por quanto tempo o fornecedor corrige, sem custo, erros que existiam no que foi entregue. Ela deve separar defeito (algo que não funciona como especificado) de melhoria (algo novo que a empresa passou a querer).

Também é útil definir prazos de resposta por gravidade: um erro que impede vendas exige atendimento mais rápido que um ajuste de texto.

9. Confidencialidade

O fornecedor terá acesso a regras de negócio, dados de clientes e estratégias. A cláusula de confidencialidade deve cobrir o período do contrato e um prazo depois dele, listar as exceções usuais (informação já pública, por exemplo) e prever a devolução ou destruição das informações ao final.

10. Proteção de dados pessoais (LGPD)

Na maioria dos projetos, a empresa contratante é a controladora dos dados e o fornecedor é o operador. Pela LGPD, o operador trata dados segundo as instruções do controlador (art. 39). A cláusula, ou um anexo de tratamento de dados, deve registrar essas instruções.

O conteúdo mínimo costuma incluir: finalidade do tratamento, tipos de dados, medidas de segurança, uso de subcontratados, prazo para avisar a empresa sobre incidentes, apoio em pedidos de titulares e devolução ou eliminação dos dados ao final do contrato.

11. Segurança da informação

Além da LGPD, o contrato deve tratar de práticas de segurança no desenvolvimento: controle de acesso, revisão de código, testes de vulnerabilidade e correção de falhas conhecidas. Referências como o OWASP Top 10, lista das falhas mais comuns em aplicações web, podem ser citadas como padrão mínimo. O guia sobre segurança no desenvolvimento de software e OWASP Top 10 detalha esses controles.

12. Rescisão, transição e multas

A cláusula de saída é a que mais se negligencia e a que mais pesa quando a relação termina mal. Ela deve prever as hipóteses de rescisão, o aviso prévio, o pagamento pelo trabalho já feito e, principalmente, a obrigação de entregar código, documentação, acessos e dados em um prazo curto.

As multas devem ser proporcionais. O art. 413 do Código Civil determina que o juiz reduza a penalidade quando a obrigação foi cumprida em parte ou quando o valor é manifestamente excessivo. Uma multa desproporcional, portanto, pode não valer o que está escrito.

13. Responsabilidade e limites

É comum o fornecedor pedir um teto de responsabilidade, por exemplo limitado ao valor do contrato. Isso pode ser aceitável, mas o teto não deve alcançar situações graves, como violação de confidencialidade ou de proteção de dados por culpa do fornecedor. Negocie essas exceções.

14. Foro ou arbitragem

O contrato pode eleger um foro judicial ou prever arbitragem. A arbitragem, regulada pela Lei 9.307/1996, permite escolher árbitros com conhecimento técnico. Pelo art. 23 dessa lei, se as partes não fixarem prazo, a sentença arbitral deve sair em seis meses. Pelo art. 31, a sentença arbitral tem o mesmo efeito de uma decisão judicial. O custo da arbitragem costuma ser alto, então ela faz mais sentido em contratos de valor elevado.

Como o modelo de preço muda o contrato

O formato de remuneração altera quais cláusulas precisam de mais atenção. Nenhum modelo é melhor em todos os casos; cada um distribui o risco de um jeito.

Em qualquer modelo, a estimativa precisa ter método. O artigo sobre como estimar projetos de software com precisão mostra por que faixas de horas são mais honestas que um número único logo no primeiro contato.

Cláusulas de LGPD: o que escrever na prática

A LGPD é de 14 de agosto de 2018. Ela separa dois papéis: o controlador, a quem cabem as decisões sobre o tratamento de dados, e o operador, que trata os dados em nome do controlador. Na contratação de software, a empresa costuma ser a controladora e o fornecedor, o operador.

Esse enquadramento tem consequências práticas. Se o operador descumprir a lei ou as instruções lícitas do controlador, ele responde solidariamente pelos danos, conforme o art. 42, §1º, I. Por isso, a empresa precisa dar instruções claras e documentadas.

Outro ponto é o incidente de segurança. A Resolução CD/ANPD nº 15, de 24 de abril de 2024, estabelece que o controlador comunique à ANPD e aos titulares, em três dias úteis, o incidente que possa causar risco ou dano relevante. Esse prazo conta a partir do conhecimento de que o incidente afetou dados pessoais. Como quem detecta o problema muitas vezes é o fornecedor, o contrato deve obrigá-lo a avisar a empresa em prazo menor que esse, para que ela consiga cumprir a regra. A mesma resolução manda guardar o registro de incidentes por no mínimo cinco anos.

Um anexo de tratamento de dados costuma conter:

1. Descrição das finalidades e das categorias de dados tratados no sistema.
2. Lista dos subcontratados (por exemplo, provedores de nuvem) e a regra para incluir novos.
3. Medidas de segurança mínimas, como criptografia, controle de acesso e registro de atividades.
4. Prazo para o fornecedor comunicar incidentes à contratante, menor que três dias úteis.
5. Forma de apoio a pedidos de titulares, como acesso, correção e exclusão de dados.
6. Regra de devolução ou eliminação dos dados ao final do contrato.
7. Direito de a contratante auditar ou pedir evidências de conformidade.

Para projetos que usam inteligência artificial com dados de clientes, os cuidados aumentam. O guia sobre LGPD e inteligência artificial em 2026 trata do tema em detalhe.

Multas, rescisão e transição sem perder o sistema

Uma cláusula de rescisão bem escrita responde a três perguntas: quando cada parte pode sair, quanto se paga e o que se entrega.

Sobre a saída, é comum prever rescisão por descumprimento, com prazo para corrigir a falha antes de encerrar, e rescisão sem motivo, com aviso prévio. Para a empresa, o aviso prévio do fornecedor deve ser longo o bastante para encontrar outro time sem deixar o sistema parado.

Sobre o pagamento, o justo é pagar pelo trabalho entregue e aceito até a data da saída. Multas devem compensar prejuízos razoáveis, sem transformar a saída em punição. O Tribunal de Justiça do Distrito Federal reúne decisões em que multas foram reduzidas por serem excessivas, sempre com base no art. 413 do Código Civil. Em uma delas, a 3ª Turma Cível considerou excessiva uma multa de 10% sobre o valor total do contrato, no caso concreto analisado. Isso não cria uma regra geral, mas mostra que o percentual precisa ter relação com o prejuízo real.

Sobre a entrega, a lista deve ser objetiva:

Exemplo hipotético: uma empresa contrata um sistema por preço fechado de R$ 200 mil, dividido em cinco marcos de R$ 40 mil. Após o aceite de três marcos, decide encerrar o contrato. Uma cláusula justa prevê o pagamento dos R$ 120 mil já aceitos, eventual pagamento proporcional do marco em andamento, multa compatível com o prejuízo do fornecedor e entrega imediata de tudo o que foi produzido. Uma cláusula ruim exigiria o valor integral ou reteria o código até a quitação de uma multa alta.

A diferença entre os dois cenários está no papel, não na negociação feita depois que a relação já se desgastou.

Erros comuns em contratos de desenvolvimento de software

Os problemas abaixo aparecem com frequência em minutas enviadas por fornecedores e em modelos baixados da internet.

1. Escopo descrito em uma linha, sem anexo técnico nem critérios de aceite.
2. “Licença de uso” no lugar de cessão de direitos, deixando o código com o fornecedor.
3. Repositório, domínio e nuvem registrados em nome do fornecedor.
4. Pagamentos vinculados apenas a datas, e não a entregas aceitas.
5. Ausência de cláusula de proteção de dados, ou cláusula genérica copiada de outro contrato.
6. Multa de rescisão desproporcional, que pode ser reduzida em juízo e gera disputa.
7. Nenhuma obrigação de entregar documentação, credenciais e dados na saída.
8. Garantia que não separa defeito de melhoria, o que leva a discussões em toda correção.
9. Contrato de sustentação sem níveis de serviço nem definição de gravidade.

Muitos desses erros nascem da pressa em começar. Gastar alguns dias revisando a minuta custa menos do que resolver um impasse com o sistema em produção. O artigo sobre como escolher uma software house em 2026 traz critérios complementares para avaliar o fornecedor antes da assinatura.

Checklist para revisar a minuta antes de assinar

Use a lista abaixo como roteiro de revisão interna, antes de enviar a minuta ao jurídico. Ela não substitui o parecer do advogado, mas ajuda a chegar à conversa com as perguntas certas.

1. O escopo está anexado, com funcionalidades, integrações e requisitos de segurança?
2. Existe um processo escrito para pedidos de mudança, com aprovação e estimativa de horas?
3. A cláusula fala em cessão definitiva dos direitos patrimoniais sobre o código, para todos os usos?
4. Estão listados os componentes de terceiros e de código aberto, com suas licenças?
5. Repositório, domínio, nuvem e contas de lojas de aplicativos ficam em nome da empresa?
6. Há marcos com entregas parciais e prazos de aceite definidos?
7. Os pagamentos estão ligados a entregas aceitas?
8. A garantia tem prazo, separa defeito de melhoria e define tempo de resposta por gravidade?
9. Existe anexo de tratamento de dados com prazo de aviso de incidentes menor que três dias úteis?
10. A rescisão prevê entrega de código, documentação, credenciais e dados em prazo curto?
11. As multas são proporcionais ao prejuízo e ao trabalho já cumprido?
12. Os limites de responsabilidade excluem violações de confidencialidade e de proteção de dados?
13. O foro ou a arbitragem foram escolhidos de forma consciente, considerando custo e prazo?

Se a resposta for “não” para três ou mais itens, vale pedir ajustes ao fornecedor antes de seguir. Fornecedores sérios costumam aceitar ajustes que trazem clareza, porque contratos claros também os protegem.

O padrão contratual da Mind Group

Para mostrar como essas cláusulas se traduzem em prática, a tabela abaixo resume as condições que a Mind Group adota como padrão nos seus projetos de software sob medida.

Metodologia: as faixas de orçamento são as usadas pela Mind Group em 2026 e resultam de horas estimadas multiplicadas pelo valor-hora de R$ 110 a R$ 190. São referências; o valor final depende do escopo aprovado. As demais linhas descrevem as condições contratuais padrão da empresa.

Com entregas a cada duas semanas, o cliente tem pontos frequentes para aceitar ou recusar o que foi feito, o que facilita amarrar pagamentos a entregas reais. Com o código em mãos e os aplicativos em sua própria conta, a empresa mantém a liberdade de trocar de fornecedor se quiser.

Para entender o custo total ao longo da vida do sistema, e não só o do desenvolvimento, veja a metodologia de TCO de software. E, para comparar o contrato com uma software house com a alternativa de montar um time próprio, o comparativo entre software house, equipe interna e freelancer ajuda na decisão.

Como a Mind Group pode ajudar

A Mind Group é uma software house brasileira, fundada em 2016, que desenvolve sistemas, aplicativos e soluções de inteligência artificial sob medida para empresas de todo o Brasil. Tem mais de 60 desenvolvedores próprios, mais de 500 produtos digitais lançados, nota 5,0 no Clutch com 17 avaliações verificadas de clientes, entrega o código-fonte ao cliente e mantém uma frente de cibersegurança dedicada à correção de vulnerabilidades e à resposta a incidentes.

Antes de qualquer contrato, a Mind apresenta escopo, faixa de horas e condições por escrito, para que o jurídico do cliente possa revisar cada ponto com calma. Entre os clientes da empresa estão Itaipu Binacional, Inframerica (Aeroporto de Brasília), Fisk, Febracis e Unidas (autogestão em saúde).

Quando o projeto envolve dados pessoais ou sistemas críticos, a frente de cibersegurança participa da definição das medidas de segurança que entram no contrato e no anexo de tratamento de dados. Para conhecer os serviços, acesse a página de desenvolvimento de sistemas.

Atualizado em outubro de 2026.

Perguntas frequentes

Quem é o dono do código-fonte quando a empresa contrata uma software house?

A Lei 9.609/1998 diz que, salvo estipulação em contrário, os direitos pertencem ao contratante de serviços. Como o contrato pode inverter essa regra, o mais seguro é prever cessão definitiva e por escrito dos direitos patrimoniais. Confirme a redação com um advogado.

O contrato de software precisa de cláusula de LGPD?

Se o sistema vai tratar dados pessoais, sim. O fornecedor costuma atuar como operador e, pela LGPD, deve seguir as instruções do controlador. O contrato ou um anexo de tratamento de dados é o lugar para registrar essas instruções.

Qual é um valor razoável para a multa de rescisão?

Não existe percentual fixo na lei. O art. 413 do Código Civil manda reduzir a multa quando ela é manifestamente excessiva ou quando a obrigação foi cumprida em parte. O ideal é que a multa tenha relação com o prejuízo real e com o trabalho já entregue.

Preciso registrar o software no INPI?

Não é obrigatório. O art. 3º da Lei 9.609/1998 diz que o registro é facultativo, a critério do titular. Ele pode servir como prova de autoria em uma eventual disputa.

Vale a pena colocar arbitragem no contrato de software?

Depende do valor e da complexidade do projeto. A arbitragem permite escolher árbitros com conhecimento técnico e, sem prazo combinado, a lei prevê sentença em seis meses. Como o custo costuma ser alto, ela faz mais sentido em contratos de valor elevado.

O que deve ser entregue quando o contrato termina?

Código-fonte atualizado, documentação técnica, credenciais de acesso, cópia dos dados e lista de pendências conhecidas. A cláusula de rescisão deve fixar prazos curtos para cada item. Sem isso, a empresa pode ficar dependente do antigo fornecedor.

Contrato de preço fechado é mais seguro que contrato por hora?

Cada modelo transfere o risco de um jeito. O preço fechado exige escopo muito bem descrito e regra clara para mudanças. O modelo por hora exige relatórios, teto e aprovação prévia de tarefas.

Fontes: Lei nº 9.609/1998 (Lei do Software), Planalto · Lei nº 9.610/1998 (Direitos Autorais), Planalto · Lei nº 13.709/2018 (LGPD), Planalto · Lei nº 9.307/1996 (Arbitragem), Planalto · Resolução CD/ANPD nº 15/2024, texto integral (LegisWeb) · Cláusula penal: possibilidade de redução equitativa, TJDFT