Checklist para um contrato de desenvolvimento web
A maioria dos litígios em projetos de sites não é sobre qualidade mas sobre expectativas que nunca foram escritas. Um contrato que nomeia as coisas certas evita praticamente todos eles, e demora uma hora a ler.
Este guia cobre o que deve constar, porque existe cada ponto, e as cláusulas em que deve insistir na dúvida.
Âmbito: a parte que causa mais litígios#
«Construir o site» não é âmbito. Isto é o que deve estar explícito.
- Número de modelos únicos, não número de páginas. Cinquenta páginas em quatro modelos é um projeto pequeno.
- O que está incluído: desenho, construção, introdução de conteúdo, migração, integrações, testes.
- O que não está incluído — esta é a frase mais importante do contrato inteiro.
- Quem escreve os textos e quem fornece as fotografias.
- Número de rondas de desenho e o que conta como uma ronda.
- Navegadores e dispositivos suportados, e o nível de acessibilidade assumido.
- Objetivos de desempenho, se forem importantes, expressos em valores mensuráveis.
- Que idiomas, e quem fornece as traduções.
Um fornecedor que escreve por iniciativa própria o que não está incluído é normalmente um fornecedor que já passou por um litígio de âmbito — o que é bom sinal.
Propriedade, acessos e saída#
Estes pontos parecem abstratos até querer mudar de fornecedor, e nessa altura são os únicos que contam.
| Ponto | O que o contrato deve dizer |
|---|---|
| Código-fonte | Passa integralmente para si com o pagamento final |
| Ficheiros de desenho | Também seus, incluindo os ficheiros de origem |
| Domínio | Registado em nome da sua empresa, com o seu acesso |
| Alojamento | Na sua conta, ou transferível a pedido |
| Contas de terceiros | Análise, e-mail, pagamentos — em seu nome |
| Licenças de terceiros | Quais são, e quem as paga depois |
| Transição | Documentação e entrega de acessos ao terminar |
| Uso em portefólio | Podem mostrar; é razoável permitir |
Domínio e alojamento em nome do fornecedor é a forma mais comum de as empresas ficarem presas. Verifique isso antes de assinar, não ao sair.
Pagamento, prazos e alterações#
Estes três ligam-se: quem paga quando, o que define a data, e o que acontece se o âmbito crescer.
- Pagamento por fases ligado a entregas, não a datas de calendário.
- Um adiantamento é normal; pagamento integral antecipado não é.
- Uma parcela final após a entrega, suficientemente relevante para ter significado.
- Dependências mútuas: o prazo desliza se você entregar textos tarde, e isso deve constar.
- Um procedimento de alteração: cada acréscimo recebe estimativa escrita antes de começar.
- Preço à hora para trabalho fora do âmbito, definido à partida.
- O que acontece em caso de atraso de ambos os lados — não apenas do seu.
- Condições de rescisão: como se termina e o que é pago e transferido nesse caso.
Garantia, manutenção e responsabilidade#
A parte que trata do período depois do lançamento, e a que mais frequentemente falta.
| Ponto | Acordo razoável |
|---|---|
| Período de correção | Trinta a noventa dias sem custo |
| O que é um erro | Não funciona como acordado — não: pedido novo |
| Tempo de resposta | Dias úteis para o normal, mais rápido em avaria |
| Manutenção | Contrato separado, com lista explícita |
| Vulnerabilidades de segurança | Quem corrige, em que prazo |
| Dados pessoais | Contrato de subcontratação se tratarem dados |
| Responsabilidade | Limitada ao valor do contrato é habitual |
| Litígios | Que lei, que foro — curto mas presente |
A distinção entre «erro» e «pedido novo» é o que causa mais atrito depois do lançamento. Uma frase que a define poupa meses de discussão.
Perguntas frequentes
Preciso de contrato num projeto pequeno?
Sim, ainda que curto. Duas páginas que fixem âmbito, preço, momentos de pagamento, propriedade e o que fica de fora cobrem a maior parte do que corre mal. Os projetos pequenos são precisamente aqueles em que ninguém escreve nada e em que o âmbito duplica sem que se dê por isso.
E se o fornecedor quiser manter a propriedade do código?
É motivo para perguntar mais. Em código à medida, o código deve ser seu depois de pago. A exceção é uma plataforma ou framework próprio do fornecedor — nesse caso recebe uma licença em vez de propriedade, o que pode ser razoável, desde que o contrato diga o que acontece se sair ou se eles fecharem.
Quanto devo pagar adiantado?
Um adiantamento de um quarto a um terço é habitual e razoável. Pagamento integral antecipado não é, porque remove qualquer incentivo para terminar. Ligue o restante a entregas que consiga ver — desenho aprovado, construção entregue, site no ar — em vez de a datas de calendário que podem deslizar.
O que deve cobrir a garantia?
Defeitos naquilo que foi entregue: coisas que não funcionam como acordado. Não: pedidos novos, alterações provocadas por atualizações de navegador meses depois, ou problemas causados por alterações suas. Trinta a noventa dias é o habitual. Garanta que o contrato define o que é um erro, ou discutirá isso no pior momento possível.
contrato desenvolvimento webcontrato websiteâmbito projetopropriedade código-fonteadjudicação sitegarantia site
