Senior / Lead Frontend Engineer
Construyo frontends de comercio electrónico y las plataformas que los sostienen.
Casi todo mi trabajo reciente está donde el checkout se cruza con pagos, APIs, sistemas de contenido y monitorización. En SumUp trabajo en el flujo con el que los comercios compran lectores de tarjetas y suscripciones, y en el SDK, el servidor MCP y la documentación que otros equipos y agentes de IA usan para trabajar con él.
- TypeScript
- React
- Next.js
- SDKs
- MCP
- OpenTelemetry
Experiencia profesional
18+ años
Ámbito
Producto y plataforma
Foco actual
Comercio fiable
Ubicación
Berlín, Alemania
Proyectos destacados
Tres proyectos de los últimos años
Cada uno cuenta el problema, lo que hice y qué cambió después. He dejado fuera cifras de negocio confidenciales y detalles internos.
Plataforma de comercio · Herramientas de IA
Una sola interfaz al dominio de comercio, para equipos y agentes de IA
Un SDK en TypeScript y un servidor MCP que storefronts, herramientas de ventas y clientes de IA usan para precios, pedidos, suscripciones, presupuestos y contratos.
El problema
La lógica de comercio estaba repartida entre varios servicios, cada uno con su propio modelo de recursos. Cada aplicación necesitaba ese contexto, y copiarlo en todas significaba más errores de integración y más peticiones de soporte para nuestro equipo.
Lo que hice
- Codiseñé el SDK tipado como la capa que agrega esos servicios, para que nadie tenga que saber qué servicio se encarga de qué. Lo seguí ampliando a medida que otros equipos pedían más.
- Añadí un servidor MCP cuyas herramientas declaran si solo leen, añaden datos, los sobrescriben o se pueden repetir sin riesgo.
- Escribí agent skills con evals y guías para el repositorio, para que el conocimiento del dominio viva en archivos versionados que se pueden probar y revisar.
- Medí cada recurso antes de recortar las respuestas a los campos que realmente se usan.
Qué cambió
- Herramientas de ventas internas y de cara al cliente se integran a través del SDK, entre ellas la tienda de la web de marketing.
- Un solo recorte de campos redujo el tamaño de los pedidos en torno a un 93 % y la latencia p50 de un pedido individual en torno a un 11 %.
- Los agentes pueden hacer trabajo real en el dominio, y sus clientes saben qué llamadas necesitan la confirmación de una persona.
Observabilidad · Guardias
Conectar los errores del navegador con la transacción que los causó
Antes, quien estaba de guardia tenía que cuadrar marcas de tiempo entre Sentry y Honeycomb para entender una compra fallida. Ahora puede seguirla desde el navegador hasta las trazas del backend en un solo sitio.
El problema
Al actualizar el SDK de Commerce Layer, su cliente HTTP pasó de XHR a fetch. Nuestra instrumentación del navegador solo cubría XHR, así que las llamadas de autenticación, pedidos y líneas de pedido dejaron de generar spans. Además, los errores del navegador solo llegaban a Sentry, lejos de las trazas del backend que se consultan en las guardias.
Lo que hice
- Añadí instrumentación de fetch con propagación de trazas W3C y atributos de pedido, comercio, idioma y flujo en cada span.
- Envié los errores no capturados, y los errores gestionados en las peticiones de checkout que mide nuestro SLO, al mismo pipeline. Subí source maps para que las trazas de producción sean legibles.
- Filtré el ruido de hidratación y de terceros, puse la captura de errores detrás de su propio flag y cargué el código de trazas de forma diferida para contener el coste y el tamaño del bundle.
- Añadí marcadores de despliegue para poder relacionar un cambio en una gráfica con la versión que lo provocó.
Qué cambió
- Quien está de guardia puede buscar por ID de pedido y ver el error del frontend junto a la traza del backend.
- Las peticiones de autenticación, pedidos y líneas de pedido vuelven a aparecer en las trazas.
Arquitectura · Migración
Cambiar el modelo de datos de producto y el CMS sin que los equipos dejaran de publicar
Una migración por fases de Contentful a Builder.io que abarcó el storefront, el backoffice, los consumidores del SDK y el flujo de trabajo de los editores de contenido.
El problema
Varias aplicaciones y equipos leen los mismos datos de producto. Cambiar el modelo y el CMS de golpe habría atado a todos a la fecha de la migración y habría complicado cualquier rollback.
Lo que hice
- Rediseñé el modelo de producto y planifiqué una secuencia compatible hacia atrás, para que cada consumidor migrara a su ritmo.
- Construí un plugin de Commerce Layer para Builder que guarda instantáneas de producto en el contenido publicado, para que ahí no acaben tokens ni URLs de la API.
- Pasé las comprobaciones de unicidad y exclusión mutua a hooks de validación versionados, para que los editores vean los problemas mientras editan.
- Mantuve ambos proveedores en paralelo durante el despliegue e hice pruebas de carga del plugin antes de quitar el código de transición.
Qué cambió
- El storefront y las herramientas internas migraron sin caídas planificadas.
- Las páginas publicadas ya no dependen de que Commerce Layer esté disponible cuando el CDN las sirve.
Cómo trabajo
Casi todo mi trabajo ocurre entre sistemas
Donde más aporto es cuando el recorrido de un cliente atraviesa varios sistemas y equipos, y alguien tiene que decidir qué sistema es dueño de cada estado y a quién avisan cuando algo se rompe.
Comercio y pagos
Sigo una transacción desde el navegador, pasando por nuestras APIs y el proveedor de pagos, hasta el callback que vuelve.
- Recuperación en checkout y pagos
- Pagos a plazos y suscripciones
- Contratos
- Reglas que cambian según el mercado
Plataformas y herramientas de IA
Construyo SDKs, herramientas MCP y documentación para que otros equipos puedan usar un dominio complejo sin tener que aprenderlo entero antes.
- SDKs en TypeScript
- Servidores MCP
- Agent skills con evals
Fiabilidad y observabilidad
Para mí, la monitorización es parte de entregar una funcionalidad, desde las trazas del navegador hasta el seguimiento de un incidente.
- OpenTelemetry y Honeycomb
- Guardias
Hacer explícitos los contratos
En cada frontera entre equipos o servicios dejo por escrito los estados, los errores y quién se encarga de ellos, para que nadie tenga que deducirlos después.
Contar con los fallos
Los pagos agotan el tiempo de espera y los callbacks llegan tarde. Le dedico al camino de recuperación la misma atención que al camino feliz.
Dejarlo por escrito
La documentación, los tests, los runbooks y las instrucciones para agentes permiten que la siguiente persona, o el siguiente agente, tome la misma decisión sin preguntarme.
Trabajar conmigo
Aviso de los riesgos pronto
Si un plan tiene una dependencia arriesgada o una fecha ajustada, lo digo durante la planificación, cuando todavía se puede cambiar.
Trabajo bien por escrito
Escribo tickets, descripciones de PR y documentación pensando en quien los lea meses después, y trabajo sin problema entre zonas horarias.
Trabajo mejor con un mandato claro
Aporto más cuando me hago cargo de un problema de principio a fin, incluidas las partes que tocan a otros equipos y sistemas. Dime el objetivo y hasta dónde llega mi papel, y yo me encargo del resto.
Me gusta programar en pareja
Disfruto del pair programming y de acompañar a gente nueva. Varios ingenieros se pusieron al día en el equipo a través de sesiones de pairing conmigo.
Experiencia
Dónde he trabajado
Dieciocho años de trabajo web, sobre todo frontend, en analítica, gestión de contenidos, logística y ahora comercio y pagos.
2023-actualidad
Senior Frontend Engineer II
SumUp
Trabajo en la tienda online donde los comercios compran lectores de tarjetas y suscripciones, y en el backoffice de ventas. Detrás de ambos están el SDK, las integraciones con el CMS, la gestión de pagos, la monitorización y las herramientas para desarrolladores en las que también trabajo.
2021-2023
Lead Frontend Engineer
HERE Technologies
Dirigí el frontend de la división de logística: un panel de seguimiento de vehículos en tiempo real con WebSockets, la migración al nuevo sistema de diseño y la contratación e incorporación de un equipo de seis personas. También introduje tests de interfaz con Cypress y seguimiento de embudos con Amplitude.
2019-2021
Senior Frontend Engineer
Doodle
Me moví entre los equipos de Growth, Data y Design System. Arranqué el sistema de diseño en TypeScript, escribí la librería de analítica de frontend que adoptaron seis equipos y ayudé a lanzar la web basada en Contentful.
2007-2019
Frontend & Full-Stack Engineer
Trabajos anteriores
Una herramienta de gestión de anuncios en Delivery Hero y trabajo de frontend en RideLink y Architrave. Antes, unos diez años de proyectos con Plone y Django para portales del gobierno brasileño, universidades y agencias, con algunos clientes en EE. UU., Australia y Alemania.
Herramientas
Con qué trabajo
Donde soy más fuerte es en el frontend. El resto lo uso cuando un problema va más allá del navegador, y en comercio eso pasa mucho.
Frontend
Plataforma y herramientas de IA
Fiabilidad y entrega
Backend e infraestructura
Trayectoria
Cómo llegué hasta aquí
Estudié publicidad, no informática. Llegué al software a través del diseño, de portales del sector público brasileño, de Python y de la comunidad de código abierto de Plone, y sigo apoyándome en esa formación cuando explico sistemas o diseño para quienes los usan.
Formación
Grado en Comunicación Social (Publicidad)
Universidad de São Paulo, 2001-2006
Trabajo final: "Wikipedia: an exploratory study"
Descargar el trabajo (PDF, en portugués)Estudios de artes visuales y audiovisuales
Ministerio de Cultura de Brasil y SENAC, 2007-2012
Charlas destacadas
Plone on React
EuroPython & PyConWeb, 2018
Thinking UX in Multi-Editor Portals
Plone Symposium South America, 2012
Diazo, a new way to theming
PyCon Brazil, 2011
Servicios digitales públicos
Dirigí y construí plataformas de contenido para universidades, bibliotecas, parlamentos e instituciones públicas.
Código abierto
Trabajo en las comunidades de Plone y Python: complementos, correcciones upstream, charlas en conferencias y Clips, una app de Django para programas de conferencias que se usó en la PyCon Brazil y en el FISL.
Idiomas
Portugués (nativo), inglés (C1), alemán (B2) y español (B1). Vivo en Berlín.
Hablemos
Siempre me apetece hablar de arquitectura frontend, sistemas de comercio, observabilidad o del uso de la IA en el día a día de la ingeniería.