Contrato com software house: o que verificar antes de assinar

Assinar um contrato com uma software house sem lê-lo com atenção é um dos erros mais caros que uma empresa pode cometer. Problemas de propriedade intelectual, escopo indefinido e ausência de SLA são a origem da maioria dos conflitos entre clientes e fornecedores de software no Brasil.

Este guia apresenta as cláusulas mais importantes, o que deve estar explícito e os pontos que geram mais conflito na prática.

Por que o contrato importa tanto em desenvolvimento de software

Diferente de uma compra de produto físico, desenvolvimento de software é um serviço de resultado incerto por natureza. O produto final depende de decisões tomadas ao longo do projeto, de informações fornecidas pelo cliente e de condições técnicas que nem sempre são previsíveis no início.

Isso torna o contrato ainda mais importante — não para resolver conflitos, mas para preveni-los. Um contrato bem redigido alinha expectativas antes que o projeto comece.

Propriedade intelectual: a cláusula mais crítica

Esta é a cláusula que mais gera conflito e, paradoxalmente, a que mais aparece redigida de forma ambígua.

O que precisa estar explícito: todo o código-fonte, documentação, designs e ativos digitais produzidos durante o projeto pertencem ao contratante após o pagamento integral. Isso inclui bibliotecas customizadas, componentes de interface e integrações desenvolvidas especificamente para o projeto.

O que observar: algumas software houses incluem cláusulas que reservam para si o direito de reutilizar componentes do projeto em outros clientes. Isso pode ser aceitável para componentes genéricos, mas não para lógica de negócio proprietária. Leia com atenção.

Outro ponto: o código produzido durante o projeto deve ser entregue ao cliente em repositório acessível, não apenas no ambiente de produção. Garanta isso no contrato.

Escopo e gestão de mudanças

O escopo define o que está dentro do projeto — e, por consequência, o que gera cobrança adicional quando solicitado fora do acordo original.

Um bom contrato descreve o escopo de forma detalhada (ou referencia um documento de escopo em anexo) e estabelece um processo claro para mudanças: como são solicitadas, em quanto tempo são orçadas e aprovadas, e qual é o impacto em prazo e custo.

Sem esse processo definido, qualquer pedido do cliente pode gerar uma discussão sobre se está ou não dentro do escopo — e essas discussões consomem energia de ambos os lados e deterioram o relacionamento.

SLA e critérios de aceite

SLA (Service Level Agreement) define os padrões de qualidade e tempo de resposta que a software house se compromete a cumprir.

Em contratos de projeto, o SLA mais relevante é o critério de aceite: como a entrega será validada? Quem valida? Em quanto tempo o cliente pode rejeitar uma entrega e solicitar correções? Qual é o prazo para correção de bugs após a entrega?

Em contratos de squad dedicado ou suporte contínuo, o SLA inclui também tempo de resposta para incidentes (por exemplo, bug crítico em produção deve ser corrigido em até 4 horas).

Sem critérios de aceite definidos, qualquer entrega é subjetivamente "incompleta" para quem quiser argumentar isso.

Confidencialidade e LGPD

Se o projeto envolve dados de usuários — e a maioria dos produtos digitais envolve — o contrato precisa endereçar responsabilidades relacionadas à LGPD (Lei Geral de Proteção de Dados).

Quem é o controlador dos dados? Quem é o operador? Como os dados são tratados durante o desenvolvimento e nos ambientes de teste? O que acontece com os dados ao fim do contrato?

Além disso, o NDA (acordo de não divulgação) garante que informações estratégicas compartilhadas durante o projeto — modelo de negócio, dados de usuários, estratégias de produto — não sejam divulgadas ou usadas para outros fins.

Cláusulas de rescisão

O que acontece se o projeto precisar ser interrompido antes do fim? Essa é uma situação mais comum do que parece — mudança de estratégia, crise financeira, fusão da empresa — e o contrato precisa prever como lidar com ela.

Pontos importantes: o que acontece com o código produzido até o momento da rescisão? Há multa por rescisão antecipada? Qual é o prazo de aviso prévio? Como é feita a transferência de conhecimento para o cliente ou para outro fornecedor?

Garantia pós-entrega

Após a entrega do projeto, é razoável esperar um período de garantia durante o qual a software house corrige bugs sem custo adicional. O padrão de mercado varia de 30 a 90 dias para bugs funcionais (funcionalidades que não funcionam como especificado).

Atenção: garantia cobre bugs, não novas funcionalidades. Se o cliente pede algo que não estava no escopo original, isso é uma nova demanda — não um bug.

Perguntas frequentes

Preciso de um advogado para revisar o contrato com uma software house? Para projetos acima de R$ 50 mil ou com dados sensíveis de usuários, sim. O custo de uma revisão jurídica é muito menor do que o custo de um conflito mal resolvido. Para projetos menores, pelo menos garanta que os pontos desta lista estejam cobertos.

A software house pode usar código de terceiros (open source) no meu projeto? Sim, e é uma prática comum e legítima. O que precisa estar claro é quais bibliotecas open source foram usadas e sob quais licenças. Algumas licenças open source impõem restrições ao uso comercial — o contrato deve garantir que a software house é responsável por usar apenas código com licenças compatíveis com o seu modelo de negócio.

O que fazer se a software house não entregar o código-fonte ao fim do projeto? Isso é uma violação contratual. Se estiver previsto em contrato, você tem respaldo jurídico para exigir. Por isso a importância de incluir essa cláusula explicitamente antes de começar.

Compare software houses com histórico verificado e avaliações de clientes no Softdex — antes de assinar qualquer contrato.