O projeto começou com aperto de mão e almoço de comemoração. Dezoito meses depois, terminou com e-mails frios e advogado em cópia. A entrega não fazia o que tinha sido combinado em reunião, o fornecedor cobrava por cada correção e, quando a empresa decidiu trocar, veio a pior descoberta: o código estava num repositório que só o fornecedor acessava, e o contrato de duas páginas, assinado às pressas para “não atrasar o início”, não dizia uma palavra sobre isso. Reler aquele documento foi como descobrir, no dia do incêndio, que a apólice não cobria incêndio.
Contrato de software tem uma característica ingrata: enquanto tudo vai bem, ninguém abre. Quando algo dá errado, ele vira a única coisa que importa. E software é uma compra em que muita coisa pode dar errado: escopo interpretado de dois jeitos, entregas que não funcionam, fornecedor que muda de prioridade, de dono ou de endereço.
A tese deste artigo é simples: contrato bom é o que foi escrito para o dia ruim, e montá-lo não exige juridiquês nem clima de desconfiança. Exige clareza sobre meia dúzia de pontos que qualquer gestor consegue conferir, e que este texto apresenta um a um.
O que é um contrato de desenvolvimento de software?
É o documento que define o que será construído, em que condições e com quais garantias: quem é dono do código produzido, como se verifica se a entrega está correta, o que o fornecedor corrige sem custo depois da entrega, como funciona o suporte e o que acontece se a relação terminar. Um bom contrato transforma promessas de reunião em compromissos verificáveis, com nome, prazo e consequência.
Ele não substitui a escolha de um bom fornecedor, e nenhum contrato salva um projeto conduzido por quem não sabe entregar. Mas funciona como o cinto de segurança: você escolhe um bom motorista e, ainda assim, coloca o cinto.
Por que o contrato só importa quando algo dá errado?
Porque essa é exatamente a função dele. Nos meses em que as entregas chegam e as reuniões terminam em acordo, o contrato dorme na gaveta. Ele acorda quando surge a divergência: a empresa diz que o módulo estava no combinado, o fornecedor diz que é escopo novo, e alguém precisa de um texto para apontar. Se o texto não existe ou não trata do assunto, a divergência vira queda de braço, e queda de braço com quem segura o seu código é um jogo desequilibrado.
Há um segundo motivo, menos óbvio: a negociação do contrato revela o fornecedor antes do primeiro boleto. Quem aceita com naturalidade formalizar propriedade do código, critérios de aceite e condições de saída está dizendo que pretende cumprir. Quem resiste, adia ou responde “isso a gente vê depois” também está dizendo algo, e vale a pena escutar.
Quais cláusulas protegem de verdade a sua empresa?
- Propriedade intelectual do código. O contrato deve dizer, com todas as letras, que o código e os demais produtos do projeto pertencem à contratante. Sem isso, você corre o risco de pagar pelo sistema e não ser dono dele. Já detalhamos o que sua empresa deve ter em mãos de código-fonte e documentação; o contrato é onde esse direito nasce.
- Escopo e critérios de aceite anexados. A proposta e a definição do que será entregue devem ser anexos formais do contrato, junto com os critérios que caracterizam “entrega aceita”. Um escopo de software bem definido só protege quando está dentro do contrato, não na troca de e-mails.
- Garantia de correção pós-entrega. Defeitos identificados dentro de um prazo definido são corrigidos sem custo adicional. Prazo e abrangência claros evitam a discussão clássica sobre o que é defeito e o que é melhoria nova.
- SLA de suporte. Tempos de resposta e de solução conforme a gravidade do problema. Sistema parado em plena operação é cenário que o contrato precisa prever antes de acontecer, não negociar durante a crise.
- Confidencialidade e proteção de dados. O fornecedor terá acesso a informações do negócio e, muitas vezes, a dados pessoais de clientes. Sigilo, limites de uso e responsabilidades sobre esses dados precisam estar escritos, com a lei brasileira como piso.
- Condições de saída. A cláusula mais esquecida e uma das mais valiosas: ao fim da relação, por qualquer motivo, o fornecedor entrega código atualizado, documentação, acessos e um período de transição assistida. Saída organizada prevista em contrato é o que impede o aprisionamento na prática.
Quais bandeiras vermelhas pedem atenção antes de assinar?
- Silêncio sobre propriedade do código. Se o contrato não diz de quem é o código, você depende de interpretação jurídica no pior momento possível. Essa cláusula não é detalhe, é o coração do documento.
- Escopo genérico. “Desenvolvimento de sistema de gestão comercial” num parágrafo único é um convite ao conflito. Sem anexo detalhado, cada divergência futura vira palavra contra palavra.
- Garantia simbólica. Prazo de garantia curto demais, ou garantia que exclui na letra miúda quase tudo, transforma qualquer correção em novo orçamento.
- Aprisionamento disfarçado. Multa de rescisão desproporcional, fidelidade longa, hospedagem obrigatória com o fornecedor sem previsão de migração. Somadas, essas cláusulas custam caro na hora de sair.
- Pagamento quase todo antecipado. Pagamento saudável acompanha entregas aceitas. Concentrar o valor no início remove o principal incentivo de ritmo e qualidade do projeto.
- Resistência a formalizar. A frase “isso a gente resolve na confiança” costuma anteceder exatamente as situações em que a confiança não resolve.
O contrato precisa proteger os dois lados?
Precisa, e desconfie do desequilíbrio nos dois sentidos. Um fornecedor sério também tem o que proteger: pagamento em dia, regras claras para mudança de escopo, colaboração do cliente com acessos, informações e homologações em prazo razoável. Contrato leonino contra o fornecedor afasta justamente os bons, que podem escolher clientes, e atrai quem assina qualquer coisa porque não pretende honrar nada.
Vale dizer também o óbvio que costuma ser pulado: leve o contrato para revisão jurídica antes de assinar. O advogado garante a forma e a validade; a sua parte, como gestor, é garantir que a substância esteja lá, ou seja, as cláusulas listadas acima. E lembre que o contrato é uma peça de uma avaliação maior do parceiro: o nosso checklist para contratar uma software house cobre o restante desse processo, do portfólio à forma de trabalhar.
Um bom contrato é sinal de fornecedor sério
Inverta a leitura habitual: contrato detalhado não é burocracia que atrapalha a parceria, é o retrato de um fornecedor que pretende cumprir o que promete e não tem medo de assinar embaixo. Propriedade do código, aceite objetivo, garantia, SLA e saída organizada protegem a sua empresa no dia ruim e, nos dias bons, dão à relação a tranquilidade de quem sabe as regras do jogo.
Se a sua empresa vai contratar um projeto de software, ou quer revisar os termos da relação atual antes que uma crise o faça, fale com o nosso time. Na DevCore, propriedade do código, critérios de aceite e condições de saída fazem parte do contrato padrão, porque relação boa começa com regra clara.
Perguntas frequentes sobre contrato de desenvolvimento de software
E se o contrato não disser nada sobre propriedade do código?
A questão vira discussão jurídica, no momento em que você menos pode pagar por uma. Se o seu contrato atual é omisso, o caminho é negociar agora um aditivo que formalize a propriedade e o acesso ao repositório, enquanto a relação está saudável, e não esperar a crise para tocar no assunto.
Posso usar um modelo de contrato pronto da internet?
Como rascunho inicial, talvez. Como versão final, é arriscado: modelos genéricos costumam ignorar exatamente o que protege em software, como critérios de aceite, SLA e condições de saída. Use as cláusulas deste artigo como checklist de substância e leve o texto para revisão jurídica.
Quando devo negociar o contrato: antes ou depois de fechar a proposta?
Junto com a proposta, sempre antes de qualquer início de desenvolvimento. Proposta e escopo devem entrar como anexos do contrato, formando um conjunto único. Começar o projeto com o contrato “para assinar depois” é abrir mão da sua melhor posição de negociação.