Encomendar um site ou uma loja WordPress não é comprar um produto na prateleira, mas entrar numa relação da qual é difícil sair a meio do caminho. A decisão mais importante não tem que ver com o preço nem com o portefólio de quem parece mais bonito, mas sim com aquilo que fica nas suas mãos quando o projeto termina: o acesso, o código e os direitos. Este guia reúne as perguntas que realmente separam um bom prestador dos problemas, e uma área em que quase ninguém pensa até ser tarde demais: o direito.
Agência, freelancer ou equipa interna
É uma escolha de continuidade, não de qualidade. Um freelancer isolado pode ser a melhor escolha técnica e o mais rápido a decidir, mas é também um ponto único de falha. Vimos uma loja parar durante uma semana porque a única pessoa que conhecia o seu código tinha ido para a serra sem rede, e o conhecimento sobre o projeto não estava registado em lado nenhum. Uma equipa interna resolve o problema da continuidade, mas só compensa com uma carga de trabalho constante e elevada; com tarefas irregulares, um posto fixo fica parado e custa na mesma.
Uma agência é o meio-termo: paga um acréscimo pela equipa e pelo processo e, em troca, obtém pessoas substituíveis e documentação, para que o projeto não pare quando uma pessoa sai. O modelo intermédio sensato para a maioria das empresas B2B e das lojas é um engenheiro fixo e identificado do lado do prestador, mas com uma equipa e conhecimento registado por trás. A pergunta de controlo é simples: o que acontece ao meu projeto quando essa pessoa concreta adoece ou sai.
O que observar em vez de um portefólio bonito
Um portefólio mostra como algo aparece numa captura de ecrã, não como funciona sob carga. Três coisas dizem mais do que uma galeria de trabalhos anteriores.
A primeira é o desempenho medido, e não declarado. Peça um resultado do Core Web Vitals a partir de dados de campo, ou de um teste num telemóvel médio com uma ligação mais lenta, e não num portátil com fibra. A metodologia e os limiares são descritos pela equipa da Google na documentação dos Web Vitals. Um bom prestador mostra números antes e depois, explica como lida com page builders pesados e quantas consultas à base de dados gera uma página de produto.
A segunda é a forma como trabalham com o código. Pergunte diretamente se o código está versionado num repositório ou é enviado por FTP diretamente para o servidor. A versionização não é um capricho: é a possibilidade de reverter um erro, auditar alterações e permitir que qualquer outra pessoa assuma o projeto. A falta de repositório significa que fica preso a um único prestador, porque mais ninguém entra nesse código sem arqueologia.
A terceira é a segurança após o lançamento. Um site não é um quadro que se pendura e se esquece; os plugins têm de ser atualizados, e a cadeia de fornecimento dos plugins pode ser um vetor de ataque. Pergunte quem é responsável pelas atualizações após o arranque e como é a resposta a um incidente. A falta de resposta significa que a responsabilidade é sua, só que ainda não o sabe.
Cinco perguntas antes de assinar
Estas cinco perguntas custam um minuto e poupam meses.
- A quem pertencerão os direitos patrimoniais de autor sobre o código e o design quando o projeto terminar, e em que formas de utilização?
- Vou obter acesso administrativo completo ao alojamento, ao domínio, ao repositório e às contas externas, ou trabalhamos na vossa conta fechada?
- O código está versionado e as implementações são reproduzíveis, ou as alterações chegam ao servidor à mão?
- Quem é responsável pelas atualizações, cópias de segurança e segurança após o lançamento, e o que abrange o acompanhamento?
- Vou ver um resultado real de desempenho no telemóvel, ou apenas capturas de ecrã do portefólio?
Se qualquer uma destas perguntas receber uma resposta evasiva, não é uma questão de conhecimento, mas de um modelo de negócio que prende o cliente ao prestador pela força e não pela qualidade.
Direito e propriedade: a área em que ninguém pensa cedo o suficiente
É aqui que começa a parte mais fácil de ignorar e mais difícil de corrigir depois. Ao abrigo da lei polaca, o simples pagamento de um projeto não transfere automaticamente os direitos patrimoniais de autor sobre o código, as imagens ou os textos; é necessária uma cláusula expressa no contrato que indique as formas de utilização. Sem ela, os direitos ficam com o prestador e ao cliente resta apenas uma licença para utilizar aquilo por que pagou. O advogado polaco Tomasz Palak resume-o sem rodeios: como escreve no seu guia sobre direitos de autor para criadores, “ao publicar, não se perdem os direitos”, o que funciona nos dois sentidos, também do lado do prestador, enquanto este não ceder conscientemente os direitos.
A mesma cautela aplica-se aos materiais colocados no site. O facto de uma imagem estar disponível na internet, ou de ter sido gerada por um modelo de IA, não significa que a possa usar comercialmente; é preciso verificar a licença, porque, como recorda Palak, nem toda a “imagem gratuita” é realmente gratuita, e uma licença CC BY não é o mesmo que CC0. Do seu lado, vale a pena assegurar três coisas no contrato:
- A cessão dos direitos patrimoniais de autor sobre o código, o design e os conteúdos, e não apenas uma licença.
- Uma declaração do prestador de que detém os direitos sobre todos os materiais utilizados, imagens, tipos de letra e plugins premium, bem como as respetivas licenças.
- A conformidade com o RGPD se o site recolher dados, ou seja, quem é o responsável pelo tratamento e quem é o subcontratante, e o que acontece aos dados quando a colaboração termina.
Se usar ferramentas de IA para conteúdos ou imagens, lembre-se de uma regra que Palak repete: a ferramenta não retira a sua responsabilidade pelo que publica. Verifique os termos da ferramenta e não introduza dados que não pode divulgar. O mesmo vale para a agência que contrata: vale a pena perguntar se e como usa IA e quem é responsável pelos direitos sobre os resultados.
Bandeiras vermelhas
Alguns sinais perante os quais é melhor agradecer antes de assinar. Um prestador que não quer entregar o acesso ao alojamento, ao domínio e ao código. A ausência de repositório e implementações exclusivamente manuais. Um preço indicado de forma desligada do âmbito, sem análise dos requisitos reais. Promessas de posições no Google ou de “visibilidade na IA” dadas de palavra, sem explicar em que devem consistir. Por fim, o silêncio sobre os direitos de autor, porque isso significa normalmente que os direitos ficam com o prestador e só ficará a saber quando tentar mudar de fornecedor.
O que se segue
Escolher bem um prestador WordPress resume-se a um princípio: assegure aquilo que ficará nas suas mãos quando o projeto terminar, antes de ele começar. O acesso, o código versionado e os direitos cedidos por escrito são mais importantes do que o slide mais bonito da proposta. Se está a planear um site ou uma loja e quer percorrer esta lista num caso concreto, descreva o que o projeto deve entregar e analisamos em conjunto a que deve estar atento na sua situação.
Os aspetos jurídicos deste texto têm caráter geral e não constituem aconselhamento jurídico; num contrato concreto, vale a pena consultar um advogado especializado em direitos de autor e novas tecnologias.
Última atualização: 11 de junho de 2026.
