Quem faz o trabalho
A WPPoland é um único programador de software sénior, Mariusz Szatkowski, que trabalha na parte web e de e-commerce do software: o código do servidor, as integrações entre sistemas e os front ends que assentam sobre eles. O trabalho gira em torno do WordPress desde 2006 e foi crescendo a partir daí para WooCommerce, TypeScript e Node.js, front ends headless em Astro e Next.js e código na edge em Cloudflare Workers.
É uma definição mais estreita do que “programador de software” em geral, e é intencional. Aqui não há equipa de mobile, nem departamento de design, nem uma bancada de juniores. O que tem é a pessoa que escreve o código, lê o código que já existe e responde por ele.
O que constrói um programador de software web e de e-commerce
A maior parte dos pedidos cabe em cinco tipos de trabalho. Sobrepõem-se, porque os sistemas reais também se sobrepõem.
- Integrações entre sistemas. Uma loja WooCommerce que tem de bater certo com um ERP, com o feed de preços de um grossista, com um programa de contabilidade ou com um armazém. A parte difícil raramente é a chamada à API: é decidir qual dos sistemas é a fonte da verdade para stock, preços e estado das encomendas, e o que acontece quando dois deles discordam às duas da manhã.
- Front ends headless e na edge. Astro ou Next.js sobre WordPress ou WooCommerce, publicados em Cloudflare Workers ou Pages. Compensa quando o modelo de conteúdo é estável e a velocidade ou a segurança pesam mais do que o construtor visual do editor. Não compensa num site institucional que muda duas vezes por ano.
- Engenharia de lojas. Lógica de checkout, integrações de pagamento e de envio (numa loja portuguesa, os exemplos típicos são MB WAY e referências Multibanco), trabalho de desempenho medido com dados reais de utilizadores em vez de uma pontuação de laboratório, e o código de plugins que guarda as regras de negócio da loja.
- Software WordPress à medida. Plugins com um modelo de dados a sério, tarefas em segundo plano, interfaces REST e WP-CLI e ecrãs de administração que os editores conseguem usar sem manual.
- Integrações de IA e MCP. Ligar um site ou uma loja a agentes de IA de forma que seja só de leitura por omissão, registada e reversível. O servidor MCP público para WooCommerce descrito mais abaixo é um exemplo dessa abordagem.
A stack, e onde cada peça se justifica
Uma stack é um conjunto de compromissos, não uma coleção de emblemas. Este é o conjunto de trabalho e a razão de cada peça lá estar.
| Camada | Ferramenta | Escolhida quando | Não escolhida quando |
|---|---|---|---|
| Servidor | PHP 8 sobre WordPress | O sistema precisa de editores, utilizadores, um ecossistema de plugins e alojamento barato | A carga é um serviço de longa duração sem modelo de conteúdo |
| Comércio | WooCommerce | Catálogo, checkout e dados de encomendas têm de ficar na sua própria base de dados | Os limites de uma plataforma alojada são aceitáveis e ninguém quer gerir servidores |
| Scripts e serviços | TypeScript em Node.js | Workers de integração, ferramentas de linha de comandos, servidores MCP, tudo o que tenha um contrato tipado | Uma tarefa de dez linhas que o WP-CLI já resolve |
| Serviços de dados | Kotlin e Spring Boot | Importações de longa duração e resolução de identidades sobre milhões de registos, com fila e modelo de domínio tipado | A equipa do cliente só mantém PHP |
| IA local | Ollama via Spring AI | Classificação em que os dados do cliente nunca podem sair das suas instalações | Uma tarefa que regras simples ou uma tabela de consulta já resolvem |
| Front end | Astro | Páginas com muito conteúdo, em que a maior parte da página é estática | A interface é uma aplicação densa e com estado |
| Front end | Next.js | Front ends do tipo aplicação, com muito estado no cliente | O site é sobretudo documentos |
| Edge | Cloudflare Workers e Pages | Cache, redirecionamentos, pequenas APIs e builds estáticos perto do visitante | A tarefa precisa de uma ligação à base de dados aberta durante minutos |
| Ferramentas | Python | Verificações de dados, análise de documentos, migrações pontuais | Qualquer coisa que a equipa do cliente vá manter em PHP |
A linguagem importa menos do que as fronteiras. Um bom software, aqui, é aquele em que se consegue dizer que sistema é dono de que dados, que código corre onde e como desfazer o lançamento da terça-feira passada.
Provas públicas que pode verificar antes de escrever
Afirmações sobre competência saem baratas. Estas podem ser verificadas sem uma chamada.
- wppoland/woocommerce-mcp: um servidor Model Context Protocol só de leitura para WordPress e WooCommerce, escrito em TypeScript, licença MIT. Expõe cinco ferramentas (produtos, um produto individual, encomendas, um relatório de vendas e pesquisa de artigos públicos) e nada que possa alterar a loja. A decisão de ser só de leitura por omissão é a que vale a pena examinar.
- wppoland/hidden-text-detector: uma ferramenta em Python que deteta texto oculto e prompt injection em ficheiros PDF e DOCX, como texto branco sobre branco, letra demasiado pequena para ler, texto colocado fora da página e caracteres Unicode invisíveis. Existe porque contratos e pedidos de orçamento chegam agora com instruções dirigidas a um leitor de IA e não a um humano.
- O Plogins e o perfil motylanogha no wordpress.org: o Plogins é um conjunto de 45 extensões para WooCommerce, com versão gratuita e versão pro, desenvolvido em PHP 8.1 com PHPStan, PHPCS e lançamentos automáticos para o wordpress.org e o Freemius. 21 plugins do diretório oficial listam este perfil (verificado a 26 de setembro de 2026), entre eles o plugin de localização de lojas para o mercado polaco Polski (GPSR, Omnibus, RGPD) e o plugin de eventos comunitários GatherPress.
- Este website. O wppoland.com é um build em Astro 7 no Cloudflare Pages, com seis idiomas e cerca de 13 600 páginas pré-renderizadas. Cada alteração passa por cerca de cinquenta verificações automáticas de qualidade antes de ser publicada, desde links partidos e conflitos de schema até uma verificação do sitemap que falha quando uma página marcada para indexação não consta de nenhum sitemap. A minificação do HTML passou para worker threads em setembro de 2026 e baixou de 910 segundos para 199 segundos nos mesmos 13 610 ficheiros, com resultado idêntico byte a byte.
Percurso profissional
Vinte anos de trabalho na web, a maior parte dentro de sistemas de outras pessoas. As funções abaixo são públicas no LinkedIn; os nomes dos clientes dentro desses trabalhos mantêm-se confidenciais.
| Período | Função | Em que consistiu |
|---|---|---|
| Desde out. 2025 | Engenheiro full-stack (contrato), WP-Stars, Viena | Uma plataforma de media e comércio por subscrição: um monorepo Composer que descreve toda a aplicação WordPress, CI com duas barreiras de lançamento independentes, fluxos de subscrição com Stripe e um serviço em Kotlin e Spring Boot que consolida dados do ERP, do CleverReach e de moradas no Mautic, com um LLM local (Ollama via Spring AI) como classificador restrito, a correr on-premise sobre milhões de registos |
| Desde out. 2025 | Coorganizador, CMSConf, Gdynia | Uma conferência sobre sistemas de gestão de conteúdos, organizada presencialmente em Gdynia |
| Desde jan. 2021 | Programador WordPress, WooCommerce e PHP (contrato), Equiqo, Berlim | Desenvolvimento à medida em WordPress, WooCommerce, HubSpot e Shopify sobre a stack Roots (Bedrock, Sage), trabalho de desempenho e dados estruturados |
| 2020 | Programador WordPress, Itineris, Ipswich (Reino Unido) | WordPress à medida sobre Sage e Bedrock, CircleCI, desempenho e SEO |
| 2019 a 2020 | Programador WordPress (freelancer), what., Zurique | WordPress à medida, desempenho e dados estruturados |
| 2016 a 2019 | Programador WordPress e piloto de equipa, AirHelp | Trabalho multilingue, AMP e de desempenho num site de consumo com muito tráfego, ligação entre departamentos |
| 2007 a 2015 | Web developer e especialista em marketing na internet, Vector Group, Gdynia | Desenvolvimento web, sites de comércio B2B e marketing em motores de busca |
| Desde 2007 | WPPoland | A marca sob a qual decorre todo o trabalho independente |
Projetos típicos
O trabalho para clientes está sob NDA, por isso os estudos de caso são anonimizados e dizem-no. Cada um descreve o problema, a abordagem e o que foi e não foi possível medir.
- Uma loja WooCommerce lenta de um vendedor B2B, recuperada através da análise do checkout e da base de dados, em vez de mais um plugin de cache: recuperação de desempenho WooCommerce.
- Uma organização de língua alemã a migrar de TYPO3 para WordPress sem perder a estrutura de URLs nem os hábitos dos editores: migração de TYPO3 para WordPress.
- Uma editora a ligar o seu fluxo editorial a agentes de IA através de um servidor MCP controlado: servidor MCP para um fluxo editorial.
- Um build WooCommerce headless no Cloudflare, preparado para compras feitas por agentes: WooCommerce headless no Cloudflare.
- Um plano de migração por escrito para passar um site WordPress para um front end headless, incluindo as partes que devem ficar como estão: plano de migração headless.
- Uma integração de operações de conteúdo com IA, com revisão humana em cada passo: integração de operações de conteúdo com IA.
Para o detalhe de cada tecnologia, as páginas de serviço vão mais fundo: desenvolvedor WordPress, desenvolvedor de WooCommerce, programador PHP, desenvolvedor Astro, desenvolvedor Next.js, Cloudflare edge e desenvolvimento de servidores MCP.
Freelancer, agência ou software house
A resposta honesta depende da dimensão do problema e do que acontece depois do lançamento. Um único programador sénior nem sempre é a escolha certa.
| Situação | Freelancer sénior | Agência | Software house |
|---|---|---|---|
| Uma integração ou um resgate com um responsável claro do seu lado | Boa escolha: uma pessoa segura o problema inteiro | Muitas vezes mais lenta a arrancar | Normalmente pesada demais |
| Um produto novo que precisa de design, front end e back end ao mesmo tempo | Só com o seu próprio designer | Boa escolha | Boa escolha |
| Seis ou mais programadores necessários no prazo de um mês | Não serve | Possível | Boa escolha |
| Manutenção a longo prazo de um sistema WordPress ou WooCommerce | Boa escolha, com um plano de continuidade por escrito | Boa escolha | Raramente é o foco |
| Uma aplicação móvel | Aqui não serve | Depende da agência | Boa escolha |
| Precisa de falar com quem escreveu o código | Sempre | Às vezes | Raramente |
O risco real com um freelancer é a continuidade: doença, férias ou o dia em que deixa de responder. Peça que isso fique resolvido por escrito. Aqui, isso significa código no seu repositório desde o primeiro commit, documentação ao lado do código, credenciais na sua posse e um procedimento de passagem que outro programador consiga seguir.
Como avaliar qualquer programador de software
Seja quem for que contrate, estas perguntas separam quem entrega de quem só apresenta.
- Onde fica o código? Deve estar no seu repositório, na sua organização, desde o primeiro dia. Um programador que guarda o código até a fatura estar paga está a mantê-lo como refém.
- Como é testada uma alteração antes de chegar à produção? Procure um ambiente de staging, verificações automáticas e uma pessoa identificada que aprova os lançamentos. “Testo no site em produção” é um sinal de alarme.
- Como se desfaz um lançamento? Peça o caminho de reversão, não o de lançamento. Qualquer pessoa consegue publicar; poucas ensaiaram voltar atrás.
- O que foi medido antes de o trabalho começar? Afirmações sobre desempenho, taxas de erro e conversão não valem nada sem um ponto de partida medido da mesma forma.
- O que não vai fazer? Um programador sem limites declarados ou nunca pensou neles, ou vai descobri-los à custa do seu orçamento.
- Posso ler algo que tenha escrito? Código público, um artigo técnico ou um documento de design. O estilo nota-se depressa: se o autor aponta os compromissos ou só as vantagens.
Trabalhar em código escrito por outra pessoa
A maioria dos projetos começa dentro de um sistema existente, não num repositório vazio. A primeira semana é para ler, não para reescrever.
- Mapear antes de mexer. Que plugins e serviços guardam lógica de negócio, que tarefas cron e webhooks correm, que dados vivem fora da base de dados (ficheiros, caches, painéis de terceiros). O mapa entra no repositório como um documento curto.
- Reproduzir o problema numa cópia. Uma cópia em staging com dados próximos dos de produção, anonimizados quando contêm registos de clientes, para que uma correção possa ser provada antes de ser publicada.
- Manter o que funciona. Reescrever é a forma mais cara de corrigir um sistema e a mais fácil de recomendar. Código feio mas correto e coberto por um teste fica; código errado é substituído em passos pequenos e fáceis de rever.
- Deixar tudo mais legível. Cada alteração leva o contexto de que um estranho precisaria: porque foi feita, o que foi medido e como a desfazer.
A mesma regra vale no sentido inverso. Se outro programador herdar o trabalho mais tarde, deve conseguir continuar a partir da documentação no repositório sem ter de telefonar a ninguém.
Segurança e os dados que entrega
Um programador com acesso aos seus servidores e bases de dados representa um risco real, por isso o tratamento é acordado por escrito antes de qualquer acesso.
- As credenciais continuam a ser suas. O acesso é criado por pessoa nos seus sistemas e revogado no fim do projeto; nada de palavras-passe de administrador partilhadas por email.
- Os dados de produção só são copiados quando é necessário, guardados cifrados no computador do programador, anonimizados para staging quando contêm dados pessoais e apagados quando o trabalho termina. À luz do RGPD, isto é tratamento de dados por conta do cliente, por isso um acordo de subcontratação (o contrato de tratamento de dados previsto no artigo 28.º do RGPD) faz parte da documentação desde o início, não é um pormenor para depois. Em Portugal, a autoridade de controlo é a CNPD.
- As alterações em produção são rastreáveis. Cada lançamento corresponde a um commit, e cada commit a um motivo.
- Os documentos recebidos são verificados. Contratos e pedidos de orçamento são analisados em busca de texto oculto e prompt injection antes de alguém, humano ou IA, agir com base neles. É para isso que serve o hidden-text-detector referido acima.
Como decorre um projeto
O processo está escrito para que ninguém tenha de se lembrar dele.
- Pedido por escrito. O sistema, o problema, o prazo, os repositórios e o alojamento existentes e quem decide do seu lado.
- Âmbito com pressupostos. O que está incluído, o que está excluído e o que tem de se verificar para a estimativa se manter. Design, wireframes e conteúdos vêm do cliente e ficam assinalados como tal.
- Ponto de partida. Acessos, uma cópia em staging e medições antes de qualquer alteração, para que “melhor” tenha um número associado.
- Iterações semanais. Commits que pode rever, uma demonstração em staging todas as semanas e decisões registadas no repositório, e não numa conversa de chat.
- Lançamento e passagem de testemunho. Uma reversão ensaiada, documentação e, se a sua equipa assumir o sistema, uma sessão de passagem com a pessoa que escreveu o código.
As condições de pagamento fazem parte do âmbito escrito, com datas concretas em vez de “no fim do projeto”. O trabalho começa quando o adiantamento acordado estiver recebido.
O que não está na oferta
Ser claro sobre os limites poupa um mês a ambas as partes.
- Design gráfico, wireframes e design de UX. O layout é fornecido pelo cliente, muitas vezes numa folha de cálculo simples que indica que elementos entram em cada vista. O trabalho é implementá-lo numa interface funcional e responsiva.
- Aplicações móveis nativas. iOS e Android são outra disciplina e ficam mais bem entregues a um especialista.
- Suporte de piquete 24/7. Monitorização e resposta rápida em horário de trabalho, sim; um alarme às três da manhã, não.
- Fingir ser uma equipa. Uma pessoa significa uma agenda. Grandes cargas de trabalho em paralelo são para uma agência ou uma software house.
Onde o trabalho acontece
Em Gdynia, na costa báltica da Polónia, na hora da Europa Central. Os clientes estão sobretudo na Polónia, na Alemanha, na Áustria, na Suíça, nos países nórdicos e no resto da UE, e o trabalho é remoto, com demonstrações semanais. Fora do trabalho com clientes, o Mariusz faz parte da equipa organizadora do WordCamp Europe desde 2024, na área de orçamento, nas edições de 2025 em Basileia e de 2026 em Cracóvia, e é coorganizador da CMSConf em Gdynia.
Se o seu problema é um sistema web ou de e-commerce que tem de funcionar de forma fiável e ser compreendido pela próxima pessoa que o abrir, descreva-o por escrito. Uma resposta com perguntas ou um primeiro âmbito chega normalmente no prazo de um dia útil. Mais contexto na página sobre mim.
