Senior / Lead Frontend Engineer
Construo frontends de e-commerce e as plataformas por trás deles.
Quase todo o meu trabalho recente fica onde o checkout encontra pagamentos, APIs, sistemas de conteúdo e monitoramento. Na SumUp, trabalho no fluxo de compra que lojistas usam para comprar maquininhas e assinaturas, e no SDK, no servidor MCP e na documentação que outros times e agentes de IA usam para trabalhar com ele.
- TypeScript
- React
- Next.js
- SDKs
- MCP
- OpenTelemetry
Experiência profissional
18+ anos
Atuação
Produto e plataforma
Foco atual
Confiabilidade no e-commerce
Moro em
Berlim, Alemanha
Projetos selecionados
Três projetos dos últimos anos
Cada um conta o problema, o que eu fiz e o que mudou depois. Deixei de fora números de negócio confidenciais e detalhes internos.
Plataforma de e-commerce · Ferramentas de IA
Uma única interface para o domínio de e-commerce, para times e agentes de IA
Um SDK em TypeScript e um servidor MCP que storefronts, ferramentas de vendas e clientes de IA usam para preços, pedidos, assinaturas, cotações e contratos.
O problema
A lógica de e-commerce estava espalhada por vários serviços, cada um com seu próprio modelo de recursos. Toda aplicação precisava desse contexto, e copiá-lo em cada uma significava mais bugs de integração e mais pedidos de suporte para o nosso time.
O que eu fiz
- Coprojetei o SDK tipado como a camada que agrega esses serviços, para que ninguém precise saber qual serviço cuida do quê. Continuei expandindo o SDK conforme outros times pediam mais.
- Adicionei um servidor MCP cujas ferramentas declaram se só leem, adicionam dados, sobrescrevem ou podem ser repetidas com segurança.
- Escrevi agent skills com evals e orientações para o repositório, para que o conhecimento do domínio fique em arquivos versionados que podem ser testados e revisados.
- Fiz benchmark de cada recurso antes de reduzir as respostas aos campos que de fato são usados.
O que mudou
- Ferramentas de vendas internas e voltadas ao cliente se integram pelo SDK, incluindo a loja do site de marketing.
- Uma única redução de campos cortou o payload dos pedidos em cerca de 93% e a latência p50 de um pedido individual em cerca de 11%.
- Agentes conseguem fazer trabalho de verdade no domínio, e seus clientes sabem quais chamadas precisam da confirmação de uma pessoa.
Observabilidade · Plantão
Ligando falhas no navegador à transação que as causou
Antes, quem estava de plantão precisava alinhar timestamps entre o Sentry e o Honeycomb para entender uma compra que falhou. Agora dá para acompanhá-la do navegador até os traces do backend em um só lugar.
O problema
A atualização do SDK da Commerce Layer trocou o cliente HTTP de XHR para fetch. Nossa instrumentação no navegador só cobria XHR, então as chamadas de autenticação, pedidos e itens do pedido pararam de gerar spans. Além disso, os erros do navegador iam só para o Sentry, longe dos traces do backend que o plantão consulta.
O que eu fiz
- Adicionei instrumentação de fetch com propagação de traces W3C e atributos de pedido, lojista, idioma e fluxo em cada span.
- Mandei os erros não tratados, e os erros tratados nas requisições de checkout que o nosso SLO acompanha, para o mesmo pipeline. Subi source maps para que os stack traces de produção fiquem legíveis.
- Filtrei o ruído de hidratação e de terceiros, coloquei a captura de erros atrás de uma flag própria e carreguei o código de tracing sob demanda para segurar o custo e o tamanho do bundle.
- Adicionei marcadores de deploy, para que uma mudança num gráfico possa ser ligada à versão que a causou.
O que mudou
- Quem está de plantão consegue buscar pelo ID do pedido e ver o erro do frontend ao lado do trace do backend.
- Requisições de autenticação, pedidos e itens do pedido voltaram a aparecer nos traces.
Arquitetura · Migração
Trocando o modelo de dados de produto e o CMS sem os times pararem de entregar
Uma migração em etapas do Contentful para o Builder.io, passando pelo storefront, pelo backoffice, pelos consumidores do SDK e pelo fluxo de trabalho dos editores de conteúdo.
O problema
Vários apps e times leem os mesmos dados de produto. Trocar o modelo e o CMS de uma vez só teria amarrado todo mundo à data da migração e dificultado qualquer rollback.
O que eu fiz
- Redesenhei o modelo de produto e planejei uma sequência retrocompatível, para que cada consumidor migrasse no seu próprio ritmo.
- Construí um plugin da Commerce Layer para o Builder que salva snapshots de produto no conteúdo publicado, para que tokens e URLs da API não parem ali.
- Levei as validações de unicidade e exclusão mútua para hooks versionados, para que os editores vejam os problemas enquanto editam.
- Mantive os dois provedores rodando em paralelo durante o rollout e fiz testes de carga no plugin antes de remover o código de transição.
O que mudou
- O storefront e as ferramentas internas migraram sem downtime planejado.
- As páginas publicadas não dependem mais da Commerce Layer estar no ar quando o CDN as entrega.
Como eu trabalho
Quase todo o meu trabalho acontece entre sistemas
Rendo mais quando a jornada de um cliente atravessa vários sistemas e times, e alguém precisa decidir qual sistema é dono de qual estado e quem é acionado quando algo quebra.
E-commerce e pagamentos
Acompanho uma transação do navegador, passando pelas nossas APIs e pelo provedor de pagamento, até o callback que volta.
- Recuperação no checkout e no pagamento
- Parcelamento e assinaturas
- Contratos
- Regras que mudam por mercado
Plataformas e ferramentas de IA
Construo SDKs, ferramentas MCP e documentação para que outros times usem um domínio complexo sem precisar aprender tudo antes.
- SDKs em TypeScript
- Servidores MCP
- Agent skills com evals
Confiabilidade e observabilidade
Para mim, monitoramento faz parte de entregar uma funcionalidade, do tracing no navegador ao acompanhamento de um incidente.
- OpenTelemetry e Honeycomb
- Plantão
Deixar os contratos explícitos
Em cada fronteira entre times ou serviços, escrevo os estados, os erros e quem é responsável por eles, para que ninguém precise fazer engenharia reversa depois.
Contar com a falha
Pagamentos estouram o tempo limite e callbacks chegam atrasados. Dou ao caminho de recuperação a mesma atenção que ao caminho feliz.
Deixar escrito
Documentação, testes, runbooks e instruções para agentes deixam a próxima pessoa, ou o próximo agente, tomar a mesma decisão sem precisar me perguntar.
Trabalhando comigo
Aponto riscos cedo
Se um plano tem uma dependência arriscada ou um prazo apertado, eu falo isso no planejamento, enquanto ainda dá para mudar.
Trabalho bem por escrito
Escrevo tickets, descrições de PR e documentação pensando em quem vai ler meses depois, e trabalho tranquilo entre fusos horários.
Trabalho melhor com um mandato claro
Contribuo mais quando sou dono de um problema de ponta a ponta, incluindo as partes que esbarram em outros times e sistemas. Me diga o objetivo e até onde vai o meu papel, que eu cuido do resto.
Gosto de pair programming
Curto parear e ajudar no onboarding. Várias pessoas do time pegaram o ritmo por meio de sessões de pareamento comigo.
Experiência
Onde trabalhei
Dezoito anos de trabalho com web, principalmente frontend, em analytics, gestão de conteúdo, logística e agora e-commerce e pagamentos.
2023-atual
Senior Frontend Engineer II
SumUp
Trabalho na loja online onde lojistas compram maquininhas e assinaturas, e no backoffice de vendas. Por trás dos dois estão o SDK, as integrações com o CMS, o processamento de pagamentos, o monitoramento e as ferramentas de desenvolvimento em que também trabalho.
2021-2023
Lead Frontend Engineer
HERE Technologies
Liderei o frontend da divisão de logística: um painel de rastreamento de veículos em tempo real via WebSockets, a migração para o novo design system e a contratação e o onboarding de um time de seis pessoas. Também implantei testes de UI com Cypress e rastreamento de funil com Amplitude.
2019-2021
Senior Frontend Engineer
Doodle
Circulei entre os times de Growth, Data e Design System. Comecei o design system em TypeScript, escrevi a biblioteca de analytics de frontend adotada por seis times e ajudei a lançar o site baseado em Contentful.
2007-2019
Frontend & Full-Stack Engineer
Trabalhos anteriores
Uma ferramenta de gestão de anúncios na Delivery Hero e trabalho de frontend na RideLink e na Architrave. Antes disso, cerca de dez anos de projetos com Plone e Django para portais do governo brasileiro, universidades e agências, além de alguns clientes nos EUA, na Austrália e na Alemanha.
Ferramentas
Com o que eu trabalho
Frontend é onde eu sou mais forte. O resto eu uso quando um problema vai além do navegador, o que no e-commerce acontece bastante.
Frontend
Plataforma e ferramentas de IA
Confiabilidade e entrega
Backend e infraestrutura
Trajetória
Como cheguei aqui
Estudei publicidade, não ciência da computação. Cheguei ao software pelo design, por portais do setor público brasileiro, pelo Python e pela comunidade open source do Plone, e ainda me apoio nessa bagagem quando explico sistemas ou projeto para as pessoas que vão usá-los.
Formação
Bacharelado em Comunicação Social (Publicidade e Propaganda)
Universidade de São Paulo, 2001-2006
TCC: "Wikipédia: um estudo exploratório"
Baixar o TCC (PDF)Estudos em artes visuais e audiovisual
Ministério da Cultura e SENAC, 2007-2012
Palestras selecionadas
Plone on React
EuroPython & PyConWeb, 2018
Thinking UX in Multi-Editor Portals
Plone Symposium South America, 2012
Diazo, a new way to theming
PyCon Brasil, 2011
Serviços digitais públicos
Liderei e construí plataformas de conteúdo para universidades, bibliotecas, casas legislativas e instituições do governo.
Open source
Atuação nas comunidades Plone e Python: add-ons, correções upstream, palestras em conferências e o Clips, um app em Django para programação de eventos usado na PyCon Brasil e no FISL.
Idiomas
Português (nativo), inglês (C1), alemão (B2) e espanhol (B1). Moro em Berlim.
Vamos conversar
Sempre topo uma conversa sobre arquitetura de frontend, sistemas de e-commerce, observabilidade ou uso de IA no dia a dia da engenharia.