Contratos de Desenvolvimento de Software: O Que Verificar Antes de Assinar

A maioria dos contratos de desenvolvimento de software é assinada num estado de otimismo. Ambas as partes estão entusiasmadas com o projeto, a relação é calorosa e o futuro parece simples. Ninguém lê atentamente a cláusula de resolução de litígios quando acredita que nunca haverá um litígio. Ninguém analisa minuciosamente a cessão de propriedade intelectual quando parte do princípio de que a agência vai fazer o que é correto.

O problema é que os contratos não são redigidos para os bons momentos. São o único documento que regula o que acontece quando as coisas correm mal — quando o âmbito cresce descontroladamente, quando a agência não cumpre os prazos, quando é necessário terminar o contrato, quando se descobre que o código foi construído com base numa biblioteca com uma licença incompatível. Quando precisa do contrato, já se encontra numa situação difícil. Se não o leu devidamente antes de assinar, está prestes a descobrir exatamente quanto poder de negociação não tem.

Temos clientes que perderam propriedade intelectual que pensavam ser sua, que não conseguiram terminar um contrato que estava a falhar sem pagar dezenas de milhares em taxas de aviso prévio, e que descobriram a meio do projeto que os acordos de confidencialidade que assinaram não cobriam, na realidade, o seu conceito de negócio. Todos eles teriam detetado o problema se soubessem o que procurar antes de assinar.

Este guia abrange as cláusulas que importam, as que são frequentemente ignoradas e as disposições que deve recusar aceitar. É escrito para fundadores, gestores de produto e responsáveis de aquisição — não para advogados — e destina-se a dar-lhe fluência suficiente para rever um contrato de forma inteligente, mesmo que recorra a um solicitador para a verificação final.

---

Propriedade Intelectual

Esta é a cláusula mais importante em qualquer contrato de desenvolvimento de software, e é a que é mais frequentemente mal compreendida.

O padrão que deve esperar é a cessão total dos direitos de propriedade intelectual mediante o pagamento integral. Isso significa que, quando tiver pago, o código, a documentação, os ativos de design e quaisquer obras derivadas pertencem-lhe absolutamente. Não à agência. Não ao abrigo de uma licença. A si.

O que essa cláusula deve dizer, em termos simples: a agência cede-lhe irrevogavelmente todos os direitos de propriedade intelectual sobre os entregáveis, incluindo direitos de autor, após a receção do pagamento final. Não deve haver exceções, direitos retidos nem linguagem de licença disfarçada de propriedade.

O que deve verificar:

• Linguagem de "licença de utilização" em vez de cessão. Se o contrato disser que a agência "lhe concede uma licença" para utilizar o software, não é seu proprietário. Está a arrendá-lo. A agência retém a propriedade e pode, em teoria, revogar ou alterar os termos. Esta redação é por vezes disfarçada para parecer propriedade. Leia cada palavra.
• Direitos retidos de "PI pré-existente." As agências retêm legitimamente a propriedade de ferramentas, frameworks, bibliotecas e modelos base que trazem para um projeto. Isso é justo. O que não é aceitável é que a PI pré-existente seja tão amplamente definida que englobe a funcionalidade principal do que encomendou. Peça-lhes que listem especificamente qual a PI pré-existente que está a ser retida e garanta que tem uma licença irrevogável e isenta de royalties para a utilizar no seu produto.
• Cessão de PI condicional. Alguns contratos incluem cláusulas em que a PI "reverte" para a agência se falhar um pagamento ou violar um termo. Abordamos isto na secção de sinais de alerta. Nunca aceite.
• Work-made-for-hire vs. cessão. Em algumas jurisdições, o software criado por um prestador de serviços não se qualifica automaticamente como "work made for hire." Uma cláusula de cessão clara contorna completamente esta ambiguidade. Certifique-se de que o contrato utiliza linguagem de cessão explícita independentemente da jurisdição.

Peça à agência que confirme por escrito, antes de assinar, que será proprietário da PI após o pagamento. Qualquer hesitação é um sinal que vale a pena investigar.

---

Âmbito do Trabalho

Um âmbito de trabalho vago é uma fuga orçamental à espera de acontecer. O Âmbito de Trabalho (SOW) é o documento que define exatamente o que a agência está a construir para si, e se for impreciso, cada desacordo sobre o que está "incluído" será resolvido na direção de custo adicional.

O que um SOW bem definido inclui:

• Uma lista específica de funcionalidades, não uma descrição geral do produto
• Critérios de aceitação para cada entregável — como saberão ambos quando algo está concluído?
• Decisões sobre plataforma e stack tecnológica
• Integrações de terceiros com sistemas identificados
• Expectativas de desempenho quando relevante (tempos de carregamento de página, limites de utilizadores simultâneos)
• O que está explicitamente fora do âmbito

O processo de pedido de alteração é tão importante quanto o próprio SOW. Nenhum projeto sobrevive ao contacto com a realidade sem alterações. A questão é se as alterações são tratadas de forma transparente ou utilizadas como mecanismo para extrair receita adicional sem o seu pleno conhecimento. Um bom contrato especifica um processo formal de pedido de alteração: o cliente submete um pedido de alteração por escrito, a agência fornece uma avaliação de impacto escrita cobrindo tempo e custo, e o trabalho na alteração só começa após a sua aprovação por escrito.

Desconfie de qualquer contrato que não defina como as alterações são tratadas. "Acomodaremos alterações razoáveis sem custo adicional" não é um processo — é uma promessa vaga que se desvanece no momento em que você e a agência discordam sobre o que significa "razoável".

O SOW deve ser um anexo ao contrato, não estar incorporado num e-mail de vendas. Se estiver apenas numa cadeia de e-mails, formalize-o antes de assinar o contrato principal.

---

Condições de Pagamento

A estrutura de pagamento é onde se definem as dinâmicas de poder de um projeto. Como paga, e quando, determina quanto poder de negociação retém ao longo do contrato.

As três estruturas principais:

• Baseada em marcos. Pagamento vinculado a entregáveis definidos. Paga quando algo específico é concluído e aceite. Este é o modelo mais favorável ao cliente para projetos de preço fixo, porque o seu dinheiro está sempre associado a valor recebido.
• Tempo e materiais. Paga pelas horas trabalhadas, normalmente semanalmente ou mensalmente em atraso. Este é o padrão para retainers contínuos e desenvolvimento iterativo. O risco é o custo ilimitado se o âmbito não for gerido rigorosamente.
• Entregável com pagamento antecipado. Paga um preço fixo por um resultado definido. Isto é razoável para pequenos trabalhos bem delimitados.

As regras que recomendamos:

Nunca pague mais de 30–40% do valor total do contrato antecipadamente. Um depósito inicial de 20–30% é padrão e razoável — cobre o custo de onboarding da agência e dá-lhes confiança de que é sério. Qualquer coisa acima de 40% antecipado inclina o poder de negociação a favor deles. Se um projeto falhar ou não for entregue, recuperar um pagamento antecipado de 60% através de ação judicial é caro, lento e incerto.

Os pagamentos por marcos devem estar vinculados à aceitação, não à passagem do tempo. "Vamos faturar na última sexta-feira de cada mês" não é faturação por marcos — é faturação baseada no tempo rotulada como marcos. Os critérios de aceitação no SOW tornam-se a condição para o pagamento.

As cláusulas de retenção valem a pena solicitar em contratos maiores. Uma retenção de 5–10% do pagamento final, mantida durante 30–60 dias após o lançamento, incentiva a agência a corrigir prontamente os erros pós-lançamento. Nem todas as agências concordarão com isto, mas vale a pena negociar.

---

Confidencialidade e NDA

A maioria dos contratos de desenvolvimento de software inclui uma cláusula de confidencialidade. A questão é se abrange o que realmente precisa de proteger.

O que deve ser coberto: o seu conceito de negócio, os seus dados, a sua arquitetura técnica, quaisquer segredos comerciais que divulgue durante a fase de descoberta, os dados dos seus clientes e a própria existência do contrato, se isso for comercialmente sensível.

NDA mútuo vs. unilateral: Na maioria dos casos, um NDA mútuo é adequado. A agência pode partilhar informações sobre os seus métodos, estruturas de preços ou ferramentas consigo durante o contrato — um NDA unilateral que apenas o protege a si pode criar fricção. Os NDAs mútuos são padrão e não devem ser um ponto de discórdia.

Duração: As obrigações de confidencialidade devem sobreviver ao contrato. Uma cláusula que diz que a confidencialidade se aplica "durante a vigência deste acordo" não o protege após o término do contrato. O padrão é de dois a cinco anos após a rescisão para informações confidenciais gerais, sem limite de tempo para segredos comerciais.

Subcontratados: Se a agência utilizar subcontratados ou programadores offshore no seu projeto, certifique-se de que a cláusula de confidencialidade exige explicitamente que a agência vincule essas partes a obrigações equivalentes. Uma cláusula de confidencialidade que apenas cobre os funcionários da própria agência é uma lacuna.

---

Garantias e Responsabilidade

Os contratos de desenvolvimento de software contêm frequentemente garantias que parecem abrangentes mas oferecem pouca proteção prática, e cláusulas de responsabilidade que estão completamente ausentes ou fortemente desfavoráveis ao cliente.

Como deve ser uma garantia de software: Uma disposição de garantia razoável compromete a agência a corrigir defeitos no software que sejam reportados dentro de um período definido após o lançamento — normalmente 30 a 90 dias. Deve cobrir defeitos que façam o software falhar materialmente no desempenho conforme especificado no SOW. Não deve exigir que prove que o erro existia no lançamento, apenas que existe dentro do período de garantia.

O que uma garantia não é: Nenhuma agência credível vai ou deve garantir que o software não contém erros. O software é complexo. O que podem razoavelmente garantir é que corrigirão erros no período especificado sem custo adicional. Desconfie de garantias abrangentes que prometem perfeição — são inexequíveis ou serão usadas para argumentar que cada problema está fora do âmbito.

Limites de responsabilidade: A maioria dos contratos inclui um limite na responsabilidade total da agência, normalmente igual às taxas pagas ao abrigo do contrato. Isto é padrão e amplamente aceitável. O que não é aceitável é um limite de responsabilidade de um valor nominal (digamos, 500 € ou 1.000 €) num contrato de 50.000 €, ou um limite combinado com uma exclusão geral de perdas consequenciais que o impediria de recuperar uma compensação significativa por uma entrega falhada.

Indemnização: O contrato deve incluir uma cláusula de indemnização mútua cobrindo reclamações de terceiros sobre propriedade intelectual. Especificamente, a agência deve indemnizá-lo se o software que entregam infringir os direitos de PI de terceiros. Deve também verificar se está a indemnizar a agência por qualquer PI que forneça — isto é razoável, mas certifique-se de que o âmbito está limitado aos ativos que realmente contribui.

---

Rescisão

O seu direito de sair de um contrato que não está a funcionar é uma das proteções mais importantes em qualquer contrato de serviços, e é uma que os clientes frequentemente não negociam antes de assinar.

Direito de rescisão por conveniência: Deve ter o direito de rescindir o contrato sem causa, com aviso prévio razoável. Normalmente 30 dias é o padrão. Alguns contratos incluem apenas rescisão por justa causa — o que significa que só pode sair se a agência tiver violado materialmente o contrato. Isto deixa-o preso numa relação que está a falhar, a menos que consiga provar a violação, o que é muitas vezes difícil e moroso de estabelecer.

O que recebe na rescisão: O contrato deve indicar claramente que na rescisão recebe: todo o código desenvolvido até à data, em estado entregável; toda a documentação; credenciais de acesso para quaisquer ambientes, repositórios ou serviços configurados em seu nome; e um plano de transição claro. Uma agência que retém o código até que um litígio seja resolvido tem um poder de negociação significativo sobre si. Não aceite isto.

Períodos de aviso prévio e pagamento na rescisão: Se rescindir por conveniência, deve esperar pagar pelo trabalho concluído até à data de rescisão. O que não deve aceitar é a obrigação de pagar por trabalho ainda não iniciado, ou uma "taxa de cancelamento" que equivale a uma percentagem significativa do valor restante do contrato. Alguns contratos incluem danos liquidados na rescisão — reveja-os cuidadosamente.

Rescisão por justa causa: Deve também ter o direito de rescindir imediatamente, sem aviso prévio, se a agência cometer uma violação material que não seja corrigida dentro de um período de cura razoável (normalmente 14–21 dias após notificação por escrito).

---

Resolução de Litígios

Os litígios em desenvolvimento de software são comuns — sobre âmbito, qualidade, prazos, pagamento e PI. Como um litígio é resolvido, onde é resolvido e a que custo pode ser tão importante quanto o resultado.

Jurisdição: Para contratos domésticos, certifique-se de que a lei aplicável e a jurisdição são a sua jurisdição local. Para contratos internacionais, este é um ponto de negociação material. Uma agência baseada na Europa de Leste ou no Sul da Ásia pode propor a sua jurisdição local. A implicação prática é que, se precisar de executar uma sentença, terá de o fazer no país deles — o que pode ser caro, lento ou efetivamente impossível.

Processo de escalada: Os bons contratos incluem um processo de escalada faseado: discussão informal entre líderes de projeto, depois escalada para gestão sénior, depois mediação formal, depois arbitragem ou litígio. Isto é sensato e rentável — a maioria dos litígios pode ser resolvida sem procedimentos formais se houver um processo estruturado.

Arbitragem vs. litígio: A arbitragem é geralmente mais rápida, menos dispendiosa e mais privada do que o litígio. Para litígios abaixo de um determinado limiar (frequentemente entre 50.000 € e 100.000 €), o custo da arbitragem é proporcional. Certifique-se de que qualquer cláusula de arbitragem especifica um organismo arbitral reconhecido e uma sede de arbitragem na sua jurisdição.

Nota internacional: Se estiver a contratar com uma agência fora da sua jurisdição, considere exigir que o contrato seja regido pela lei de Inglaterra e País de Gales ou outra jurisdição de common law internacionalmente neutra. Isto dá-lhe acesso a um direito comercial bem desenvolvido e a um regime de execução previsível.

---

Acordo de Processamento de Dados (RGPD)

Se o software a desenvolver irá processar dados pessoais — dos seus clientes, dos seus colaboradores ou de quaisquer pessoas singulares no EEE ou no Reino Unido — é legalmente obrigado a ter um Acordo de Processamento de Dados (APD) estabelecido com qualquer parte que processe esses dados em seu nome.

Isto não é opcional. É um requisito ao abrigo do RGPD do Reino Unido e do RGPD da UE, e a ausência de um APD expõe-o a risco regulatório caso ocorra uma violação de dados ou uma auditoria de uma autoridade supervisora.

Quem é quem: Em quase todas as relações de desenvolvimento de software, é o responsável pelo tratamento de dados — determina a finalidade e os meios de tratamento. A agência é o subcontratante — trata os dados de acordo com as suas instruções. O APD deve refletir isto claramente.

O que o APD deve abranger:

• As categorias de dados pessoais a tratar e as finalidades do tratamento
• As obrigações da agência de tratar os dados apenas de acordo com as suas instruções documentadas
• Medidas de segurança técnicas e organizacionais adequadas
• Restrições ao subtratamento (a agência não pode transmitir os seus dados a terceiros sem a sua autorização)
• Assistência com pedidos de titulares de dados e notificação de violações
• Eliminação ou devolução de dados pessoais no final do contrato
• Direitos de auditoria

Se uma agência recusar assinar um APD ou afirmar que é desnecessário para um contrato de desenvolvimento, trate-o como um sério sinal de alerta. Mesmo num contexto de desenvolvimento, os dados pessoais são frequentemente carregados em ambientes de teste — e esses dados precisam de ser protegidos.

---

Cláusulas de Alerta a Rejeitar

Alguns termos contratuais não são apenas desfavoráveis — são disposições que clientes experientes aprendem a identificar e recusar. São as cláusulas que parecem inócuas durante a fase otimista da assinatura e tornam-se prejudiciais quando as coisas correm mal.

PI que reverte por pagamento em falta. Qualquer cláusula que transfira a propriedade da PI de volta para a agência se falhar um pagamento, mesmo que temporariamente, dá à agência uma opção nuclear sobre o seu produto. Um litígio de pagamento — que pode acontecer por razões legítimas — deve ser resolvido através de mecanismos de recuperação de pagamento, não através da recuperação da PI de algo pelo qual já pagou em grande parte.

Responsabilidade ilimitada do cliente. Alguns contratos incluem cláusulas em que o cliente indemniza a agência amplamente por quaisquer perdas decorrentes do projeto. Isto pode incluir perdas causadas pelos próprios erros da agência. Nenhum cliente deve aceitar responsabilidade ilimitada ou indemnizações que se estendam além dos ativos e informações que contribui diretamente.

Sem direito de rescisão sem justa causa. Se não conseguir sair do contrato sem provar que a agência o violou, assinou a sua capacidade de responder a um contrato que está a falhar sem entrar em litígio judicial. Insista sempre num direito de rescisão por conveniência.

Sem acesso ao ambiente de staging. Este é um sinal de alerta prático em vez de jurídico. Se o contrato não garante o acesso a um ambiente de staging ao longo do desenvolvimento, não tem visibilidade independente do que está a ser construído até que a agência decida mostrar-lho. Insista no acesso contínuo.

Renovação automática com longos períodos de aviso prévio. Os contratos de retainer que se renovam automaticamente por períodos de 12 meses com janelas de cancelamento de 90 dias são concebidos para prender os clientes em acordos dos quais querem sair. Um aviso prévio de 30 dias num retainer mensal é o padrão.

Cláusulas de não aliciamento abrangentes. Muitas agências incluem cláusulas que o impedem de contratar os seus programadores durante um período após o contrato. Uma cláusula de não aliciamento restrita cobrindo os programadores diretamente afetos ao seu projeto por 12 meses é razoável. Uma cláusula abrangente cobrindo todos os colaboradores da agência por 24 meses é uma tentativa de proteger a sua reserva de mão de obra à sua custa.

---

Como os Nossos Contratos Estão Estruturados na Cyberbeak

Não somos neutros neste tema — somos uma agência de desenvolvimento de software e temos uma opinião sobre como os contratos devem funcionar. Achamos que vale a pena ser transparentes sobre a forma como abordamos os nossos.

Os nossos acordos padrão incluem cessão total de PI ao cliente após a receção do pagamento final. Não existem direitos retidos além das bibliotecas e ferramentas pré-existentes padrão, que são listadas e cobertas por uma licença irrevogável. Utilizamos estruturas de pagamento por marcos para projetos de preço fixo, com marcos vinculados a critérios de aceitação acordados no SOW. Não pedimos mais de 30% antecipadamente.

Todos os contratos com processamento de dados pessoais incluem um APD por padrão. A confidencialidade é mútua. O nosso limite de responsabilidade está definido nas taxas pagas ao abrigo do contrato, com exclusões padrão para fraude e conduta dolosa. Os clientes têm um direito de rescisão por conveniência de 30 dias. Na rescisão, todo o código, documentação e credenciais são transferidos no prazo de cinco dias úteis.

Incluímos uma garantia de correção de defeitos de 60 dias após o lançamento em todos os projetos de preço fixo.

Acreditamos que estes termos são justos para ambas as partes e estamos à vontade com que os clientes os submetam à revisão de um solicitador. Se uma agência potencial recusar qualquer uma destas disposições, vale a pena perguntar porquê.

---

Perguntas Frequentes

Preciso de um solicitador para rever um contrato de desenvolvimento de software?

Para qualquer contrato acima de 15.000–20.000 €, recomendamos vivamente. Um solicitador comercial com experiência em contratos de tecnologia pode rever um contrato padrão de desenvolvimento de software em uma a duas horas. O custo é normalmente de 300–600 €. Dado o que está em jogo — a sua PI, a sua capacidade de sair, as suas obrigações de dados — é um dos investimentos com maior retorno que pode fazer. Para contratos mais pequenos, ler este guia e aplicá-lo por si próprio pode ser suficiente, mas a revisão profissional nunca é desperdiçada.

E se a agência não quiser negociar os termos do contrato?

A maioria das agências de boa reputação negociará em pontos materiais. Se uma agência recusar discutir cessão de PI, responsabilidade ou direitos de rescisão, isso diz-lhe algo importante sobre a forma como aborda as relações com os clientes em geral. A resistência estilística menor é normal — a recusa total em negociar proteções substantivas é um sinal de alerta. Se genuinamente tiverem um formulário padrão não negociável, peça-lhes que expliquem por escrito cada cláusula sobre a qual tem dúvidas. As suas explicações dir-lhe-ão muito.

E quanto a acordos verbais e discussões por e-mail?

Os acordos verbais são juridicamente vinculativos na maioria das jurisdições, mas são extremamente difíceis de executar porque não existe um registo claro do que foi acordado. As discussões por e-mail têm mais peso e podem constituir um acordo vinculativo em algumas circunstâncias, mas criam ambiguidade sobre o âmbito e os termos. A única posição segura é garantir que todos os termos materiais — âmbito, pagamento, PI, rescisão — estejam capturados num acordo escrito e assinado antes do início do trabalho. Se uma agência iniciar trabalho com base num sinal verbal e as coisas correrem mal, pode ter recursos muito limitados.

Posso utilizar um contrato modelo padrão em vez dos termos da agência?

Sim, e em muitos casos é preferível. Se encomenda software regularmente, ter os seus próprios termos padrão redigidos por um solicitador uma vez e utilizados consistentemente em todos os contratos dá-lhe uma base conhecida. A agência pode solicitar alterações, e isso é uma negociação — mas começar com o seu próprio modelo significa começar com termos estruturados a seu favor. Os modelos também estão disponíveis em organizações como a TechUK e a Law Society, embora devam ser revistos por um solicitador para garantir que refletem as suas circunstâncias específicas.

---

Acertar no contrato não é uma questão de desconfiança. Trata-se de garantir que ambas as partes têm a mesma compreensão do que acordaram, e que existe um processo claro e justo para lidar com as coisas que inevitavelmente correm de forma diferente do planeado.

Se está a avaliar um contrato de desenvolvimento de software e gostaria de perceber como os nossos acordos estão estruturados, ou se tem questões sobre o que termos contratuais específicos significam na prática, teremos todo o gosto em ter essa conversa. Entre em contacto connosco — sem obrigações, sem discurso de vendas, apenas uma discussão direta sobre o que são termos justos.