Download Word gratuito • Edite on-line • Salve e compartilhe com Drive • Exporte para PDF
Um Acordo de Design de Website é um contrato profissional que formaliza a relação entre um desenvolvedor (ou agência) e um cliente que contrata a criação de um website. O modelo documenta de forma clara o escopo do projeto, especificações técnicas, responsabilidades de cada parte, cronograma de desenvolvimento, processo de aceitação e entrega, estrutura de pagamento em estágios, e direitos sobre backup e manutenção futura. Disponível como download Word editável, permite preenchimento rápido de dados específicos do projeto sem necessidade de redação legal complexa. Pode ser exportado em PDF para assinatura digital ou impressa.
Sem um acordo formalizado, projetos web enfrentam riscos significativos: ambiguidade sobre quem fornece qual conteúdo (levando a atrasos e retrabalho), expectativas conflitantes sobre design final (cliente pode solicitar mudanças indefinidas sem compensação ao desenvolvedor), ausência de proteção financeira (cliente pode recusar pagar alegando insatisfação, deixando desenvolvedor sem lucro), e cronogramas infinitos (projeto arrasta meses sem data clara de conclusão). Este documento protege ambas as partes ao estabelecer especificações detalhadas no início (Inventários A–E), marcos de desenvolvimento com prazos fixos (Inventário F), estrutura de pagamento escalonada ligada a marcos (Inventário G), e período claro de aceitação após entrega. Para desenvolvedor, garante compensação proporcional e limite de revisões. Para cliente, documenta exatamente o que receberá, quando e por quanto, reduzindo surpresas e disputas.
| Se sua situação é… | Use este modelo |
|---|---|
| Website institucional de 5–10 páginas, sem ecommerce ou funcionalidades complexas | Acordo básico — projeto simples |
| Quando desenvolvedor também fornecerá hosting e manutenção contínua | Acordo com hospedagem incluída |
| Projeto que requer múltiplas iterações e refinamento de design | Acordo com revisões ilimitadas |
| Cliente fornecerá redação profissional ou fotografia por conta própria | Acordo com conteúdo terceirizado |
| Projeto de médio/grande porte com 3+ fases de desenvolvimento | Acordo com estágios de pagamento |
| Incluir período de correções de bugs e pequenos ajustes após entrega | Acordo com suporte pós-lançamento |
Por que importa: Resulta em atrasos quando cliente espera que desenvolvedor crie conteúdo que cliente deveria fornecer, causando dispute de responsabilidade e aumento de custo.
Fix: Liste explicitamente cada item no Inventário B (cliente) e C (desenvolvedor); não deixe nada indefinido.
Por que importa: Sem período claro de aceitação, cliente pode notificar problemas meses depois, obrigando desenvolvedor a revisar trabalho antigo sem compensação adicional.
Fix: Defina número fixo de dias (ex: 10 dias) após entrega final para cliente notificar desvios; após isso, site é presumido aceito.
Por que importa: Cliente pode solicitar mudanças de design indefinidamente, tornando projeto improfissional e não rentável para desenvolvedor.
Fix: Inclua cláusula que limita ciclos de revisão (ex: 2 ciclos de revisão incluídos; ciclos adicionais pagos) ou defina mudanças como 'fora de escopo'.
Por que importa: Desenvolvedor fica sem proteção financeira; cliente pode recusar pagar alegando insatisfação, deixando desenvolvedor sem compensação.
Fix: Fixe taxa total na cláusula 3.1; estruture pagamento em depósito + marcos (ex: 40% inicial, 30% ao design, 30% final) para partilhar risco.
Por que importa: Projeto pode arrastar indefinidamente; cliente fica incerto sobre quando o site estará pronto, prejudicando seu plano de negócios.
Fix: Defina cronograma claro no Inventário F com datas específicas para cada marco; inclua cláusula que atrasos de cliente estendem cronograma.
Por que importa: Site pode ser entregue em formato incompatível com hosting do cliente, rendendo inútil o trabalho ou causando custo adicional de migração.
Fix: Especifique linguagens de programação (HTML, PHP, etc.), limite de tamanho de ficheiro, e confirmação de que site é compatível com servidor específico de cliente.
Em linguagem simples: Cliente compromete-se a fornecer todo conteúdo necessário (texto, imagens, vídeos, logos, banco de dados) em formato e prazo especificados, permitindo que desenvolvedor possa integrar no site.
Dentro de [NUMERO] dias da assinatura, o Cliente irá entregar os itens listados no Inventário B, incluindo materiais de texto, logotipos, fotografias, arquivos de som e vídeo, em formatos especificados (GIF para logos, JPG para fotografias, MP3 para áudio, MPEG para vídeo).
Erro comum: Não especificar formatos de ficheiro aceitáveis, levando a retrabalho quando cliente fornece ficheiros incompatíveis ou de qualidade inadequada.
Em linguagem simples: Desenvolvedor concorda em criar especificamente os elementos de conteúdo listados (gráficos customizados, animações, etc.), podendo usar subcontratados para tal.
O Desenvolvedor terá a obrigação de criar o conteúdo específico listado no Inventário C anexado, sendo autorizado a utilizar subcontratados conforme julgar necessário.
Erro comum: Deixar ambíguo quem cria qual conteúdo, resultando em expectativas conflitantes sobre responsabilidade de design gráfico ou redação.
Em linguagem simples: Site será desenvolvido em conformidade com mapa de navegação e modelo visual fornecido, assegurando que design final corresponde à visão do cliente.
O Site será desenhado em grande conformidade com o mapa do site e o modelo anexado aqui no Inventário D.
Erro comum: Não anexar ou detalhar o modelo visual, permitindo interpretação subjetiva sobre como site deve parecer.
Em linguagem simples: Desenvolvedor incluirá meta tags com palavras-chave especificadas, melhorando visibilidade em motores de busca sem incluir conteúdo oculto não autorizado.
O Consumidor dirige ao Desenvolvedor para incluir Meta Tags no Site com as palavras-chave definidas no Inventário E, sem incluir qualquer texto escondido não requisitado.
Erro comum: Não fornecer lista clara de palavras-chave desejadas, resultando em site com visibilidade de busca subótima.
Em linguagem simples: Após entrega final, cliente tem número específico de dias para testar e notificar desenvolvedor de qualquer não-conformidade; silêncio após prazo implica aceitação.
O Consumidor terá [NUMERO] dias após entrega final para notificar o Desenvolvedor de itens não conformes com as especificações. Após este período, o Site é considerado aceito em todos os aspectos.
Erro comum: Deixar ambíguo quando o período de aceitação começa (a partir da entrega ou da notificação) ou não incluir mecanismo para aceitação presumida.
Em linguagem simples: Desenvolvedor tem prazo fixo para corrigir itens não-conformes; cliente pode notificar novamente desvios nas correções; processo continua até aceitação final.
O Desenvolvedor terá [NUMERO] dias para corrigir itens levantados pelo Cliente. O Cliente terá [NUMERO] dias para avisar de não-conformidade nas correções. O Desenvolvedor terá [NUMERO] dias para fazer novos ajustes. Este procedimento continua até aceitação final.
Erro comum: Não limitar número de ciclos de revisão, levando a mudanças infinitas e custo imprevisto para desenvolvedor.
Em linguagem simples: Cliente paga depósito inicial na assinatura, depois parcelas adicionais ao atingir marcos de desenvolvimento específicos, com fatura emitida a cada estágio.
O Consumidor pagará [QUANTIA] como pagamento inicial ao assinar este Acordo. O restante será pago conforme o Plano de Pagamentos anexado no Inventário G, com fatura emitida ao completar cada estágio de desenvolvimento.
Erro comum: Não detalhar que estágios justificam pagamento, causando disputa sobre quando cliente é obrigado a pagar.
Em linguagem simples: Site final será entregue em arquivo comprimido (Disco Zip) com máximo 100mb, contendo todos os ficheiros em HTML, JAVA e/ou FLASH em versões atualizadas.
O Site final será entregue ao Consumidor em um Disco Zip de 100mb, em formato de HTML, JAVA e/ou FLASH nas versões mais atuais, completamente funcional e pronto para colocação em servidor.
Erro comum: Não especificar limite de tamanho ou formato técnico, levando a ficheiros inúteis ou incompatíveis com infraestrutura de hosting do cliente.
Em linguagem simples: Desenvolvedor garante que todos os links estão testados e funcionais antes de entrega final, reduzindo riscos de erro imediatamente após lançamento.
Todos os links contidos no Site devem ser testados e confirmados como precisos antes da entrega do Site final ao Consumidor.
Erro comum: Omitir esta cláusula, permitindo que site seja entregue com links quebrados ou redirecionamentos incorretos.
Em linguagem simples: Desenvolvedor retém cópia de segurança dos ficheiros do site por número fixo de dias após aceitação; após prazo, todas as cópias são destruídas, a menos que hosting seja contratado separadamente.
O Desenvolvedor reterá um backup dos arquivos do Site por um período de [NUMERO] dias após a aceitação final. Após isso, o Desenvolvedor destruirá todas as cópias, a menos que disponibilize hosting em Acordo separado.
Erro comum: Deixar indefinido por quanto tempo backup é retido, causando incerteza sobre quando dados do cliente serão deletados.
Em linguagem simples: Valor total fixo acordado pelo projeto completo de design, desenvolvimento e entrega conforme especificações, payável conforme plano escalonado.
Em consideração aos serviços a serem realizados, o Consumidor pagará ao Desenvolvedor uma Taxa de Desenvolvimento total igual a [QUANTIA], payável conforme o Plano de Pagamento do Inventário G.
Erro comum: Não fixar taxa total, permitindo que desenvolvedor cobre por horas extras ou alterações de escopo sem limite pré-acordado.
Em linguagem simples: Desenvolvedor usa esforço razoável para cumprir cronograma, mas reconhece que mudanças de especificações, desvios de plano e atrasos de cliente causam adiamentos legítimos.
O Desenvolvedor usará esforços razoáveis para atingir o plano de finalização anexado no Inventário F. No entanto, o Consumidor reconhece que mudanças nas especificações, atrasos do Consumidor na entrega de Conteúdo e revisões lentas levarão a atrasos no cronograma.
Erro comum: Responsabilizar desenvolvedor por prazos sem reconhecer impacto de atrasos de cliente em fornecer conteúdo ou feedback.
Insira o nome completo, tipo de entidade jurídica (pessoa física ou empresa), estado/país e endereço completo do desenvolvedor e do cliente nos campos [NOME DO DESENVOLVEDOR] e [NOME DA COMPANHIA]. Inclua também o domínio do website no campo [ENDEREÇO].
💡 Verifique que nomes e endereços correspondem exactamente aos documentos jurídicos da empresa.
Preencha [DATA] da assinatura. No Inventário A, descreva em detalhe o que o website deve incluir (número de páginas, funcionalidades, layout, responsividade para mobile, etc.), linguagem de programação preferida e requisitos técnicos específicos.
💡 Seja o mais específico possível; especificações vagas causam desentendimentos.
Liste todos os itens que o cliente fornecerá (textos, logos, fotografias, vídeos, base de dados, etc.), especificando formatos aceitáveis (GIF, JPG, MP3, MPEG, [PROCESSADOR DE TEXTO]), tamanho de ficheiro, e prazo de entrega (preencha [NUMERO] dias).
💡 Detalhe o formato de cada tipo de ficheiro para evitar retrabalho.
Liste quais elementos o desenvolvedor criará especificamente (gráficos customizados, animações, redação, etc.), sem incluir conteúdo que cliente fornecerá. Isto clarifica responsabilidades e evita conflitos.
💡 Qualquer coisa não listada aqui assume-se ser responsabilidade do cliente.
Anexe wireframes ou sketches do mapa de navegação do site e mockups visuais (design de cores, tipografia, layout) que o desenvolvedor seguirá. Isto evita surpresas estéticas no final.
💡 Incluir mockups visuais reduz iterações e acelera aprovação.
Liste as palavras-chave e expressões-chave que devem aparecer em meta tags para otimização de motores de busca. Seja específico (ex: 'design web em Lisboa', 'consultoria PME').
💡 Coordene com estratégia de SEO do cliente para garantir palavras-chave relevantes.
Mapeie as fases de desenvolvimento (pesquisa, design, desenvolvimento, teste, revisão) com datas-alvo para cada etapa. Preencha prazos realistas considerando complexidade do projeto.
💡 Inclua buffers para atrasos inevitáveis; cronogramas apertados geram risco de qualidade.
Defina a taxa total de desenvolvimento [QUANTIA], depósito inicial (normalmente 30–50%), e parcelas intermediárias associadas a marcos (ex: 30% ao aprovar design, 40% ao finalizar desenvolvimento). Preencha prazos de pagamento [NUMERO] dias após fatura.
💡 Estruture pagamentos em marcos para proteção de ambas as partes; nunca 100% adiantado ou 100% final.
Cliente fornece normalmente todo o conteúdo editorial (textos, imagens, vídeos, logos) listado no Inventário B. Desenvolvedor cria elementos específicos (gráficos customizados, animações, funcionalidades interativas) listados no Inventário C. Qualquer item não listado em nenhum inventário deve ser esclarecido por escrito antes da assinatura para evitar desentendidos.
Mudanças no escopo original (especificações, design, conteúdo) são consideradas 'fora de escopo' e podem ser cobradas separadamente ou adiar o cronograma. Este acordo inclui cláusula (seção 2.9) que reconhece que desvios de especificações causam atrasos legítimos. É recomendável documentar mudanças solicitadas por escrito e acordar novo cronograma e custo antes de proceder.
Este modelo usa estrutura escalonada: cliente paga depósito inicial na assinatura (normalmente 30–50% da taxa total), depois parcelas adicionais quando marcos específicos são atingidos (design aprovado, funcionalidades testadas), e saldo final após entrega e aceitação. Cada parcela é faturada quando o desenvolvedor notifica que o estágio foi alcançado. Cliente tem [NUMERO] dias após receber fatura para pagar.
O período de aceitação é uma janela fixa (normalmente 5–10 dias) após entrega final durante o qual cliente testa o site e notifica o desenvolvedor de qualquer item não conforme com as especificações. Se cliente não notificar dentro deste prazo, o site é presumido aceito em todos os aspectos, evitando que cliente requeira revisões meses depois. Isto protege desenvolvedor de trabalho infinito e estabelece um final claro para o projeto.
Este modelo cobre design e desenvolvimento, não manutenção contínua. Se cliente deseja que desenvolvedor forneça hosting, suporte técnico, ou atualizações futuras, isto deve ser documentado num acordo separado mencionado na cláusula sobre retenção de backup (seção 2.12). Recomenda-se esclarecer na assinatura se desenvolvedor fornecerá ou não hospedagem.
Este acordo reconhece que o desenvolvedor usará 'esforços razoáveis' para cumprir cronograma, mas que atrasos de cliente (fornecimento lento de conteúdo, revisões lentas) causam atraso legítimo. Se desenvolvedor atrasará sem razão de cliente, é aconselhável incluir cláusula de penalidade (ex: redução de 1% de taxa por semana atrasada) ou direito de cliente rescindir se atraso excede 30 dias. Recomenda-se adicionar isto no Inventário F.
Este modelo não aborda explicitamente propriedade intelectual ou direitos autorais. Recomenda-se adicionar cláusula declarando que cliente retém direitos sobre conteúdo que forneceu, desenvolvedor retém direitos sobre código e templates customizados, e qualquer conteúdo terceirizado (fontes, ícones, bibliotecas) segue licenças respectivas. Consulte um advogado para proteger ambas as partes.
Este acordo especifica que desenvolvedor retém backup por [NUMERO] dias após cliente aceitar o site. Após este prazo, desenvolvedor destroi todas as cópias do site, a menos que fornecedor hospedagem num acordo separado. Cliente deve fazer download de cópia pessoal dos ficheiros no momento da aceitação para proteção própria.
Este acordo estabelece que site é entregue pronto para funcionar quando colocado num servidor Web com conexões necessárias (domínio, base de dados, SSL). Se cliente tem dificuldade técnica a colocar site em funcionamento, isto é responsabilidade de cliente ou seu provedor de hospedagem, não desenvolvedor. Recomenda-se documentar o servidor-alvo (tipo, versão do PHP, base de dados) no Inventário A para evitar incompatibilidade.
Uma proposta é documento de uma página que lista serviços e preço. Este acordo é contrato legal completo que inclui cronograma, especificações técnicas detalhadas, processo de revisão, penalidades, e mediação de disputa. Use proposta para apresentação inicial; use este acordo quando ambas as partes concordam em proceder e precisam documentação legal que proteja investimento.
Contrato genérico é amplo e pode aplicar-se a vários tipos de serviço. Este modelo é específico a design e desenvolvimento web, com cláusulas especializadas sobre entrega técnica (formato Disco Zip), meta tags, teste de links, e aceitação de site. Use modelo especializado para maior precisão legal e menor necessidade de personalização.
Este acordo cobre design e desenvolvimento inicial. Acordo de manutenção cobre suporte contínuo, atualizações, e correções após lançamento. Muitos projetos requerem ambos; este modelo inclui referência a acordo de hospedagem separado se desenvolvedor fornecerá serviços pós-lançamento. Use ambos se cliente requer suporte duradouro.
Este modelo é específico para website e inclui cláusulas técnicas e de aceitação. Acordo de trabalho por empreitada genérico é aplicável a qualquer projeto (redação, tradução, design gráfico). Se projeto é website, use este modelo; se é outro tipo de trabalho criativo, use empreitada genérica ou adaptação equivalente.
Acordo padrão para formalizar projetos com clientes, proteger cronograma e pagamento, e evitar mudanças de escopo não compensadas.
Documento essencial para projetos de website que acompanham estratégia digital maior; documenta website como deliverable específico com prazos e marcos.
Proporciona estrutura clara para desenvolvimento de plataforma, integração de pagamento, e teste antes de lançamento ao público.
Usado para renovações de website corporativo, necessário para estabelecer presença digital e comunicar à clientela mudanças de identidade.
Acordo acessível que PME podem usar para contratar freelancer ou agência local sem necessidade de advogado, documentando expectativas claras.
Estrutura de pagamento escalonada permite startups com capital limitado a financiar desenvolvimento web sem 100% adiantado, compartilhando risco com desenvolvedor.
No Brasil, contrato de serviços web é regido pelo Código Civil e legislação sobre direitos autorais (Lei 9610/98). Recomenda-se revisar cláusulas de propriedade intelectual e adequar para legislação brasileira, particularmente no que toca a direitos sobre código e conteúdo.
Em Portugal, contrato é regido pelo Código Civil Português. Verifique conformidade com RGPD se website recolhe dados pessoais, e considere adicionar cláusula sobre protecção de dados do cliente. Direitos autorais são automáticos sob Lei do Direito de Autor.
| Caminho | Melhor para | Custo | Tempo |
|---|---|---|---|
| Use o modelo | Projeto web simples (5–10 páginas, funcionalidade básica), entre partes em jurisdição clara, sem requisitos regulatórios especiais. | €0–50 (apenas preço do modelo) | 30–60 minutos para preencher inventários e adaptar prazos |
| Modelo + revisão jurídica | Projeto de complexidade média com múltiplos marcos de pagamento, requisitos técnicos específicos, ou quando cliente é em país diferente. | €250–600 (modelo + consulta jurídica de 1–2 horas) | 2–3 horas (incluindo consulta com advogado) |
| Redigido sob medida | Projeto grande e complexo (ecommerce, integração de sistemas, dados sensíveis), com multijurisdições, ou relação de longo prazo com cláusulas customizadas. | €1000–3000+ (redação de contrato à medida) | 1–2 semanas (incluindo negociaçã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
