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.
| Critério | Freelancer | Agência | Equipa interna |
|---|---|---|---|
| Continuidade | Ponto único de falha | Pessoas substituíveis e documentação | Resolvida, mas só com carga constante |
| Modelo de custos | Tarifa mais baixa, disponibilidade irregular | Acréscimo pela equipa e pelo processo | Salário, fica parado com trabalho irregular |
| Velocidade de decisão | A mais rápida | Rápida, através de um engenheiro identificado | Rápida, mas só interna |
| Conhecimento documentado | Muitas vezes nenhum | Registado e pronto para entrega | Depende da equipa |
| Melhor adequação | Tarefas pequenas e bem definidas | A maioria dos sites e lojas B2B | Carga constante e elevada |
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.
Se quiser ir mais fundo antes de assinar, acrescente mais cinco perguntas que custam o mesmo minuto:
- O que acontece exatamente no fim do contrato: em quantos dias úteis recebo os acessos, os ficheiros e a exportação da base de dados, e isso está escrito no contrato ou depende da boa vontade?
- Quais são os tempos de resposta garantidos, e o que conta como incidente crítico: uma loja em baixo num sábado à noite é tratada de forma diferente de um typo numa página?
- Quem executa realmente o trabalho: a equipa interna da agência ou subcontratados, e, se houver subcontratação, quem responde perante mim pelo resultado e pela confidencialidade?
- Como funciona a política de cópias de segurança e de reposição: com que frequência são feitas, onde ficam guardadas (fora do mesmo servidor, espera-se) e quanto tempo demora repor o site depois de uma atualização correr mal?
- Em nome de quem ficam as licenças do page builder, do tema e dos plugins premium: minhas ou da agência?
A décima pergunta parece um pormenor e é das que mais dói mais tarde. Se a licença do Elementor Pro ou de um tema comercial estiver na conta da agência, no dia em que a colaboração termina o site deixa de receber atualizações, e atualizações em falta são a forma mais comum de um WordPress ser comprometido.
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.
Contrato e modelos de faturação
A forma como se paga condiciona a forma como o prestador trabalha, por isso vale a pena perceber o que cada modelo recompensa antes de discutir o valor. Não existe uma resposta universalmente correta, e qualquer agência séria orça o projeto de forma individual a partir dos seus requisitos, mas os incentivos diferem de maneira previsível.
Um preço fixo de projeto compra-lhe certeza de custo e coloca o risco de entrega do lado do prestador. O problema está nas margens: o preço fixo só funciona quando o âmbito está escrito com precisão, e cada alteração vira uma negociação. Se a proposta inclui “revisões ilimitadas” a preço fixo, trate-o como aviso e não como oferta; significa que o âmbito nunca foi definido, e que o prestador conta tornar o modelo rentável cansando-o ou cortando cantos invisíveis, como saltar o ambiente de testes e experimentar em produção.
A faturação por horas é o modelo mais honesto para trabalho exploratório: migrações de sites antigos que ninguém compreende por completo, recuperação após um ataque, integrações com um ERP em que a documentação do outro sistema se revela ficção. O risco de orçamento fica consigo, por isso só funciona com duas salvaguardas no contrato: um teto que aprova antes de ser ultrapassado, e acesso a um registo de trabalho concreto o suficiente para ver o que uma dada hora produziu. Uma agência que resiste a ambos quer faturação horária sem responsabilidade horária. Em lojas portuguesas isto aparece com frequência quando Multibanco ou MB Way entram na equação com faturação eletrónica para a Autoridade Tributária: o número de rondas de teste raramente cabe num âmbito fechado à primeira.
Um retainer, uma mensalidade fixa de cuidado e um cabaz de horas de desenvolvimento, é o que a maioria dos sites realmente precisa depois do lançamento, porque o WordPress não é uma entrega, é um processo: atualizações de core cerca de duas vezes por ano, atualizações de plugins todas as semanas, migrações de versão de PHP no alojamento. O retainer incentiva a agência a manter o site aborrecido e estável, porque os incidentes comem a margem. O que importa é o que a mensalidade cobre por escrito: ritmo de atualizações, frequência e retenção de cópias de segurança, tempo de resposta garantido se o site cair, e se as horas não usadas passam para o mês seguinte. É o modelo por detrás de um serviço típico de manutenção WordPress, e é aí que as perguntas sobre política de atualizações e rollback da checklist acima deixam de ser teóricas.
Qualquer que seja o modelo, o preço em si deve ser individual, construído a partir dos seus requisitos, não lido de um menu. Um orçamento sem conversa de descoberta, sem acesso ao site atual e sem perguntas sobre tráfego e integrações é um orçamento para um projeto que o prestador imaginou, não o seu.
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.
A esta lista juntam-se sinais mais técnicos, que se detetam com uma pergunta simples em cada caso.
A ausência de um ambiente de testes (staging). Se todas as alterações são feitas diretamente no site em produção, cada atualização de plugin é uma roleta com os seus clientes como público. Um prestador sério tem uma cópia de trabalho onde testa antes de publicar, e consegue mostrá-la.
A falta de uma política escrita de atualizações. “Atualizamos quando é preciso” não é uma política, é uma esperança. Pergunte com que frequência os plugins e o core são atualizados, quem verifica o site depois de cada ronda e o que acontece quando uma atualização parte alguma coisa.
Licenças em nome da agência. Como referido acima, um page builder ou tema comercial licenciado na conta do prestador é uma trela: funciona enquanto a relação durar. O mesmo vale para plugins de faturação e de campos personalizados.
O repositório fechado ao cliente. Existir um repositório não chega; o cliente tem de constar dele como proprietário ou, no mínimo, ter acesso de leitura garantido no contrato. Um repositório que só a agência vê protege a agência, não o projeto.
A promessa de “revisões ilimitadas”. Soa generoso e significa o contrário: um âmbito que nunca foi definido. Um projeto sem âmbito fechado não tem critério de conclusão, e um prestador que vive disso é incentivado a prolongar, não a terminar. Prefira um âmbito claro com rondas de revisão definidas e um processo para alterações fora dele.
Como se apresenta uma boa entrega
O fim do projeto é onde é mais fácil distinguir um prestador profissional dos restantes, porque a entrega é custo puro para eles e valor puro para si. Um bom prestador trata-a como parte do entregável e agenda-a; um mau trata-a como um favor. Eis o que significa completo.
O acesso ao repositório vem primeiro: o historial completo transferido para uma organização no GitHub ou no Bitbucket que lhe pertence, não um zip do estado final. O historial importa porque o próximo desenvolvedor WordPress usa-o para perceber por que as coisas foram feitas daquela forma, e porque prova o que foi trabalho à medida versus plugins configurados. Junto com o código deve receber documentação: que plugins são estruturais e porquê, onde vivem as personalizações, como se publica uma alteração, e quaisquer tarefas cron ou serviços externos de que o site depende em silêncio.
As credenciais movem-se por um gestor de palavras-passe ou um cofre adequado, nunca por uma folha de cálculo por e-mail. A lista é mais longa do que a maioria dos clientes espera: administração WordPress, painel de alojamento, registador do domínio, DNS se for gerido à parte (por exemplo na Cloudflare), e-mail transacional, gateways de pagamento e chaves de API das integrações. A propriedade importa mais do que o acesso: o domínio tem de estar registado na sua empresa, e num .pt isso significa figurar como titular junto do DNS.PT através da sua própria conta no registador, não na da agência. A conta de alojamento, seja managed WordPress ou VPS, deve ser sua com a agência adicionada como colaboradora, não o contrário. A maioria dos alojadores tem uma função de transferência de site ou de conta precisamente para este momento; uma agência que já fez entregas sabe onde está esse botão.
Por fim, uma sessão de formação: uma ou duas horas em que a sua equipa edita conteúdos reais em staging, publica uma página e vê onde estão as cópias de segurança e como restaurar uma. Grave-a. Seis meses depois, quando a pessoa que assistiu já mudou de emprego, a gravação é a formação. Se um prestador oferecer tudo isto sem ser pedido, isso diz mais sobre o comportamento a meio do projeto do que qualquer slide de portefólio.
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: 22 de julho de 2026.
