7 cláusulas pra revisar no contrato de software sob medida

A conversa costuma ser assim: proposta aceita, prazo combinado, contrato chegou em Word, 4 páginas. Dono de empresa assina porque já quer começar. Oito meses depois descobre que não tem acesso ao código, que não existe garantia de bug pós-entrega, e que rescisão vai custar 40% do valor total.

Não é má-fé da software house. É modelo de contrato copiado de template genérico que circula no mercado desde 2008 — quando entrega de software funcionava de forma diferente, código ficava em servidor físico, e ninguém pensava em LGPD.

Antes de assinar contrato de software sob medida, revise 7 cláusulas críticas: (1) propriedade do código-fonte deve ser do cliente desde o commit 1, em repositório próprio — nunca “após pagamento integral”; (2) revisões com limite numérico e valor/hora claro pra extra; (3) prazo em dias úteis com gatilhos de extensão objetivos; (4) pagamento parcelado em marcos, não 100% antecipado; (5) garantia pós-entrega de pelo menos 30 dias pra bugs; (6) NDA recíproco com cláusula LGPD explícita; (7) rescisão com portabilidade documentada — levo o quê, em quantos dias, em qual formato. Quem revisa essas 7 antes de assinar evita 90% dos litígios.

Esse post é pra dono de PME B2B que já decidiu contratar sistema sob medida — ou que já assinou e quer saber se o contrato tem buracos antes de a entrega começar. Você já passou pelos comparativos, escolheu a casa, leu sobre como contratar software house pequena confiável. Agora está na última milha antes de assinar. Esse é o momento em que a revisão vale mais.

Aviso antes de começar: esse post é checklist técnico-comercial, não parecer jurídico. O conteúdo aqui não substitui revisão por advogado — especialmente pra contratos de alto valor. O que esse post faz é identificar as 7 cláusulas que mais frequentemente geram atrito, pra você saber o que perguntar e o que pedir antes de assinar.

Por que contrato de software BR tende à armadilha (sem má-fé de ninguém)

Contratos de desenvolvimento de software no Brasil têm um problema de origem: a maioria das casas pequenas (1-5 pessoas) não tem advogado interno. Elas usam modelo que alguém passou, que veio de outra casa, que copiou de template online, que foi escrito antes da Lei Geral de Proteção de Dados (LGPD — Lei nº 13.709/2018), antes do cloud computing virar padrão, e antes de repositório GitHub existir como infraestrutura universal.

O resultado é um contrato que protege quem o escreveu — a casa de software — sem intenção deliberada de prejudicar o cliente. Protege porque foi escrito do ponto de vista de quem entrega, não de quem contrata.

Quatro cláusulas ausentes que aparecem em quase todo template genérico:

• Sem cláusula de repositório do cliente
• Sem limite numérico de revisões
• Sem definição de “bug” vs “nova funcionalidade”
• Sem portabilidade em caso de rescisão

Cada uma dessas ausências tem custo real quando o projeto começa a ter problema. Vamos cláusula a cláusula.

As 7 cláusulas que precisam de revisão

Cláusula 1 — Propriedade intelectual e código-fonte

Essa é a cláusula mais importante do contrato. E é a que mais aparece errada.

O risco: contrato que diz “propriedade do código transferida após pagamento integral” significa que, durante todo o desenvolvimento, o código não é seu. Se a casa de software fechar, travar pagamento por qualquer motivo, ou simplesmente não responder, você não tem acesso ao que foi construído até ali.

A redação prática: “O código-fonte produzido neste contrato é de propriedade exclusiva do CONTRATANTE desde o primeiro commit. O repositório ficará hospedado em conta GitHub (ou GitLab/Bitbucket) de titularidade do CONTRATANTE, com acesso de administrador concedido desde o início do projeto. A CONTRATADA terá acesso de colaboradora para fins de desenvolvimento, que pode ser revogado a qualquer momento pelo CONTRATANTE.”

O que perguntar à software house antes de assinar: “O repositório fica no meu GitHub ou no de vocês durante o projeto?”

Resposta verde: no seu. Resposta vermelha: “fica no nosso servidor até o final”.

Se a casa hesitar nessa pergunta, essa é a informação mais importante que você vai ter antes de assinar.

Cláusula 2 — Escopo e revisões

O risco: contrato sem limite de revisões cria ambiguidade sobre o que é “ajuste” e o que é “nova funcionalidade”. A casa de software pode cobrar extra por uma mudança de texto. Você pode pedir 15 rodadas de ajuste achando que estão inclusas.

A redação prática: “Estão inclusas neste contrato [X] rodadas de revisão por módulo ou fase entregue. Rodada de revisão é definida como: conjunto de ajustes solicitados por escrito após demo aprovada, respondidos em até [N] dias úteis. Funcionalidade não listada no escopo original ou alteração de escopo aprovado é tratada como aditivo, cobrado à razão de R$ [Y] por hora, aprovado por escrito antes de iniciar.”

O número de revisões inclusas varia por casa e por tamanho de projeto. O mais importante é ter o número — e a definição do que conta como revisão. Sem isso, toda conversa sobre mudança é negociação informal.

Aprofundei o tema de como escopo claro reduz fricção em escopo aberto vs fixed price em sistema sob medida.

Cláusula 3 — Prazo, atrasos e marcos

O risco: prazo escrito como “aproximadamente 60 dias” ou “estimativa de 8 semanas” não é prazo — é intenção. Sem prazo em dias úteis e sem gatilhos de extensão objetivos, atraso vira ponto de negociação subjetiva.

A redação prática: “O prazo total de desenvolvimento é de [N] a [M] dias úteis, contados a partir da data de aprovação do briefing final e recebimento do adiantamento previsto neste contrato. O prazo pode ser estendido nos seguintes casos, com notificação escrita prévia: (a) atraso superior a [2] dias úteis na entrega de pré-requisitos pelo CONTRATANTE (credenciais, acessos, aprovações); (b) mudança de escopo aprovada em aditivo. Cada semana de atraso em pré-requisito do CONTRATANTE estende o prazo proporcionalmente.”

O detalhe do “pré-requisito do CONTRATANTE” é importante: em todo projeto de sistema, a empresa que contrata precisa entregar coisas — acesso a sistemas existentes, dados de credencial, aprovação de telas. Se você atrasar, o prazo precisa ajustar. Essa cláusula protege os dois lados.

Para projetos bem-escopados com a Adrion, o prazo fica entre 3 e 12 dias úteis dependendo da complexidade — o contrato crava os marcos e define exatamente o que cada marco inclui.

Cláusula 4 — Pagamento e parcelamento

O risco: pagamento 100% antecipado é o maior risco financeiro pra quem contrata. Pagamento 100% apenas na entrega é o maior risco financeiro pra quem desenvolve. Ambos os extremos criam tensão.

A redação prática (três modelos, do mais ao menos conservador):

Modelo A — 50/50: “50% na assinatura do contrato. 50% na aprovação do go-live final com testes completados.”

Modelo B — 30/30/40 por marcos: “30% na assinatura. 30% na conclusão e aprovação da Fase 1 [descrição da fase]. 40% no go-live aprovado com checklist de testes.”

Modelo C — 3 milestones: “30% na assinatura. 40% na demo aprovada das funcionalidades principais. 30% no go-live com aceite formal do cliente.”

O Modelo B e C são os mais equilibrados: você não expõe 100% antes de ver nada, e a casa de software não corre 100% do risco sem receber até o final. A Adrion estrutura pagamento em 3 milestones cravados — valor total fechado, sem cobrança recorrente até manutenção pós-go-live.

Cláusula 5 — Garantia pós-entrega

O risco: sistema vai ao ar e aparece bug em fluxo que não foi testado. Se não existe cláusula de garantia, o cliente recebe charge de hora pra corrigi-lo. Tecnicamente, o Código Civil Brasileiro (art. 618 e seguintes) cobre vícios ocultos, mas a aplicação a software ainda é interpretação judicial — e litigar é caro.

A redação prática: “A CONTRATADA garante correção de bugs identificados nas funcionalidades descritas neste contrato por prazo de [30] dias corridos após o go-live aprovado. Entende-se por bug comportamento diferente do especificado e aprovado nas demos. Não se enquadra como bug: (a) funcionalidade não listada no escopo; (b) comportamento diferente de nova solicitação do CONTRATANTE feita após o go-live; (c) incompatibilidade com ambiente de terceiros não declarado no escopo. Após o prazo de garantia, correções e manutenção estão disponíveis mediante contrato de manutenção separado.”

A definição do que é “bug” é tão importante quanto o prazo. Sem ela, toda reclamação vira negociação sobre se é bug ou nova funcionalidade.

Cláusula 6 — Confidencialidade e LGPD

O risco: durante o desenvolvimento, a software house tem acesso a dados da empresa — dados de clientes, processos internos, regras de negócio proprietárias. Sem NDA (Non-Disclosure Agreement, ou Acordo de Confidencialidade) explícito, essa proteção é fraca.

Com a LGPD em vigor, dados pessoais de clientes processados durante o desenvolvimento precisam de tratamento explícito contratual. Isso inclui dados usados em testes com base real.

A redação prática: “As partes se comprometem a manter sigilo sobre todas as informações trocadas durante o desenvolvimento, incluindo processos, regras de negócio, dados de clientes, credenciais de acesso e qualquer dado considerado sensível pela LGPD (Lei nº 13.709/2018). Essa obrigação persiste por [2] anos após o encerramento do contrato. Dados pessoais de clientes do CONTRATANTE utilizados em ambiente de teste devem ser anonimizados ou mascarados. A CONTRATADA não pode divulgar, vender ou compartilhar quaisquer informações do CONTRATANTE com terceiros.”

O NDA deve ser recíproco: a software house também tem informações que você não deve vazar — como o processo deles de desenvolvimento, ferramentas internas, metodologia.

Cláusula 7 — Rescisão e portabilidade

O risco: você precisa encerrar o contrato — por qualquer motivo. Sem cláusula de portabilidade clara, a pergunta “o que levo comigo?” não tem resposta objetiva. Código parcial sem documentação é praticamente inutilizável por outra casa de software.

A redação prática: “Em caso de rescisão por qualquer parte, a CONTRATADA entregará ao CONTRATANTE em até [10] dias úteis: (a) todo o código-fonte desenvolvido até a data da rescisão, no repositório do CONTRATANTE; (b) documentação técnica da arquitetura e das funcionalidades concluídas; (c) lista de dependências, bibliotecas e serviços de terceiros utilizados com versões; (d) acesso pleno ao ambiente de produção (se já implantado). O CONTRATANTE é responsável pelo pagamento das fases completadas até a data de rescisão, conforme milestones definidos. Multa rescisória, se aplicável, fica limitada a [20%-30%] do valor total do contrato.”

A multa rescisória acima de 30% do valor total é um dos red flags mais frequentes que aparecem em contratos genéricos. A rescisão precisa ter custo — mas não pode ser desincentivo tão alto que trava o cliente num projeto que não está funcionando.

Cláusulas que não deveriam estar no contrato (red flags)

Algumas cláusulas aparecem em contratos e são problemáticas pra você como contratante. Sinalize ao advogado se encontrar:

Exclusividade vitalícia de manutenção: “O CONTRATANTE compromete-se a contratar apenas a CONTRATADA pra manutenções do sistema desenvolvido por prazo indeterminado.” — Isso é lock-in por contrato. Sem prazo definido, você não pode trocar de fornecedor sem multa mesmo se a qualidade cair.

Renovação automática silenciosa de manutenção: “O contrato de manutenção se renova automaticamente por 12 meses caso não haja cancelamento com [90] dias de antecedência.” — 90 dias de antecedência pra cancelar é tempo excessivo. O padrão aceitável é 30 dias.

Multa rescisória acima de 30%: Multa de 40%, 50% ou “equivalente ao valor total restante” cria situação em que rescisão legítima (por atraso, por qualidade) custa mais do que aguentar o projeto ruim. Essa cláusula favorece quem entrega mal.

Propriedade intelectual “compartilhada”: “O código desenvolvido é de propriedade compartilhada entre CONTRATANTE e CONTRATADA.” — Propriedade compartilhada significa que a casa de software pode reusar seu código em outro cliente. Se o sistema tem processo diferenciado ou dado sensível, essa cláusula é problemática.

Ausência de cláusula de portabilidade: Contrato que não menciona o que acontece com o código em caso de rescisão coloca você numa posição de dependência total da boa vontade da casa de software pra receber o que foi construído com seu dinheiro.

Template: 5 perguntas pra fazer ao seu advogado

Se você tem advogado interno ou jurídico externo disponível, essas 5 perguntas direcionam a revisão pra onde mais importa:

1. A cláusula de propriedade intelectual transfere propriedade plena ao contratante desde o início? Pedir que revise o trecho de propriedade e confirme que não há ambiguidade sobre titularidade durante o desenvolvimento.

2. O prazo está cravado em dias úteis com gatilhos de extensão objetivos? Prazo “estimado” sem consequência jurídica pra atraso é apenas boa intenção. Pedir redação com consequência objetiva.

3. A multa rescisória está dentro de 20-30% do valor total do contrato? Acima de 30% é desincentivo excessivo. Acima de 50% pode ser cláusula abusiva (art. 413 do Código Civil Brasileiro permite redução judicial de pena manifestamente excessiva).

4. A cláusula de confidencialidade cobre LGPD explicitamente pra dados de teste? Muitos contratos têm NDA mas não mencionam tratamento de dados pessoais durante desenvolvimento — gap que pode gerar responsabilidade civil e administrativa.

5. A portabilidade está descrita em prazo e formato específico pra rescisão? Pedido genérico de “entregar o código” não é suficiente. Prazo específico + formato + acesso ao ambiente de produção precisam estar no contrato.

Antes de assinar: um passo prático

Leia o contrato que você recebeu e marque, em caneta, cada uma das 7 cláusulas acima — se existe, se está incompleta, se está ausente.

Cláusula ausente não significa que a software house é desonesta. Significa que o modelo deles não cobre esse ponto e que a negociação é possível. A maioria das casas sérias aceita adicionar essas cláusulas quando solicitado de forma objetiva.

Se a casa de software resistir a incluir propriedade no cliente desde o início, cláusula de portabilidade, ou NDA recíproco — esse é sinal mais importante que qualquer referência ou portfólio.

Entender como o contrato se encaixa com o escopo do projeto é outro passo crítico: se você ainda não mapeou todas as regras de negócio antes de orçar, leia como mapear a regra da Joana antes de pedir orçamento — escopo vago + contrato genérico é a combinação que produz 90% dos litígios em projeto de sistema.

Para quem está em estágio de decisão sobre qual modelo contratual faz mais sentido (fixed price vs escopo aberto), aprofundei os riscos de cada um em escopo aberto vs fixed price em sistema sob medida.

Se você quer entender como a entrega acontece na prática, depois de contrato assinado, o post anatomia de uma implementação de 8 semanas mostra fase a fase o que acontece — e quando cada uma das 7 cláusulas acima vira relevante na prática.

Se você já tem proposta e contrato em mãos e quer uma análise técnica e comercial antes de assinar — não jurídica, mas de quem leu muito contrato de software dos dois lados — manda “análise contrato” no WhatsApp. São 30 minutos de conversa, sem compromisso. Em uns 20-25% dos casos a resposta é “esse contrato está adequado, pode assinar”. No restante, a gente identifica o que precisa ajustar antes de começar.

Este post não substitui parecer jurídico. As sugestões de redação aqui são referências técnico-comerciais baseadas em experiência de mercado, não assessoria legal. Para contratos de valor relevante, revisão por advogado especializado em contratos de TI é recomendada.

Sobre o autor: Lucas Américo dos Reis é fundador do Grupo Adrion. Atua em telecom corporativo e arquitetura de sistemas desde 2008 (GVT, Brasil Telecom, Oi, Claro, Embratel, Vivo). LinkedIn