Download Word gratuito • Edite on-line • Salve e compartilhe com Drive • Exporte para PDF
É um contrato completo que formaliza a relação entre sua empresa e um desenvolvedor (freelancer, agência ou empresa de software) para criar, customizar ou modificar um sistema. O acordo estrutura o projeto em fases claras, define escopo técnico, estabelece datas de entrega, especifica testes de aceitação e organiza uma estrutura de pagamento escalonada que protege ambas as partes. Download Word gratuito, totalmente editável, pronto para preencher com seus dados e exportar em PDF para assinatura digital ou impressa.
Contratos verbais ou e-mails casual criam confusão sobre o que será entregue, quando, e por quanto — levando a atrasos, custos crescentes e disputas legais caras. Um desenvolvedor pode parar o projeto ou entregar código incompleto; você pode ficar preso pagando por um sistema que não funciona. Este acordo reduz riscos ao estabelecer expectativas cristalinas: define cada funcionalidade, marco intermediário com teste de aceitação, penalidades por atraso, direito de cancelamento se a entrega atrasar demais, e percentuais de pagamento vinculados a milestones reais. Protege seu investimento de software e evita surpresas.
| Se sua situação é… | Use este modelo |
|---|---|
| Projetos pequenos com 2–3 fases de desenvolvimento | Acordo básico com fases simples |
| Projetos complexos com várias aplicações e modificações | Acordo com múltiplas sub-fases |
| Quando há risco alto de atraso e margem é crítica | Acordo com penalidades escalonadas |
| Projetos que exigem manutenção ou assistência técnica após go-live | Acordo com suporte pós-entrega |
| Serviços de análise, treinamento ou orientação estratégica | Acordo de consultoria pura (sem desenvolvimento) |
Por que importa: Sem escopo claro, o desenvolvedor pode entregar menos que o esperado, e a empresa pode exigir mudanças infinitas, causando atrasos e custos crescentes.
Fix: Descreva cada funcionalidade esperada, integração, relatório e tela, idealmente com protótipos ou diagramas anexados.
Por que importa: Sem procedimento claro de teste e correção, a empresa fica presa a código ruim; o desenvolvedor pode negar responsabilidade.
Fix: Inclua o procedimento de teste de aceitação e prazo máximo para correções; deixe claro que o desenvolvedor paga penalidade se não corrigir no prazo.
Por que importa: Se o desenvolvedor recebe a maioria do pagamento antes de entregar, pode abandonar o projeto; se recebe pouco adiantado, pode pedir cancelamento.
Fix: Negocie percentuais equilibrados: ~30% na assinatura da fase, ~40% na entrega, ~20% na aprovação de teste, ~10% após uptime.
Por que importa: Pode haver espera indefinida por aprovação, atrasando o projeto inteiro e gerando disputa sobre responsabilidade.
Fix: Estabeleça prazo máximo para revisão e aprovação (ex: 5 dias úteis); se empresa não responder, especificações são consideradas aprovadas automaticamente.
Por que importa: Penalidades inviáveis criam incentivo para o desenvolvedor ignorar o contrato ou entrar em litígio em vez de trabalhar.
Fix: Baseie penalidades em números históricos do setor; 5–10% de redução por cada período de atraso é comum.
Por que importa: Ambas as partes ficam presas indefinidamente a um contrato quebrado, gerando frustração e custos legais.
Fix: Permita que qualquer parte cancele após falha consistente em marco intermediário; inclua direito de retenção de código e documentação já pagos.
Em linguagem simples: Especifica que serviços profissionais incluem análise de sistemas, desenvolvimento, treinamento, documentação e consultoria geral.
O termo 'Serviços de Consultoria' refere-se à prestação de serviços profissionais que incluem, mas não estão limitadas a, análise de sistemas, desenvolvimento de programas, treinamento de pessoal, criação de documentação e consultoria de negócios em geral.
Erro comum: Deixar a definição genérica demais, sem especificar quais serviços estão realmente inclusos ou exclusos.
Em linguagem simples: Define claramente que o desenvolvedor criará software personalizado modificando ou adaptando pacotes existentes conforme requisitos da empresa.
O Desenvolvedor deve desenvolver um programa personalizado que irá [MODIFICAR/ADAPTAR/ALTERAR] os seguintes pacotes de software pré-existentes: [DESCREVER].
Erro comum: Não especificar quais pacotes base serão usados ou quais modificações exatamente o desenvolvedor fará, causando desentendimentos sobre escopo.
Em linguagem simples: Divide o projeto em fases e sub-fases, cada uma concebida, aprovada, desenvolvida, testada e entregue conforme procedimentos estabelecidos.
A definição dos requisitos da empresa deve ocorrer em fases, cada fase representando uma divisão da operação da empresa. Cada Fase deve ser concebida, aprovada, programada, entregue, testada e aprovada em conformidade com os procedimentos listados abaixo.
Erro comum: Não separar claramente as fases, resultando em ambiguidade sobre o que é entregável em cada etapa e quando começam os pagamentos.
Em linguagem simples: A empresa aprova ou rejeita as especificações de programação após consultoria com o desenvolvedor; aprovação é critério exclusivo da empresa.
Após a recepção das especificações de programação, a empresa irá aprovar ou desaprovar ditas especificações. Essa aprovação será a critério exclusivo da Companhia.
Erro comum: Não deixar claro quem tem autoridade de rejeitar especificações, gerando conflitos sobre quem pode parar o projeto.
Em linguagem simples: Define pagamentos em percentuais na assinatura da fase, entrega no prazo, e após teste de aceitação, com redução por atraso.
Após a assinatura da Fase de Acordo, a Empresa deverá pagar [X%] dos custos. Na entrega dentro do prazo, [Y%]. Na passagem do teste de aceitação, [Z%]. Após [NÚMERO] dias de uso ao vivo sem falhas, [RETENÇÃO FINAL].
Erro comum: Não definir claramente os percentuais ou as datas de pagamento, deixando ambiguidade sobre quanto é devido em cada marco.
Em linguagem simples: Se o desenvolvedor não entregar no prazo, a empresa pode reduzir o pagamento da fase em percentual por cada período de atraso.
A falta do desenvolvedor em entregar a programação concluída até ao final do dia [NÚMERO] após a data de entrega dará direito a uma redução de [%] dos custos para cada [NÚMERO] dias que o Desenvolvedor esteja em atraso.
Erro comum: Definir penalidades muito altas ou muito vagas, criando disputa sobre quanto realmente será descontado.
Em linguagem simples: Se o desenvolvedor não entregar após período de carência estendido (p.ex. 6 meses após data original), a empresa pode cancelar a fase sem pagamento adicional.
No caso do desenvolvedor não entregar os programas concluído [NÚMERO] meses após a data original, a empresa pode cancelar a Fase de Acordo. Em caso de cancelamento, o desenvolvedor deve entregar todos os trabalhos em curso e especificações na posse do desenvolvedor.
Erro comum: Não definir um ponto final claro onde o cliente pode cancelar, deixando o projeto suspenso indefinidamente.
Em linguagem simples: Estabelece processo formal: notificação por telefone de falhas, confirmação por escrito, prazo de [NÚMERO] dias para reprogramação, nova data de entrega máxima.
Se os programas não conseguirem realizar os testes de aceitação, a empresa deve notificar imediatamente por telefone. A companhia deverá confirmar por carta registrada. Se a falha puder ser sanada dentro de [NÚMERO] dias, os testes devem continuar.
Erro comum: Deixar indefinido como falhas serão comunicadas ou quanto tempo o desenvolvedor tem para corrigir, causando atrasos e conflitos.
Em linguagem simples: Após [NÚMERO] dias de uso ao vivo sem falhas, a empresa pagará o saldo final retido, confirmando que o software está estável em produção.
Após a companhia ter utilizado os programas da fase por um período de [NÚMERO] dias consecutivos do tempo de atividade sem falhas, a empresa deverá pagar ao desenvolvedor o pagamento final.
Erro comum: Não definir o que conta como 'falha' ou 'dia de atividade', causando disputa sobre quando o período começa e se interrupções o reiniciam.
Em linguagem simples: A data de entrega só pode ser alterada por aditamento escrito assinado por ambas as partes.
A data de entrega só poderá ser modificada por aditamento escrito à Fase de Acordo assinado por ambas as partes.
Erro comum: Permitir ajustes verbais de prazos, criando registro inconsistente sobre datas reais de entrega.
Preencha o nome legal completo, estado de incorporação e endereço da empresa (Dono) e do desenvolvedor ou empresa (Desenvolvedor).
💡 Use o nome legal exato conforme certificado ou contrato social; iniciais incorretas podem invalidar a assinatura.
Na seção 'Considerações', indique que software será desenvolvido ou qual sistema será customizado, e os objetivos do projeto.
💡 Seja específico: em vez de 'melhorar o sistema', diga 'desenvolver módulo de gestão de clientes com integração ao ERP X'.
Se o desenvolvedor vai modificar software pré-existente, nomeie cada pacote, versão e funcionalidades a adaptar.
💡 Anexe documentação técnica do software existente para evitar surpresas sobre compatibilidade ou limitações.
Divida o projeto em fases clara (ex: Fase 1 = módulo de autenticação; Fase 2 = integração de pagamentos). Para cada fase, especifique escopo, aplicações a criar e funcionalidades.
💡 Use de 2 a 4 fases; muitas fases tornam o contrato complexo; poucas aumentam risco de mudanças de escopo.
Para cada fase, insira data de entrega, preço total fixo, e percentuais para assinatura (ex: 30%), entrega (40%), teste (20%), uptime final (10%).
💡 A soma dos percentuais deve chegar a 100%. Retenha 10–20% até o período de uptime real para garantir qualidade.
Defina quantos dias após a data original o desenvolvedor pode ainda entregar sem cancelamento (ex: 60 dias). Especifique redução de pagamento por atraso (ex: 5% por 15 dias de atraso).
💡 Seja realista: um período de carência muito curto pode não ser atingível; muito longo favorece o desenvolvedor.
Especifique quantos dias o desenvolvedor tem para corrigir falhas (ex: 15 dias) e quantos dias de uptime real confirmam aprovação final (ex: 30 dias).
💡 Coordene com o departamento de TI qual é um período realista de teste e estabilização em ambiente de produção.
Prepare anexos A e B: Anexo A com template de especificações funcionais; Anexo B com procedimentos de teste de aceitação padrão.
💡 Use checklists no Anexo B para garantir que ambas as partes testam os mesmos critérios.
Teste de aceitação é um procedimento padronizado que você e o desenvolvedor definem juntos no início (Anexo B). Ele lista funcionalidades que o software deve executar (ex: 'login funciona com e-mail e senha', 'relatório de vendas exibe dados dos últimos 30 dias'). Após a entrega, você executa esses testes. Se o software passar em todos, a fase é considerada aprovada e você paga o percentual de aceição. Se falhar, o desenvolvedor tem prazo (ex: 15 dias) para corrigir e reapresentar. Isso protege você contra software inacabado ou com bugs críticos.
Depende do contrato. Este modelo permite que você retenha uma percentagem final (ex: 10%) até depois de 30 dias de uso em produção sem falhas. Ele também inclui redução de pagamento: se o desenvolvedor atrasar mais de [número] dias, você desconta [percentual] do valor da fase para cada período adicional. Se o atraso ultrapassar o período de carência (ex: 6 meses), você pode cancelar a fase completamente e pedir que o desenvolvedor entregue todo o código e documentação que tem, sem pagar mais. Confira a jurisdição local, pois regras de penalidade variam.
Sim, mas apenas por escrito. O contrato diz que 'A data de entrega só poderá ser modificada por aditamento escrito à Fase de Acordo assinado por ambas as partes.' Isso significa que não vale acordo verbal ou e-mail casual; você e o desenvolvedor devem assinar um documento oficial estendendo o prazo. Isso evita confusão sobre qual é a data real e protege ambos contra afirmações posteriores de 'eu pensei que era outro dia'.
'Serviços de Consultoria' cobrem atividades de análise, treinamento, documentação e orientação. 'Desenvolvimento de Software' é o código customizado que o desenvolvedor cria. O contrato permite que o desenvolvedor forneça ambos: ele analisa suas necessidades (consultoria), desenha as especificações (consultoria), desenvolve o código (desenvolvimento) e treina sua equipe (consultoria). O preço fixo da fase cobre tudo.
Este contrato não cobre garantia pós-entrega explicitamente. Após o período de uptime real (ex: 30 dias) e você pagamento final, o software entra em posse exclusiva sua. Se falhar depois, tecnicamente o desenvolvedor não é obrigado a consertar de graça. Se você quer garantia estendida (ex: 90 dias, 6 meses), negocie uma cláusula de 'Suporte Pós-Go-Live' no contrato ou em aditamento. Confira a lei local — em muitas jurisdições, software defeituoso tem garantia implícita de qualidade.
Este modelo não aborda cibersegurança ou responsabilidade por perda de dados em detalhe. Antes de assinar, adicione cláusulas sobre: (1) padrões de segurança que o desenvolvedor deve seguir (ex: criptografia, backup); (2) quem é responsável por vazamento de dados (geralmente a parte que causou); (3) se o desenvolvedor precisa manter os dados confidenciais. Estas são questões sensíveis — consulte um advogado com experiência em contratos de TI na sua jurisdição.
Aditamento é qualquer alteração ao contrato original, geralmente em documento separado que referencia o contrato e lista as mudanças. Ele deve ser assinado por ambas as partes. A lei local determina se assinatura digital é válida ou se precisa ser manuscrita. Na maioria das jurisdições modernas, assinatura eletrônica (e-signature) é legal. Se em dúvida, peça que ambas as partes imprimam, assinem à mão, e enviem cópia por e-mail ou escaneada — isso cria registro claro.
Sim. Este modelo usa 'Desenvolvedor' como placeholder, que pode ser uma pessoa física (autônomo/freelancer), empresa ou ambas. Se for autônomo, preencha o nome completo, CPF/RG ou número de registro profissional, e endereço pessoal nas linhas de identificação. Verifique se a lei local exige contrato de prestação de serviços adicional ou registro de imposto para freelancer; jurisdições variam.
Um RFP descreve o que você quer e pede que fornecedores apresentem propostas de preço e prazo. Este acordo é o contrato que você assina após escolher um fornecedor. O RFP é a especificação; este contrato é a obrigação legal. Você pode usar um RFP para definir escopo antes de assinar este acordo, mas o RFP não substitui o contrato.
Um contrato de manutenção cobre suporte, correção de bugs e atualizações após o software estar pronto. Este acordo cobre apenas o desenvolvimento e entrega inicial. Se você quer suporte pós-entrega (ex: 'desenvolvedor corrige bugs por 6 meses'), adicione cláusula de manutenção ou negocie contrato adicional separado após entrega.
Este acordo é para desenvolvimento customizado do zero ou modificação de software existente. Um contrato de licença é para comprar direito de usar software pronto (ex: Microsoft Office, Salesforce). Se você está licenciando software pronto e apenas pedindo customização menor, você pode usar ambos os contratos juntos.
Se o desenvolvedor é empregado seu (contratado full-time ou part-time com benefícios), você usa contrato de trabalho, não este acordo. Este acordo é para contratação de terceiros (freelancer, agência, empresa de software) para projeto específico. Lei local sobre classificação de 'empregado vs. contratante' varia — confira com RH e contador.
Fornecedores e clientes de software customizado usam este contrato para formalizar desenvolvimento de novas aplicações, integrações e modificações de sistemas.
Consultorias de negócio e consultores de TI usam o modelo para contratos de análise, desenho de soluções e implementação técnica.
Instituições financeiras contratam desenvolvedoras de software para sistemas de conformidade regulatória, processamento de transações e relatórios.
Empresas de produção e logística usam para desenvolvimento de sistemas ERP, rastreamento e otimização de processos.
Lojas online contratam desenvolvimento de plataformas de venda, integrações de pagamento e sistemas de gestão de estoque.
Clínicas e hospitais usam para software de prontuário eletrônico (PEP), gestão de pacientes e conformidade com regulação de dados de saúde.
No Brasil, contratos de desenvolvimento são regidos pelo Código Civil (2002) e Lei de Software (Lei n.º 9.609/98). Defina claramente a propriedade do código e direitos autorais. A legislação brasileira reconhece contratos por escrito assinados digitalmente (MP 2.200-2/2001). Considere incluir cláusula de Lei Aplicável (Lei Brasileira) e foro de eleição (município relevante).
Em Portugal, contratos de prestação de serviços e desenvolvimento seguem o Código Civil Português. Assinaturas digitais reconhecidas sob Decreto-Lei 290-D/99. Recomenda-se indicar que o contrato segue Lei Portuguesa e jurisdição dos tribunais portugueses. Cláusulas sobre retenção de direitos autorais devem estar em conformidade com Lei do Direito de Autor (Lei 63/85).
| Caminho | Melhor para | Custo | Tempo |
|---|---|---|---|
| Use o modelo | Pequenos projetos de software, relação com desenvolvedor conhecido, ou quando orçamento é apertado. | Grátis ou taxa baixa do modelo; seu tempo para preencher. | 2–4 horas para preencher todas as cláusulas e percentuais de pagamento. |
| Modelo + revisão jurídica | Projeto de médio porte (desenvolvimento > 3 meses), valor significativo, ou relacionamento novo com desenvolvedor. | Taxa do modelo + US$ 500–1500 para revisão jurídica rápida. | 4–6 horas suas + 2–3 dias do advogado para revisão e ajustes. |
| Redigido sob medida | Projeto muito complexo, multinacional, ou relacionamento de alto risco; desenvolvimento adiado ou valor > US$ 100 mil. | US$ 2000–5000+ para advogado especializado em TI elaborar do zero. | 2–3 semanas; coordenação constante com advogado e desenvolvedor. |
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
