Contrato de desenvolvimento de software: o que precisa estar escrito

A maior parte das brigas entre empresa e fornecedor de software não começa no código. Começa numa frase que ninguém escreveu. O que era “pronto”? Quem paga a mudança que apareceu no meio? De quem é o repositório? Quando o projeto vai bem, essas perguntas não aparecem. Quando atrasa, elas viram o projeto inteiro.

O contrato é o único lugar onde essas respostas ficam registradas antes do problema. Neste guia eu listo o que precisa estar escrito num contrato de desenvolvimento de software, do escopo ao código-fonte, com o que a lei brasileira já diz sobre o assunto. Não é parecer jurídico: é o checklist de quem já viu muitos projetos começarem e terminarem.

Por que o contrato padrão do fornecedor costuma proteger só ele

Todo fornecedor tem um modelo de contrato. É normal. O que você precisa entender é que esse modelo foi escrito para reduzir o risco de quem o redigiu. Cláusulas vagas de escopo, prazo “estimado”, código que só é entregue no fim e licença de uso no lugar de titularidade são comuns.

Nada disso é ilegal. Só que tudo isso joga o risco para o seu lado. E você costuma perceber só quando quer trocar de equipe, como contamos no artigo sobre o freelancer que sumiu com o projeto. Ler o contrato com a lista abaixo na mão leva uma hora e evita meses de dor.

As 9 cláusulas que precisam estar no contrato

1. Escopo descrito em entregas, não em horas

O escopo deve dizer o que a pessoa usuária vai conseguir fazer no sistema: cadastrar pedido, aprovar pagamento, emitir relatório. “Desenvolvimento de plataforma web” não é escopo. Junte ao contrato um anexo com as telas, os perfis de acesso e as integrações (gateway de pagamento, ERP, WhatsApp). O que não está no anexo não está no preço, e isso vale para os dois lados.

2. Prazo escrito, com marcos

Prazo “estimado” não é prazo. Peça uma data final e marcos intermediários, cada um com uma entrega que você consegue abrir e testar. Escreva também o que acontece se o prazo estourar por culpa do fornecedor: desconto, multa ou direito de rescindir sem pagar a parcela seguinte.

3. Preço e pagamento atrelados a entregas

Pagamento por marco protege quem contrata. Você paga quando recebe algo que funciona, não quando passa um mês. Desconfie de contratos com a maior parte do valor adiantada e de reajustes sem índice definido.

4. Regra para mudanças de escopo

Todo projeto muda. O problema não é mudar, é não ter regra. O contrato deve dizer como uma mudança é pedida, quem aprova, como o impacto em preço e prazo é calculado e que nada novo começa sem aprovação por escrito. Uma alternativa melhor é trocar uma função por outra de mesmo tamanho, sem mexer na data. Explicamos essa lógica em cortar escopo para caber na data.

5. Critério de aceite

O que significa “entregue”? O contrato precisa definir um período de teste depois de cada entrega, o que conta como defeito e o prazo para corrigir. Sem isso, o fornecedor considera entregue no dia em que publica, e você descobre os erros sozinho.

6. Titularidade do código, dos arquivos e dos acessos

Esta é a cláusula mais importante. A Lei do Software (Lei nº 9.609/1998) diz, no artigo 4º, que, “salvo estipulação em contrário”, os direitos sobre o programa desenvolvido durante o contrato e para aquele fim pertencem ao contratante. Parece resolvido, mas a ressalva é justamente o ponto: basta uma cláusula no contrato do fornecedor dizendo que ele mantém os direitos e você recebe só uma licença de uso.

E esses direitos duram muito. A mesma lei garante a proteção do programa por 50 anos, contados a partir de 1º de janeiro do ano seguinte à publicação ou à criação. Escreva sem margem para dúvida:

• o código-fonte, os arquivos de design e a documentação são do contratante;
• o repositório fica numa conta da sua empresa desde o primeiro dia, com acesso do fornecedor, e não o contrário;
• domínio, hospedagem, banco de dados, contas de e-mail transacional e contas nas lojas de apps são registrados em nome da sua empresa;
• bibliotecas de terceiros e componentes que o fornecedor reaproveita de outros projetos ficam listados, com a licença de cada um.

7. Proteção de dados (LGPD)

Se o sistema trata dados de clientes, pacientes ou funcionários, sua empresa é a controladora e o fornecedor é operador desses dados. A LGPD exige que o operador trate os dados conforme as instruções do controlador, e o operador que descumpre a lei responde junto pelos danos.

O risco é alto. Pelo artigo 52, a multa simples pode chegar a 2% do faturamento da empresa no Brasil no último exercício, limitada a R$ 50 milhões por infração, como detalha o comentário da Aurum aos artigos 52 a 54. O contrato precisa dizer onde os dados ficam, quem acessa, quais medidas de segurança são obrigatórias, em quanto tempo um incidente é comunicado a você e o que acontece com os dados quando o contrato acaba.

8. Garantia e suporte depois da entrega

Defeitos aparecem depois que o sistema vai ao ar. O contrato deve trazer um período de garantia em que erros são corrigidos sem custo, e separar claramente o que é defeito (algo que não funciona como foi combinado) do que é melhoria (algo novo). Se houver manutenção depois disso, ela precisa de um contrato próprio, com tempo de resposta definido.

9. Saída: como encerrar levando tudo

Ninguém assina contrato pensando no fim, e é por isso que essa cláusula costuma faltar. Escreva como qualquer uma das partes pode rescindir, o que é pago até ali e, principalmente, a obrigação de entregar código atualizado, acessos, documentação e senhas em poucos dias. Um contrato com boa saída é o que deixa você trocar de fornecedor sem parar a empresa.

Sinais de alerta antes de assinar

Algumas frases merecem uma segunda leitura, e uma pergunta direta ao fornecedor:

• “O código será entregue ao final do projeto.” Por que não desde o início, num repositório seu?
• “Prazo estimado de X semanas.” O que acontece se passar disso?
• “Licença de uso do software.” Você está comprando um sistema ou alugando?
• “Alterações serão orçadas à parte.” Qual é a regra? Quem aprova?
• Nenhuma menção a dados pessoais num sistema que claramente vai guardar dados de clientes.

Se o fornecedor resiste a mudar esses pontos, isso diz mais sobre a relação do que qualquer portfólio. Outras perguntas que vale fazer na conversa estão em perguntas para fazer antes de contratar um estúdio de software.

O que isso muda para você

Antes de pedir orçamento, decida três coisas: o que precisa estar no ar na primeira versão, qual é a data que importa para o seu negócio e quanto você pode investir. Com isso, o fornecedor consegue fazer um diagnóstico e fechar escopo, preço e prazo por escrito. Sem isso, qualquer contrato vira uma aposta.

Depois, leia o contrato com esta lista. Peça para mudar o que estiver vago. E, se o projeto envolve dados sensíveis ou um valor alto, leve o texto a um advogado antes de assinar.

Como fazemos no Studio

No Studio Responsivo, o preço é fechado depois do diagnóstico e o prazo fica escrito no contrato. O código, os arquivos e os acessos ficam em nome do cliente. A equipe de devs é do próprio Studio, então quem assina é quem entrega.

Foi assim com a LCX, empresa de turismo com operação em mais de 10 países da América do Sul: um sistema por país virou um sistema só, no ar em 29 dias. Todo sistema que entregamos sai com um agente de IA que roda todo dia, aponta falhas, sugere melhorias e confere se os dados fazem sentido.

Se você está prestes a contratar um sistema e quer um contrato que diga, por escrito, o que entra, quando entra e de quem é, conheça como colocamos sistemas e SaaS sob medida no ar.