Cláusulas técnicas que o teu contrato de desenvolvimento deve incluir

O problema que ninguém vê até doer

Terminámos um projeto complexo. O cliente pagou. Todos satisfeitos.

Meio ano depois, o cliente decidiu passar a manutenção para outro fornecedor, e descobrimos que o contrato não dizia nada sobre quem controlava o repositório nem como se entregavam os acessos. O repositório estava na nossa conta, o cliente queria levá-lo com todo o direito e não havia um procedimento acordado. Uma cláusula de 2 linhas teria evitado uma discussão desnecessária.

Os contratos de desenvolvimento web costumam ser minutas genéricas de “prestação de serviços profissionais” que ignoram a natureza específica do software.

Estas são as 8 cláusulas técnicas que incluímos nos nossos contratos e que recomendamos a quem contrata desenvolvimento web, ou a quem o vende. Não substituem o aconselhamento jurídico, mas dizem-te o que tem de estar em cima da mesa antes de assinar.

1. Definição precisa do âmbito

O problema: “Desenvolver uma loja online” pode significar desde um WooCommerce básico até um marketplace com vários vendedores integrado com um ERP. A ambiguidade é a mãe do conflito.

A cláusula: remeter para um anexo técnico que detalhe as funcionalidades incluídas, as integrações concretas, o número de modelos de página, os fluxos de utilizador cobertos e, de forma explícita, o que fica fora do âmbito.

Exemplo: “O âmbito inclui: catálogo até 500 produtos com variações, pagamento com Stripe e PayPal, gestão de encomendas a partir do painel de administração e 5 páginas informativas. Fica fora do âmbito: integração com ERP externo, subscrições recorrentes e aplicação móvel nativa”.

Alterações durante o projeto: define o que acontece quando o cliente pede algo fora do âmbito. O sensato é um procedimento simples: pedido por escrito, avaliação de custo e prazo, e aprovação antes de executar.

2. Propriedade intelectual e licenças

O problema: quem é o dono do código? O que acontece com as bibliotecas próprias da agência?

A cláusula: em Espanha os direitos morais de autor não se podem transmitir, por isso o que se acorda é a cessão dos direitos de exploração (reprodução, distribuição, transformação e comunicação pública) sobre o código desenvolvido para o projeto. Indica se a cessão é exclusiva, o seu âmbito territorial e a sua duração, porque a lei é restritiva quando o contrato é omisso: se não se fixar um prazo, a cessão fica limitada a 5 anos.

E deixa fora da cessão as bibliotecas de terceiros, com as suas próprias licenças, o código próprio que a agência reutiliza (licencia-se, não se transmite) e o seu know-how.

Licenças de terceiros: quem paga os plugins premium, as tipografias ou as fotografias de banco de imagens, e em nome de quem são contratados.

3. Entregáveis e aceitação

O problema: “quando estiver pronto” não é uma data. Também não o é “quando o cliente estiver satisfeito”, que equivale a um âmbito infinito.

A cláusula: define os entregáveis (código-fonte num repositório, documentação de implementação, manual de utilizador se for o caso) e os critérios de aceitação: funcionalidades operacionais no ambiente de testes e um período de revisão. Por exemplo, 5 dias úteis para enviar observações; se não houver resposta, o entregável considera-se aceite.

Revisões e alterações: quantas rondas de revisão o preço inclui e o que é um “ajuste” face a uma “alteração”. Um botão de outra cor é um ajuste; acrescentar um campo ao formulário de pagamento é uma alteração.

4. Alojamento, acessos e dados

O problema: quem paga o alojamento, quem tem acesso de administrador e o que acontece aos dados se a relação terminar?

A cláusula: especifica o modelo de alojamento (gerido pela agência, pelo cliente ou partilhado), quem o configura e o paga, e quem acede ao painel, ao FTP, à base de dados e ao DNS. O recomendável é que o domínio e a conta de alojamento estejam sempre em nome do cliente.

Propriedade dos dados: os dados que o cliente introduz (conteúdos, produtos, utilizadores) são dele. A agência pode guardar cópias durante o projeto, mas não retê-las indefinidamente após a entrega.

Saída ordenada: se o cliente quiser sair, o contrato deve fixar o processo: entrega de cópias completas, transferência dos acessos e do repositório, e um período de apoio à transição (por exemplo, 30 dias, incluído ou faturado à parte). Os passos práticos estão no nosso guia para mudar de fornecedor web sem perder tudo.

5. Manutenção e garantia

O problema: quanto tempo dura a garantia e onde acaba um erro e começa uma funcionalidade nova?

A cláusula: um período de garantia, habitualmente de 30 a 90 dias desde o lançamento, durante o qual os erros são corrigidos sem custo. Define o que é um erro: uma funcionalidade que não funciona segundo a especificação acordada. E exclui as alterações de requisitos, os problemas causados por modificações do cliente e as falhas de software de terceiros.

Manutenção: a corretiva (reparar o que se avaria) pode estar incluída ou ser contratada à parte; a evolutiva (acrescentar funcionalidades) é sempre desenvolvimento novo, com o seu próprio orçamento. Se houver manutenção ativa, fixa tempos de resposta por gravidade. Por exemplo: site em baixo em 4 horas, incidência grave em 24 horas e menor em 3 dias úteis.

6. Confidencialidade e proteção de dados (RGPD)

O problema: a agência acede a dados dos clientes do seu cliente. Pode usá-los para algo mais do que o projeto? Quem responde se houver uma violação de segurança?

A cláusula: a informação do cliente não é partilhada com terceiros nem usada fora do projeto, e citá-lo como referência ou caso de estudo exige a sua autorização por escrito.

Proteção de dados: se a agência tratar dados pessoais por conta do cliente (por exemplo, ao manter um site com registo de utilizadores ou com acesso às encomendas), o RGPD exige um contrato de subcontratação do tratamento (artigo 28.º). Nele, o cliente figura como responsável pelo tratamento e a agência como subcontratante, e fixam-se as medidas de segurança, as condições para recorrer a outros subcontratantes e o que se faz com os dados no final. Mais detalhes em onde ficam realmente guardados os dados dos teus clientes.

7. Limitação de responsabilidade

O problema: até onde responde a agência se o cliente perder vendas porque o site esteve em baixo?

A cláusula: o habitual é um teto igual ao valor total do contrato, excluindo danos indiretos e lucros cessantes. Essa limitação nunca pode cobrir o dolo (o Código Civil não o permite) e o razoável é que também não se aplique à culpa grave. Se o cliente for um consumidor, estas limitações têm pouco alcance: a legislação de defesa do consumidor considera abusivas as que restringem os seus direitos. A agência também não garante 100% de disponibilidade nem responde pelo que não controla: quebras do alojamento de terceiros, ataques DDoS ou falhas de APIs externas.

O risco de proteção de dados costuma ser acordado à parte, porque as coimas e reclamações nessa matéria podem ultrapassar em muito o valor do contrato.

8. Resolução de conflitos

A cláusula: uma escada de resolução para não acabar diretamente num processo judicial longo e caro. Primeiro, negociação direta durante um prazo fixo; depois, mediação; e só se isso não funcionar, arbitragem ou tribunais. Indica também a lei aplicável e os tribunais competentes (por exemplo, lei espanhola e tribunais de Pontevedra), tendo em conta que, se o cliente for um consumidor, estas cláusulas têm limites legais.

Checklist de revisão do contrato

Antes de assinar, verifica:

• Âmbito definido com precisão, com exclusões explícitas e um procedimento para as alterações.
• Propriedade intelectual clara: que direitos são cedidos e que licenças de terceiros são usadas.
• Entregáveis especificados e critérios de aceitação objetivos.
• Modelo de alojamento, acessos e propriedade dos dados definidos.
• Garantia: período, o que cobre e o que não cobre.
• Manutenção após o lançamento, com SLA se for o caso.
• Confidencialidade e contrato de subcontratação do tratamento de dados.
• Limitação de responsabilidade razoável.
• Resolução de conflitos e saída ordenada.

Se ainda estás a escolher fornecedor, completa esta lista com as 5 perguntas que deves fazer antes de contratar qualquer desenvolvimento web.

Perguntas frequentes

Preciso de um advogado para isto?

Para contratos de valor significativo ou com dados sensíveis, sim. Um advogado com experiência em tecnologia vai adaptar estas cláusulas ao teu caso. Para projetos pequenos, usa estas orientações como checklist para rever a minuta que te propuserem.

E se o cliente não quiser assinar um contrato formal?

É um sinal de alarme: não comeces a trabalhar. Um contrato não é desconfiança, é clareza, e se alguém foge do papel, o problema não é o papel.

Quanto tempo deve durar a garantia?

Entre 30 e 90 dias. Desconfia da “garantia vitalícia”: o software não é uma cadeira, depende de um ambiente que muda constantemente, e o que se avaria por causa dessas mudanças é manutenção, não um erro de desenvolvimento.

Conclusão

Um contrato de desenvolvimento não serve para discutir depois. Serve para não ter de discutir.

A maioria dos conflitos não vem da má-fé, mas de pressupostos diferentes: “Achava que o alojamento estava incluído”. “Pensava que as alterações de última hora não custavam mais”. “Não sabia que o código não era meu”.

Quase todas essas discussões se evitam com umas poucas páginas bem escritas antes de começar. Não é preciso um advogado para cada contrato, mas é preciso saber o que perguntar.

Na Baqueiro revemos a parte técnica dos contratos de desenvolvimento sabendo o que acontece depois no código e no servidor. Se estás prestes a assinar um ou queres atualizar o teu contrato-tipo, falemos das tuas cláusulas técnicas.