Contrato de Desenvolvimento de Software: O Que Verificar

Quase toda a gente compara propostas de software pelo preço e pelo prazo. São as duas linhas que saltam à vista. O contrato em si, as páginas com letra mais pequena, fica para depois, e muitas vezes é assinado sem grande leitura porque a reunião correu bem e a equipa pareceu séria. O problema aparece um ano mais tarde, quando quer mudar de fornecedor, trazer o desenvolvimento para dentro de casa, ou simplesmente pedir o código. É nesse momento que muitas empresas descobrem que o contrato nunca disse, a preto no branco, que o código era delas.

O contrato não é papelada. É o que decide quem fica dono do que construiu, o que acontece se o projeto atrasar, e se consegue sair sem ficar refém de quem o desenvolveu. Este guia percorre as cláusulas que interessam a uma PME portuguesa antes de assinar, sem juridiquês, para saber o que perguntar e o que exigir.

Porque é que o contrato importa mais do que o preço

Uma proposta barata com um contrato mau é a forma mais rápida de pagar duas vezes. O preço é o custo de construir. O contrato é o que protege esse investimento nos anos seguintes, quando o software já está a correr o negócio e trocar de mãos deixa de ser trivial. A dependência de um fornecedor não se sente no primeiro mês. Sente-se no dia em que precisa de mudar e percebe que não pode.

A boa notícia é que uma empresa séria não foge destas conversas. Pelo contrário, costuma trazer as respostas antes de as perguntar, porque cláusulas claras são sinal de uma relação saudável, não de desconfiança.

Quem fica dono do código

Esta é a cláusula que quase ninguém lê e quase toda a gente lamenta depois. Em Portugal, os programas de computador têm proteção própria (Decreto-Lei n.º 252/94), e a titularidade dos direitos não passa automaticamente para quem paga só porque pagou. Depende do que o contrato disser. Sem uma cláusula expressa de cessão de direitos, pode acabar com uma licença de uso em vez da propriedade, por vezes uma licença estreita e agarrada à continuidade do fornecedor.

Por isso não basta a proposta dizer "o software é seu". Precisa de ver, no contrato, uma cessão dos direitos de autor sobre o código feito à medida, a produzir efeitos com o pagamento, e a entrega do código-fonte, não apenas de uma versão compilada a correr num servidor deles. "Receber o software" e "receber o código-fonte" são coisas diferentes.

As cláusulas que não podem faltar

"É tudo seu" fica bem numa reunião comercial e não vale nada num contrato. A propriedade divide-se em partes, e um bom acordo é claro sobre cada uma:

• Código-fonte. Cessão dos direitos sobre o código à medida e entrega do repositório real, com documentação e instruções de instalação.
• Os seus dados. Os dados que o negócio e os utilizadores geram são seus, exportáveis num formato utilizável, e nunca podem ficar reféns.
• Componentes de terceiros e pré-existentes. Nenhum projeto é 100% original. Bibliotecas open-source trazem as suas próprias licenças, e qualquer framework interna que a empresa reutilize continua a ser dela. Um contrato justo dá-lhe uma licença perpétua e transmissível sobre essas peças, para que retirar o fornecedor nunca parta o produto.
• Marcas e conteúdos. Logótipo, textos e imagens que forneceu, ou que foram criados para si, ficam claramente do seu lado.

O ponto dos componentes pré-existentes confunde muita gente. É normal e correto uma empresa reutilizar as suas próprias ferramentas internas, e não deve esperar ficar dono delas. O que deve exigir é uma licença larga o suficiente para que a saída do fornecedor nunca deixe o software a meio-gás.

Pagamento por fases e o que conta como "entregue"

Pagar tudo à cabeça tira-lhe a única alavanca que tem. Pagar tudo no fim assusta qualquer fornecedor. O saudável fica no meio: pagamentos ligados a fases com entregáveis concretos, cada um com um critério de aceitação escrito. "A fase 2 está entregue quando o módulo de faturação emite faturas válidas e passa nos testes acordados" vale mais do que "quando estiver pronto".

Defina também o que é o âmbito e o que acontece quando ele muda. Pedidos novos a meio do projeto são normais; o que não pode é cada alteração virar uma discussão sobre se estava ou não incluída. Um processo simples de gestão de alterações evita metade dos conflitos. Se ainda está a estimar o investimento, veja quanto custa software à medida em Portugal.

Manutenção, garantia e o que acontece se correr mal

O software não acaba na entrega. O contrato deve dizer três coisas sobre o depois:

Primeiro, um período de garantia em que os defeitos que aparecem após a entrega são corrigidos sem custo, e por quanto tempo. Segundo, as condições de manutenção e evolução: preço, tempos de resposta e se fica ou não amarrado a um contrato mensal para poder mexer no que é seu. Terceiro, e o mais esquecido, uma cláusula de saída clara: como é feita a transição de código, credenciais, contas e conhecimento se a relação terminar. Uma saída definida vale mais do que qualquer promessa de que "não haverá problema".

Peça ainda que o repositório fique, desde o primeiro dia, numa conta sua (Git na sua organização, com a equipa deles como colaboradores), em vez de num sistema deles a que pede acesso mais tarde. Não custa nada no início e evita a discussão mais comum na altura da separação.

Código gerado por IA: uma nova zona cinzenta

Grande parte do código escrito em 2026 é produzido com assistentes de IA, e isso levanta questões que um contrato antigo não previa. Código puramente gerado por máquina, sem autoria humana relevante, pode nem ser protegido por direitos de autor em vários países, o que também significa que ninguém impede um concorrente de o copiar. Na prática, o que é entregue é uma mistura de trabalho humano e de IA, e a edição humana costuma bastar, mas as margens são genuinamente incertas.

O risco mais concreto é a proveniência: ferramentas de IA podem reproduzir excertos com licenças restritivas. Vale a pena uma cláusula em que o fornecedor garante que o código entregue não infringe, tanto quanto sabe, direitos de terceiros. Escrevemos mais sobre o custo escondido do código de IA mal gerido, e é um bom tema para levar à conversa.

Checklist antes de assinar

Não precisa de ser jurista para se proteger. Precisa de fazer estas perguntas e ter as respostas por escrito:

1. Com o pagamento final, os direitos sobre o código à medida são-me cedidos na totalidade?
2. Recebo o código-fonte e o repositório, com documentação e instruções de instalação? Posso alojar o repositório na minha conta desde o início?
3. Que componentes open-source ou pré-existentes estão envolvidos, e que licença tenho para os continuar a usar para sempre, mesmo sem vocês?
4. Os meus dados são meus e exportáveis num formato normal quando pedir?
5. O que acontece na saída: transição de código, contas e conhecimento?

Nenhuma destas perguntas é sinal de desconfiança. As melhores empresas respondem a tudo isto antes de perguntar. Se um fornecedor fica na defensiva quando toca no tema da propriedade, isso já é a resposta a outra pergunta. Para o resto dos critérios de escolha, veja como escolher uma empresa de software em Portugal e a nossa leitura das melhores empresas de software à medida.

O software é uma das poucas coisas que se pode pagar por inteiro e continuar a não ser dono. Umas frases no contrato são a diferença entre um produto que controla e um que aluga sem saber.