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.
Que stack tecnológica usar em projetos web e de e-commerce?
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 em massa de longa duração e envios para um sistema de marketing, com fila, novas tentativas e modelo de domínio tipado | A equipa do cliente só mantém PHP |
| 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.
Código público e plugins WordPress para verificar
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), agência digital de 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. Trabalho próprio nesse serviço: importação de linhas de faturas de subscrição (cerca de 100 000 na última medição) e envio para o Mautic em blocos, um backfill supervisionado, tratamento de falhas com novas tentativas perante erros transitórios do Mautic e runbooks |
| 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 2006 | WPPoland | A marca sob a qual decorre todo o trabalho independente |
Casos de estudo de desenvolvimento de software
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.
Contratar 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.
Agências e empresas que constroem um produto e procuram um parceiro técnico estável encontram três modelos de colaboração na página de parcerias.
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.
Como assumir código de outro programador
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 de dados e RGPD ao contratar um programador
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 de software?
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á incluído no serviço
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 está sediado o programador?
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.
