Contrato de Desenvolvimento de Software: O Que Incluir?
Um contrato de desenvolvimento de software de uma página, copiado de um modelo pronto na internet, não protege ninguém. Ele não diz quem é dono do código depois do pagamento final, não define o que conta como entrega aprovada e não trata do que acontece se o prazo estourar. Quando o projeto sai dos trilhos, é justamente esse contrato que devia responder essas perguntas e não responde.
Este artigo lista as cláusulas que todo contrato de desenvolvimento de software precisa ter, mostra a diferença entre fechar por escopo fixo ou por hora, e os erros mais comuns que geram disputa depois da assinatura.
O que é um contrato de desenvolvimento de software
Contrato de desenvolvimento de software é o documento que define o que será entregue, por quanto e sob quais condições, entre quem contrata e quem constrói o sistema. Ele existe para substituir promessa verbal por compromisso escrito, com consequência definida para cada lado se algo não sair como combinado.
Isso vale tanto para uma agência quanto para um desenvolvedor autônomo. O tamanho do fornecedor não muda a necessidade do contrato: muda só o quanto ele costuma vir pronto de fábrica, e agência grande também erra cláusula.
Quais cláusulas o contrato precisa ter
Um contrato de desenvolvimento de software sem estas cláusulas deixa buraco para disputa. Siga esta ordem ao revisar uma minuta antes de assinar:
- Escopo detalhado. Lista do que está incluído no preço, tela por tela ou funcionalidade por funcionalidade. "Sistema de gestão completo" descreve uma intenção. Se o documento não permite contar quantas telas existem, o escopo ainda não está fechado.
- Forma de pagamento atrelada a entrega. Parcela liberada quando uma etapa é aceita, não por data no calendário. Isso alinha o interesse dos dois lados: o fornecedor só recebe quando entrega algo verificável.
- Propriedade do código. Cláusula explícita dizendo que o repositório e todos os direitos passam para quem contratou após o pagamento final. Sem isso, o fornecedor pode reter acesso ao código mesmo com a fatura quitada.
- Critério de aceite. O que precisa funcionar, e sob quais condições, para uma entrega ser considerada aprovada. Sem critério escrito, "está pronto" vira opinião de quem entregou contra opinião de quem recebe.
- Prazo com previsão de atraso. Data de entrega e o que acontece se ela passar, incluindo se existe multa ou reunião obrigatória de replanejamento. Um contrato sem essa cláusula não tem prazo, tem estimativa.
- Rescisão. Como qualquer um dos dois lados pode encerrar o contrato antes do fim, o que já foi pago fica com quem, e o que acontece com o código produzido até aquele ponto.
Quem quer entender por que o escopo pesa tanto nessa lista pode ver o detalhamento em escopo de projeto de software.
Propriedade do código-fonte: o ponto que passa despercebido
Propriedade do código-fonte é a cláusula que define quem detém os direitos sobre o que foi programado depois que o projeto termina. Na maioria dos contratos mal escritos, essa linha simplesmente não existe, e a ausência dela não é neutra: em muitos países, na falta de cláusula explícita, quem programou continua sendo o autor legal do código, mesmo tendo sido pago para fazê-lo.
Isso importa na prática quando a relação com o fornecedor azeda. Sem a cláusula, pedir o repositório vira negociação, não direito. Peça a transferência de propriedade por escrito, com data de efeito amarrada ao pagamento final, antes de assinar qualquer coisa.
Contrato por escopo fechado ou por hora: qual escolher
A escolha entre escopo fechado e cobrança por hora depende de quanto o projeto ainda pode mudar depois de assinado o contrato. Escopo fechado trava o preço e o que será entregue, contra a promessa de que ninguém vai pedir mudança no meio do caminho sem repactuar valor.
Cobrança por hora faz mais sentido quando o projeto é exploratório, como um produto novo que ainda está testando o mercado e onde o próprio cliente não sabe ainda qual vai ser a versão final. Nesse caso, travar escopo cedo demais engessa decisões que ainda precisam de espaço para mudar.
Times que já validaram a ideia e sabem exatamente o que precisam construir ganham mais previsibilidade fechando por escopo. Quem ainda está descobrindo o produto perde menos dinheiro pagando por hora e ajustando a rota a cada sprint.
Erros comuns que geram disputa depois da assinatura
- Combinar mudança de escopo por mensagem, sem aditivo formal. Toda alteração de escopo precisa virar um documento assinado, mesmo que curto, com o novo preço e prazo.
- Aceitar entrega "quase pronta" para não atrasar pagamento. Isso empurra o problema para depois, quando o fornecedor já recebeu e perdeu o incentivo de corrigir.
- Não prever quem paga pela hospedagem e por licenças de terceiros. Sistema não é só código: envolve serviço de nuvem, domínio e ferramentas pagas que alguém precisa custear depois do lançamento.
- Ignorar o que acontece com o suporte depois da entrega. Contrato de desenvolvimento e contrato de manutenção são coisas diferentes, e assumir que um cobre o outro é onde muita empresa se surpreende com uma cobrança que não esperava. O tema de manutenção de software depois do lançamento merece leitura antes de assinar.
Revisar essas quatro pontas antes da assinatura custa uma tarde de trabalho. Descobrir a falta delas no meio de um projeto custa muito mais.
Se você está fechando um fornecedor agora e quer ajuda para revisar o contrato antes de assinar, fale com a gente.