Contrato de desenvolvimento de software: o que não pode faltar

Contrato de desenvolvimento costuma fracassar no mesmo ponto: o escopo descreve tecnologia (aplicativo, painel, integração) e não comportamento entregável. A alternativa é descrever fases com resultado verificável, por exemplo cadastro de cliente com validação de documento em até dois segundos, relatório de faturamento exportável em CSV ou integração com o sistema de emissão de nota fiscal. Descrição de comportamento permite testar; descrição de tecnologia permite apenas discutir.

Junto com o escopo, defina o processo de mudança. Software muda de ideia no meio do caminho, e isso não é falha do cliente: é natureza do projeto. O contrato precisa de um caminho para pedido novo (lista priorizada, orçamento por item, prazo de resposta) e de uma regra clara sobre o que é correção do que foi contratado, que não pode ser cobrada à parte.

O aceite é o momento em que o projeto avança e a parcela vence, então ele precisa de prazo e de critério. Prazo: se ninguém se manifestar em determinado número de dias úteis, a entrega está aceita. Critério: defeito é a divergência entre o que foi entregue e o que estava escrito, e não todo ajuste de preferência que aparece depois de ver a tela funcionando. Sem essa distinção, qualquer melhoria entra como correção e o projeto não termina.

Registre o aceite por escrito, com data, versão entregue e responsável pela validação. Checklist de teste, evidência de execução e ambiente de homologação transformam discordância em histórico. Em contrato de software, histórico é o que sustenta a cobrança das etapas seguintes e o encerramento do projeto sem litígio.

O programa de computador é protegido pelo regime da Lei de Direitos Autorais (Lei 9.610/1998), e a Lei do Software (Lei 9.609/1998) trata da titularidade no ambiente de contratação. O ponto decisivo é que a regra legal é supletiva: o artigo 4 da Lei do Software define que, salvo estipulação em contrário, os direitos sobre o programa desenvolvido durante um contrato de serviço destinado a pesquisa e desenvolvimento pertencem ao contratante. Como a norma só vale quando nada foi escrito, o contrato precisa dizer quem fica com o código.

Na prática, o contrato trata quatro blocos distintos: código próprio desenvolvido no projeto, bibliotecas de código aberto (algumas licenças restringem uso comercial ou exigem publicação de alterações), componentes pagos de terceiros (com quem paga a licença ao longo do tempo) e ferramentas internas do fornecedor, que normalmente continuam sendo dele. A cessão de direitos patrimoniais segue os artigos 49 a 52 da Lei 9.610/1998 e precisa alcançar documentação, protótipos e identidade visual.

Entrega não é o fim do custo. Depois da entrada em produção existem três trabalhos diferentes, com preços diferentes: correção de defeito do que foi contratado, sustentação técnica (monitoramento, atualização de dependências, verificação de backup) e evolução (funcionalidade nova). Contrato que mistura os três em um valor único deixa a pergunta do que está incluso sem resposta, e o fornecedor acaba absorvendo trabalho que não orçou.

Defina prazo de atendimento por severidade, canal de abertura de chamado e janela de atendimento. Sistema que trava o faturamento não pode ter o mesmo prazo de um ajuste visual, e essa diferença precisa estar na tabela do contrato. Quando o sistema recebe dados pessoais, some a isso as medidas de segurança e o dever de comunicar incidente, na linha do que a LGPD exige de quem trata dados por conta de outra empresa.

O quadro abaixo reúne os pontos que decidem o destino de um projeto de software e serve de última leitura antes da assinatura, junto do modelo de contrato de desenvolvimento de software, que monta as cláusulas com os dados do projeto. A parte de disponibilidade medida, que entra quando o sistema passa a ser acessado pela internet, está em contrato de SaaS e nível de serviço, e a trilha completa fica em tecnologia e software.

Uma leitura atenta desse quadro antes de assinar costuma revelar dois ou três pontos em branco. Cada ponto em branco é uma decisão que o contrato deixa para o momento mais caro da relação, que é o momento em que o sistema já está em produção e a empresa depende dele.