Contrato de Software: 5 Cláusulas Que Você Deve Exigir

Você pagou pelo sistema. Assinou o contrato, fez o depósito, participou das reuniões iniciais. Em algum momento entre a terceira semana e o quinto mês, as respostas foram ficando mais lentas. Depois pararam. O sistema nunca foi ao ar, o dinheiro não voltou, e agora você opera com processo manual porque desconfia de qualquer pessoa que apareça com um notebook e uma proposta.

Essa situação não é rara. É um padrão reconhecível no mercado de desenvolvimento de software para pequenas e médias empresas, e ele acontece, na maioria das vezes, porque o contrato não protegia o contratante. Não porque o empresário foi descuidado, mas porque a maioria dos contratos de software é redigida para proteger quem entrega, não quem paga.

O que muda isso não é confiar mais ou confiar menos. É saber o que exigir antes de assinar.

O que um contrato de software precisa proteger

Um contrato de desenvolvimento de software não é formalidade. É o único instrumento que define o que você vai receber, quando vai receber, o que acontece se não receber e de quem é o código no final.

Contratos mal redigidos costumam ser vagos em quatro pontos críticos: escopo, prazo, propriedade do código e suporte pós-entrega. Quando esses pontos ficam em aberto, o fornecedor tem liberdade para entregar o mínimo, atrasar sem penalidade, manter o código como refém e desaparecer depois do go-live.

As cláusulas abaixo não são uma lista teórica. São o que qualquer empresa séria aceita colocar em contrato, e o que qualquer empresa séria já tem como padrão interno.

As 5 cláusulas que todo contrato precisa ter

1. Escopo detalhado por funcionalidade, não por intenção

O contrato precisa listar o que o sistema vai fazer, tela por tela, fluxo por fluxo, não em termos como "sistema de gestão completo" ou "plataforma integrada". Cada funcionalidade descrita em linguagem de negócio: "o sistema emite nota fiscal com integração à SEFAZ", "o painel exibe estoque em tempo real por filial", "o cliente recebe confirmação automática por WhatsApp após o pedido".

Escopo vago é o principal vetor de conflito em contratos de software. Quando o fornecedor diz "isso não estava no escopo", o que ele está dizendo, na prática, é que o contrato não era claro o suficiente para impedir isso.

Se o fornecedor resistir a detalhar o escopo, isso já é um sinal. Quem entrega bem não tem medo de especificar o que vai entregar.

2. Marcos de entrega com datas e critérios de aceite

O projeto precisa ter entregas intermediárias com datas definidas e critérios objetivos de aprovação. Não "entrega do módulo financeiro em fevereiro", mas "entrega do módulo financeiro com as funcionalidades X, Y e Z até o dia 15 de fevereiro, sujeito a aceite do cliente em até 5 dias úteis".

Isso serve para dois fins: você acompanha o andamento real do projeto antes do prazo final, e o fornecedor tem obrigação contratual de mostrar progresso em datas específicas. Projetos que somem geralmente somem entre marcos, não depois deles.

Fique atento a contratos que têm apenas uma data de entrega final. Isso dá ao fornecedor liberdade total até o último dia, e quando o prazo passa, o problema já está consolidado.

3. Propriedade do código-fonte

Essa é a cláusula que mais empresários esquecem de incluir e mais arrependem depois. O contrato precisa deixar explícito que o código-fonte desenvolvido pertence ao contratante, não ao fornecedor.

Sem essa cláusula, o fornecedor pode tecnicamente manter o código como propriedade intelectual dele. Isso significa que, se você precisar trocar de empresa, ampliar o sistema ou contratar outro desenvolvedor para corrigir um bug, você pode não ter acesso ao próprio sistema que pagou para construir.

O código que você pagou para existir precisa ser seu. Se o contrato não diz isso de forma explícita, assuma que não é.

Exija também acesso ao repositório de código durante o desenvolvimento, não só no final. Isso garante visibilidade do que está sendo construído e elimina o risco de receber um sistema que não pode ser mantido por ninguém além do fornecedor original.

4. Cláusula de penalidade por atraso e critério de rescisão

O contrato precisa prever o que acontece quando os prazos não são cumpridos. Uma cláusula razoável define multa proporcional por dia de atraso acima de um período de tolerância (normalmente 5 a 10 dias úteis), e critério de rescisão com devolução parcial ou total dos valores pagos se o projeto não for entregue dentro de determinado prazo.

Isso não significa que você vai acionar a multa em todo atraso. Significa que o fornecedor tem um incentivo real para cumprir o prazo, e que você tem um mecanismo de saída se a situação deteriorar.

Contratos sem essa cláusula colocam 100% do risco no lado do contratante. Você paga adiantado, o fornecedor atrasa, e você não tem instrumento para exigir nada além de uma promessa verbal de que "vai ficar pronto em breve".

5. Suporte e sustentação pós-entrega com SLA definido

Um sistema entregue sem suporte contratado é um sistema que vai gerar problema sem solução garantida. Bugs aparecem em produção. Integrações quebram quando o fornecedor de terceiros atualiza a API. Regras fiscais mudam e o sistema precisa acompanhar.

O contrato precisa especificar: por quanto tempo o fornecedor oferece suporte após o go-live, qual o prazo máximo de resposta para cada tipo de incidente (crítico, moderado, baixo), e se a sustentação contínua é um serviço adicional com contrato separado.

Uma referência de mercado: suporte pós-entrega com SLA de 24 horas para incidentes críticos e 72 horas para ajustes não urgentes é o mínimo aceitável para sistemas em produção. Qualquer coisa menos específica do que isso no contrato é margem para o fornecedor decidir quando e se vai responder.

O que fazer antes de assinar

Antes de assinar qualquer contrato de desenvolvimento de software, faça três perguntas diretas ao fornecedor:

Primeiro, peça para ver um contrato de um projeto anterior (com dados do cliente ocultados). Isso mostra se o nível de detalhe que você está exigindo é padrão para eles ou exceção.

Segundo, pergunte como funciona a sustentação depois da entrega e se existe equipe dedicada para isso. Fornecedor que some depois do go-live geralmente não tem resposta clara para essa pergunta.

Terceiro, pergunte quem vai ser o responsável técnico do projeto e se essa pessoa vai continuar disponível até o final. Projetos que travam costumam travar quando o desenvolvedor principal é redirecionado para outro cliente sem aviso.

A Wake Tecnologia tem 12 anos de mercado e mais de 100 projetos entregues. Parte do que garante essa consistência é exatamente o que está descrito aqui: contratos com escopo detalhado, marcos definidos, propriedade do código para o cliente e sustentação com SLA real após o go-live. Não é diferencial de marketing. É o padrão de quem não pode se dar ao luxo de abandonar um cliente e continuar no mercado por mais de uma década.

Conclusão

Você não precisa confiar cegamente em nenhum fornecedor de tecnologia. Precisa de um contrato que torne a confiança verificável.

As cinco cláusulas acima não são garantia absoluta de que tudo vai correr bem. Mas eliminam as brechas mais comuns que permitem ao fornecedor atrasar, entregar mal, manter o código refém e desaparecer sem consequência.

Se você está avaliando um fornecedor agora e quer saber se o que está sendo proposto faz sentido para a sua realidade antes de assinar qualquer coisa, fale diretamente pelo WhatsApp: (13) 99659-8656. Você descreve o projeto, o que já tentou antes e onde está o receio. A partir daí, a conversa é sobre o que um contrato sério precisa ter para que o seu próximo investimento em tecnologia chegue ao fim.