Download Word gratuito • Edite on-line • Salve e compartilhe com Drive • Exporte para PDF
Um Acordo de Cliente e Desenvolvedor é um contrato vinculativo que define os termos entre uma empresa e um fornecedor de serviços de programação e desenvolvimento de sistemas. Este modelo estrutura responsabilidades, prazos, pagamento, propriedade intelectual, confidencialidade e aceitação de trabalho em projetos de software. Disponível como download Word gratuito, é totalmente editável e pode ser exportado em PDF. O documento inclui seções de definições detalhadas, cláusulas sobre direitos de propriedade intelectual pré-existente, proteção de informações sensíveis, e suporte para dois modelos de pagamento: preço fixo por projeto e tempo & materiais por hora.
Contratar um desenvolvedor ou agência sem um acordo claro é arriscado. Sem documentação formal, você pode enfrentar disputas sobre propriedade de código, qualidade de entrega, prazos, confidencialidade de dados e reutilização indevida de seu trabalho. Este contrato protege você ao deixar explícito quem é dono do software gerado, qual informação é confidencial, quando o trabalho é considerado aceito, e como mudanças de escopo afetam o cronograma e o pagamento. Se o desenvolvedor falir ou não entregar, você tem um documento legal que justifica ações de cobrança. Além disso, em equipes multidisciplinares com sub-desenvolvedores, este acordo garante que todos os terceiros envolvidos respeitam os mesmos padrões de qualidade, sigilo e responsabilidade que você acordou com o desenvolvedor principal.
| Se sua situação é… | Use este modelo |
|---|---|
| Quando contrata agência de desenvolvimento para projeto completo ou contínuo | Acordo com desenvolvedor externo (agência) |
| Para contratar um programador independente com menor volume de trabalho | Acordo com freelancer programador |
| Quando o desenvolvedor principal precisa delegar parte do trabalho a terceiros | Acordo com sub-desenvolvedores |
| Quando há escopo bem definido e pagamento não é por horas trabalhadas | Acordo de projeto preço fixo |
| Para projetos com escopo aberto ou sujeitos a mudanças ao longo da execução | Acordo de projeto tempo e materiais |
| Para definir serviços contínuos de correção e aprimoramento de software existente | Acordo de manutenção e suporte |
Por que importa: O contrato pode ser considerado inválido ou ambíguo se dados essenciais (nomes, datas, valores) estão faltando.
Fix: Faça uma passagem final antes de assinar, substituindo todos os [PLACEHOLDERS] com informações reais e específicas.
Por que importa: Sem um ponto de contato definido, decisões técnicas ficam lentas, mudanças não são documentadas e responsabilidades se tornam vagas.
Fix: Sempre nomear uma pessoa específica no cliente para supervisionar o trabalho e incluir seu nome e contato no SOW.
Por que importa: O desenvolvedor pode transferir trabalho para terceiros sem qualidade ou confidencialidade adequadas, expondo dados sensíveis.
Fix: Exigir aprovação escrita do cliente antes de qualquer sub-contratação e fazer o sub-desenvolvedor assinar NDA separada.
Por que importa: Pode haver disputa se o cliente acredita que é dono de todo o código, mas o desenvolvedor reclama direitos sobre frameworks ou bibliotecas que criou.
Fix: Listar explicitamente no Anexo do contrato quais componentes são pré-existentes (desenvolvedor retém direitos) e quais são criados sob medida (cliente retém direitos).
Por que importa: Sem proteção clara, o desenvolvedor pode usar algoritmos, estruturas de dados ou segredos comerciais do cliente para clientes concorrentes.
Fix: Detalhar no Anexo B ou seção de confidencialidade exatamente o que é informação sensível e por quanto tempo a restrição se aplica (ex: 2 anos após término).
Por que importa: Pode haver disputa sobre se uma mudança de escopo justifica aumento de fatura ou se deve ser cobrada como tempo adicional.
Fix: Cada projeto deve ter um SOW separado especificando exclusivamente um modelo: ou preço fixo, ou T&M com taxa horária e limite de horas.
Em linguagem simples: Identifica o cliente, o desenvolvedor, suas sedes e a data em que o acordo entra em efeito.
Este acordo entre cliente e desenvolvedor (o "Acordo") é efetivo [DATA], ENTRE: [NOME DA EMPRESA] (o "cliente"), com matriz em [SEU ENDEREÇO], E: [FORNECEDOR] (o "Desenvolvedor"), com matriz em [SEU ENDEREÇO].
Erro comum: Deixar espaços em branco com [PLACEHOLDERS] sem preencher, o que invalida o acordo.
Em linguagem simples: Estabelece as premissas de que o desenvolvedor atua em programação, o cliente quer contratar esses serviços e ambos desejam termos padrão.
CONSIDERANDO QUE o fornecedor atue na área de programação e análise de sistemas; CONSIDERANDO QUE o cliente deseje fazer uso dos serviços; e CONSIDERANDO QUE as partes desejam estabelecer termos e condições padrão aplicáveis aos serviços.
Erro comum: Alterar ou omitir os considerandos sem revisão jurídica, o que pode afetar a interpretação do contrato.
Em linguagem simples: Define quem é o desenvolvedor, incluindo seus funcionários, diretores, subsidiárias, afiliadas, sucessores e cessionários.
O termo "Desenvolvedor" significa [NOME DO PRESTADOR], bem como seus funcionários, diretores, subsidiários, afiliados, sucessores e cessionários, atualmente existentes e criados no futuro.
Erro comum: Não especificar se subsidiárias ou afiliadas estão incluídas, causando dúvidas sobre responsabilidade.
Em linguagem simples: Clarifica que o desenvolvedor retém direitos sobre IP que era seu antes do contrato ou criou independentemente fora do projeto.
O "Desenvolvedor de IP pré-existente" compreende patentes, direitos autorais e segredos comerciais de propriedade do Desenvolvedor que (A) pré-datam a Declaração de Trabalho, ou (B) surgem exclusivamente de desenvolvimento independente.
Erro comum: Não definir o que é pré-existente, levando a disputas sobre quem é dono do código reutilizável.
Em linguagem simples: Define que toda documentação gerada (código, manuais, especificações) durante o trabalho é considerada parte do contrato.
"Documentação" significa todo material gerado, por escrito ou em mídia eletrônica, por programadores no desempenho do trabalho, incluindo código-fonte, design, fluxogramas, especificações técnicas, manuais e materiais de apoio.
Erro comum: Não clarificar se documentação técnica é entregável, resultando em código sem manual ou sem comentários.
Em linguagem simples: Estabelece que cada projeto deve ter um SOW escrito, mutual e aceitável, especificando escopo, entregáveis e padrões.
"Declaração de Trabalho (SOW)" significa um documento escrito mutuamente aceitável que especifica o escopo do projeto, entregáveis, normas de desempenho e está geralmente na forma do Anexo A.
Erro comum: Começar trabalho sem SOW formal, deixando o escopo ambíguo e facilitando desentendimentos.
Em linguagem simples: Define dois modelos de pagamento: preço fixo por entrega específica, ou tempo & materiais conforme taxas do Anexo B.
"Projeto Preço Fixo" é trabalho com pagamento baseado em entrega específica. "Projeto Tempo & Materiais (T&M)" é trabalho com pagamento baseado em taxas estabelecidas no Anexo B.
Erro comum: Misturar os dois modelos sem deixar claro qual se aplica a cada fase, causando disputas de faturamento.
Em linguagem simples: Especifica que funcionários e sub-contratados do desenvolvedor não são funcionários do cliente e que sub-desenvolvedores requerem aprovação.
"Desenvolvimento Pessoal" significa funcionários, agentes e sub-desenvolvedores fornecidos pelo desenvolvedor. Essas pessoas não serão em nenhuma hipótese consideradas funcionárias do Cliente.
Erro comum: Permitir sub-contratação sem aprovação formal, comprometendo qualidade ou confidencialidade.
Em linguagem simples: Estabelece que ambas as partes devem proteger informações sensíveis compartilhadas durante a execução do contrato.
"Informações Confidenciais" são dados, segredos comerciais e informações sensíveis compartilhadas sob dever de sigilo, conforme detalhado na Seção 11.
Erro comum: Não definir claramente o que é confidencial, permitindo que o desenvolvedor reutilize estratégias ou dados do cliente com outros.
Em linguagem simples: Identifica as pessoas com poder legal para assinar o contrato em nome de cada parte.
"Signatário Autorizado" significa [NOME] pelo cliente e [NOME] pelo desenvolvedor.
Erro comum: Assinar com pessoa sem poder de representação, tornando o contrato potencialmente inválido.
Em linguagem simples: Designa um funcionário do cliente responsável por supervisionar e coordenar o trabalho com o desenvolvedor.
"Coordenador Técnico do Cliente" significa o funcionário designado pelo Cliente para supervisionar e coordenar o trabalho a ser realizado.
Erro comum: Não designar um coordenador claro, resultando em comunicação confusa e atrasos.
Insira o nome completo, tipo de organização (empresa, parceria, etc.), estado/distrito e endereço completo do cliente e do desenvolvedor. Certifique-se de usar o nome legal exato registrado nos documentos oficiais.
💡 Copie dados diretamente de CNPJ/RG ou documentos de constituição para evitar inconsistências.
Preencha [DATA] com a data em que ambas as partes assinam e o acordo entra em efeito. Recomenda-se usar o formato dia/mês/ano.
💡 Use a data da última assinatura se houver assinatura em sequência.
Insira o nome completo e cargo da pessoa com autoridade legal para assinar em nome de cada parte (cliente e desenvolvedor).
💡 Verifique com o departamento jurídico ou RH se a pessoa indicada tem realmente poder de representação.
Na seção de definições, especifique a natureza das atividades do cliente e liste empresas consideradas concorrentes para fins de restrição de confidencialidade.
💡 Seja específico: se o cliente vende software de CRM, liste nomes de fabricantes de CRM, não apenas 'empresas de software'.
Crie ou anexe um modelo de Declaração de Trabalho que será usado para cada projeto, especificando formato, campos obrigatórios e padrões de desempenho.
💡 O SOW deve ser detalhado o suficiente para evitar ambiguidades, mas flexível o bastante para reutilização em projetos futuros.
Para projetos de tempo & materiais, liste as taxas horárias ou diárias por tipo de profissional (programador senior, junior, analista, etc.) e despesas cobertas.
💡 Atualize taxas anualmente ou conforme acordo; taxas desatualizadas podem resultar em disputas de faturamento.
Confirme quem é dono do código gerado, da documentação e de qualquer IP criado durante o projeto. Certifique-se de que IP pré-existente do desenvolvedor está claramente identificado.
💡 Consulte um advogado para alinhar essa seção com a lei de direitos autorais local (LGPL, MIT, etc., se aplicável).
IP pré-existente refere-se a propriedade intelectual que o desenvolvedor já possuía ou criou independentemente antes deste contrato. Definir claramente o que é pré-existente é crucial porque protege o direito do desenvolvedor de reutilizar código, frameworks ou conhecimento em outros projetos, evitando disputas legais. Se não for definido, o cliente pode reivindicar propriedade total de tudo que o desenvolvedor usa, impedindo que ele trabalhe com outros clientes. O contrato exige que qualquer IP pré-existente seja documentado e claramente separado do trabalho customizado para o cliente.
Em um projeto de preço fixo, o cliente e o desenvolvedor concordam antecipadamente com um valor total para uma entrega específica (ex: \"criar um app por R$ 50.000\"). O risco de aumento de custo é do desenvolvedor. Em tempo & materiais (T&M), o cliente paga por horas gastas (ex: R$ 150/hora) e o desenvolvedor reporta as horas trabalhadas. O risco de custo aberto é do cliente. Projetos de preço fixo são melhor para escopo bem definido; T&M é melhor para projetos exploratórios ou sujeitos a mudanças frequentes. Este contrato permite ambos os modelos, desde que especificados claramente no SOW de cada projeto.
De acordo com este contrato, sub-desenvolvedores são permitidos, mas geralmente requerem aprovação prévia do cliente, especialmente se envolverem acesso a informações confidenciais ou código crítico. O contrato exige que sub-desenvolvedores sejam formalmente aprovados (\"Aprovado pelo Sub-desenvolvedor\"), e recomenda-se fazer um acordo de confidencialidade separado com eles. O desenvolvedor permanece responsável por qualquer trabalho entregue por sub-contratados, então é no interesse do desenvolvedor gerenciar essa cadeia com cuidado.
Documentação inclui código-fonte, design, fluxogramas, especificações técnicas, manuais de operador e materiais de suporte. Este contrato requer que toda documentação seja entregue como parte do projeto e geralmente pertence ao cliente (uma vez pago), a menos que componentes específicos sejam identificados como IP pré-existente do desenvolvedor. O SOW de cada projeto deve especificar claramente quais documentos serão entregues, em que formato e quando. Recomenda-se exigir que o código seja bem comentado para facilitar manutenção futura.
Este contrato exige que cada projeto tenha um SOW escrito aprovado por ambas as partes. Se o cliente pedir mudanças durante a execução, essas mudanças devem ser documentadas em um aditivo ou uma ordem de serviço adicional. Se for um projeto de preço fixo, mudanças podem justificar uma alteração de preço. Se for T&M, mudanças adicionais são simplesmente cobradas como horas extras conforme as taxas do Anexo B. O contrato protege ambas as partes evitando que uma parte alegue \"mudança de escopo\" sem documentação formal.
Na seção de definições, o contrato exige que o cliente especifique a natureza de suas atividades e liste empresas ou tipos de empresas consideradas concorrentes (ex: \"qualquer fabricante de software de CRM\"). Isso define o âmbito da restrição de confidencialidade — o desenvolvedor não pode usar informações do cliente para trabalhar com empresas listadas. Ser muito amplo (ex: \"qualquer empresa de software\") pode impedir que o desenvolvedor trabalhe em múltiplas áreas; ser muito restrito pode deixar brechas. Recomenda-se definir competitores de forma específica e realista.
Um Signatário Autorizado é a pessoa com poder legal para assinar o contrato em nome da empresa (ex: CEO, diretor jurídico). Um Coordenador Técnico é um funcionário designado para supervisionar o trabalho dia a dia, coordenar mudanças e validar entregas. Podem ser a mesma pessoa em empresas pequenas, mas em grandes organizações são papéis diferentes. O Coordenador Técnico é o ponto de contato operacional; o Signatário Autorizado é responsável legal pelo contrato.
Este contrato refere-se a \"Informações Confidenciais\" conforme definido na Seção 11, mas você deve especificar no Anexo B ou em cláusula adicional por quanto tempo a obrigação de confidencialidade persiste após o término (ex: 2 anos, 5 anos, perpetuamente). Períodos comuns são 2-5 anos para segredos comerciais e perpetuamente para patentes não registradas. Informações que se tornam públicas por razão fora do controle do desenvolvedor (ex: o cliente publica no GitHub) geralmente são isentas. Essa duração deve ser clara e razoável com base no tipo de informação.
O contrato refere-se à \"aceitação\" (Seção 5), que deve definir como o cliente valida e aprova o trabalho. Normalmente, o SOW especifica critérios de aceitação (ex: código deve passar em testes automatizados, documentação deve incluir exemplos funcionais). O Coordenador Técnico do Cliente revisa o trabalho e o cliente pode aceitar ou rejeitar com feedback específico. Se há desacordo persistente, o contrato pode prever uma disputa técnica (ex: revisão por terceira parte independente) ou mediação antes de litigar. Recomenda-se deixar critérios de aceitação muito claros no SOW para evitar disputas.
Um contrato de prestação de serviços genérico é amplo e pode cobrir qualquer tipo de serviço (limpeza, consultoria, desenvolvimento). Este acordo é específico para desenvolvimento de software e programação, com termos detalhados sobre propriedade intelectual, documentação técnica, IP pré-existente, sub-desenvolvedores e modelos de pagamento (preço fixo vs. T&M). Use o acordo de cliente e desenvolvedor quando há envolvimento claro de código, software ou sistemas técnicos complexos.
Um NDA simples cobre apenas proteção de informações sensíveis, mas não define responsabilidades, prazos, pagamento ou propriedade de trabalho. Este acordo é um contrato completo que inclui confidencialidade como uma cláusula (Seção 11), mas também trata escopo, entregas, pagamento e direitos autorais. Use o contrato de cliente e desenvolvedor como contrato principal; um NDA separado é útil para proteger informações antes de assinar o contrato principal.
Um contrato de licença define os direitos do cliente de usar software já pronto (ex: licença do Microsoft Office). Este acordo regula a criação e entrega de software customizado. Depois que o desenvolvimento é concluído e o software é entregue ao cliente, ambas as partes podem executar um contrato de licença separado para definir permissões de uso, upgrades e suporte contínuo.
Um acordo de sub-contratação é assinado entre o desenvolvedor principal e o sub-desenvolvedor, definindo obrigações do sub-contratado. Este acordo é entre o cliente final e o desenvolvedor principal. Quando sub-desenvolvedores estão envolvidos, o desenvolvedor principal deve executar um acordo de sub-contratação separado (ou exigir que o sub-desenvolvedor assine uma NDA) para manter a segurança da cadeia.
Estrutura a relação entre cliente e agência ou freelancer de desenvolvimento, protegendo IP e documentação técnica.
Define termos para contratação de desenvolvedores que criam lojas online, integrações de pagamento e sistemas de inventário.
Permite que empresas de consultoria contratem desenvolvedores para customizar sistemas e entregar soluções de negócio.
Protege propriedade intelectual essencial ao permitir contratar desenvolvedores externos para MVP e escalabilidade.
Formaliza contratação de desenvolvedores para plataformas de aprendizagem, conteúdo interativo e sistemas de gestão acadêmica.
Inclui cláusulas de confidencialidade e compliance críticas ao trabalhar com dados sensíveis e sistemas regulados.
No Brasil, propriedade intelectual é regida pela Lei 9.610/98 (direitos autorais) e Lei 10.196/01 (lei de software). Recomenda-se adaptar o contrato para incluir referências a essas leis e considerar se o software será desenvolvido como "obra por encomenda" (os direitos pertencem ao cliente por padrão) ou "obra independente" (desenvolvedor retém direitos). Adicione cláusula sobre LGPL/MIT se aplicável.
Em Portugal, direitos autorais são protegidos pela Lei 63/85, e software é considerado trabalho artístico/literário. Verifique se é necessário registrar o contrato junto à Autoridade Tributária (para fins fiscais) e se há obrigações de conformidade RGPD se o software processar dados pessoais. Adapte referências de "Estado/Distrito" para sistema administrativo português (distritos ou regiões autónomas).
| Caminho | Melhor para | Custo | Tempo |
|---|---|---|---|
| Use o modelo | Projeto simples, desenvolvedor conhecido, confidencialidade baixa, ou orçamento muito limitado. | Grátis (modelo) + custos de negociação interna. | 2–4 horas de preenchimento e aprovação interna. |
| Modelo + revisão jurídica | Projeto de valor médio, desenvolvedor novo, proteção de IP importante, ou jurisdição complexa. | Grátis (modelo) + R$ 1.000–3.000 de revisão jurídica. | 1–2 semanas com ciclos de revisão. |
| Redigido sob medida | Projeto de alto valor, propriedade intelectual crítica, compliance regulatório, ou relacionamento de longo prazo com desenvolvedor. | R$ 3.000–8.000+. | 2–4 semanas para rascunho, negociação e finalização. |
Este documento é um dos 3,000+ modelos comerciais e jurídicos incluídos no Business in a Box.
Acesse mais de 3,000+ modelos empresariais e jurídicos para qualquer tarefa, projeto ou iniciativa.
Personalize seu modelo de documento empresarial pronto para uso e salve-o na nuvem.
Compartilhe seus arquivos e pastas com sua equipe. Crie um espaço de colaboração contínua.
"De um valor fantástico! Não sei o que faria sem essa plataforma. Vale cada centavo e valeu o investimento diversas vezes."
"Eu uso o Business in a Box há 4 anos. Tem sido a fonte mais útil de documentos que encontrei. Recomendo a todos."
"Salvou minha vida tantas vezes que eu perdi a conta. O Business in a Box me poupou muito tempo e, como você sabe, tempo é dinheiro."
Pare de baixar documentos. Comece a operar com clareza. Business in a Box fornece o sistema operacional usado por mais de 250.000 empresas no mundo para estruturar, gerenciar e expandir seu negócio.
Plano gratuito para sempre · Não exige cartão de crédito
