Senior / Lead Frontend Engineer
I build commerce frontends and the platforms under them.
Most of my recent work sits where checkout meets payments, APIs, content systems, and monitoring. At SumUp I work on the purchase flow merchants use to buy card readers and subscriptions, and on the SDK, MCP server, and docs that other teams and AI agents use to work with it.
- TypeScript
- React
- Next.js
- SDKs
- MCP
- OpenTelemetry
Professional practice
18+ years
Works across
Product and platform
Current focus
Commerce reliability
Based in
Berlin, Germany
Selected work
Three projects from the last few years
Each one covers the problem, what I did about it, and what changed afterwards. I left out confidential business figures and internal details.
Commerce platform · AI tooling
One interface to the commerce domain, for teams and AI agents
A TypeScript SDK and MCP server that storefronts, sales tools, and AI clients use for pricing, orders, subscriptions, quotes, and contracts.
The problem
Commerce behavior was spread across several services, each with its own resource model. Every consumer needed that context, and copying it into each app meant more integration bugs and more support requests for our team.
What I did
- Co-designed the typed SDK as the layer that aggregates those services, so consumers don't need to know which service owns what. I kept extending it as other teams asked for more.
- Added an MCP server whose tools declare whether they only read, add data, overwrite it, or can safely be repeated.
- Wrote agent skills with evals, plus repository guidance, so domain knowledge lives in versioned files that can be tested and reviewed.
- Benchmarked each resource before trimming responses down to the fields consumers use.
What changed
- Customer-facing and internal sales tools integrate through the SDK, including the shop on the marketing website.
- One field-trimming change cut order payloads by about 93% and single-order p50 latency by about 11%.
- Agents can do real work in the domain, and their clients know which tool calls need a human to confirm.
Observability · On-call
Connecting browser failures to the transaction that produced them
On-call used to line up timestamps between Sentry and Honeycomb to understand a failed purchase. Now they can follow it from the browser into the backend traces in one place.
The problem
Upgrading the Commerce Layer SDK switched its HTTP client from XHR to fetch. Our browser instrumentation only covered XHR, so auth, order, and line-item calls stopped producing spans. Browser exceptions also went only to Sentry, away from the backend traces on-call reads.
What I did
- Added fetch instrumentation with W3C trace propagation, and attached order, merchant, locale, and flow attributes to each span.
- Sent uncaught errors, plus handled errors on the checkout requests our SLO tracks, into the same pipeline. Uploaded source maps so production stacks are readable.
- Filtered out hydration and third-party noise, put error capture behind its own flag, and loaded the tracing code lazily to keep cost and bundle size down.
- Added deployment markers, so a change on a graph can be matched to the release that caused it.
What changed
- On-call can search by order ID and see the frontend exception next to the backend trace.
- Auth, order, and line-item requests show up in traces again.
Architecture · Migration
Replacing the product data model and CMS while teams kept shipping
A staged move from Contentful to Builder.io across the storefront, the backoffice, SDK consumers, and the content editors' workflow.
The problem
Several apps and teams read the same product data. Swapping the model and the CMS in one cut-over would have tied every consumer to the migration date and made rollback hard.
What I did
- Redesigned the product model and planned a backward-compatible sequence, so each consumer could move on its own schedule.
- Built a Commerce Layer plugin for Builder that stores product snapshots in published content, so no tokens or API URLs end up there.
- Moved uniqueness and mutual-exclusivity checks into source-controlled validation hooks, so editors see problems while they edit.
- Ran both providers side by side during the rollout and load-tested the plugin before removing the transitional code.
What changed
- The storefront and internal tools moved over with no planned downtime.
- Published pages no longer depend on Commerce Layer being up when the CDN serves them.
How I work
Most of my work happens between systems
I do my best work when a customer journey crosses several systems and teams, and someone has to decide which system owns which state, and who gets paged when it breaks.
Commerce & payments
I follow a transaction from the browser through our APIs, the payment provider, and whatever callback comes back.
- Checkout and payment recovery
- Installments and subscriptions
- Contracts
- Rules that differ per market
Platforms & AI tooling
I build SDKs, MCP tools, and docs so other teams can use a complicated domain without learning all of it first.
- TypeScript SDKs
- MCP servers
- Agent skills with evals
Reliability & observability
I count monitoring as part of shipping a feature, from browser tracing to the incident follow-up.
- OpenTelemetry and Honeycomb
- On-call
Make contracts explicit
At each boundary between teams or services, I write down the states, the errors, and who owns them, so nobody has to reverse-engineer them later.
Plan for failure
Payments time out and callbacks arrive late. I give the recovery path the same attention as the happy path.
Write it down
Docs, tests, runbooks, and agent instructions let the next person, or agent, make the same call without asking me.
Working with me
I raise risks early
If a plan has a risky dependency or a tight date, I say so during planning, while there's still time to change it.
I work well in writing
I write tickets, PR descriptions, and docs for whoever reads them months later, and I'm comfortable working across time zones.
Give me a mandate
I'm most useful when I own a problem end to end, including the parts that cross into other teams and systems. Tell me the goal and where my role ends, and I'll work out the rest.
I like pairing
I enjoy pairing and onboarding. Several engineers got up to speed on our team through pairing sessions with me.
Experience
Where I've worked
Eighteen years of web work, mostly frontend, in analytics, content management, logistics, and now commerce and payments.
2023-present
Senior Frontend Engineer II
SumUp
I work on the online store where merchants buy card readers and subscriptions, and on the sales backoffice. Behind both sit the SDK, the CMS integrations, payment handling, monitoring, and developer tooling I also work on.
2021-2023
Lead Frontend Engineer
HERE Technologies
Led frontend work for the logistics division: a real-time vehicle-tracking dashboard over WebSockets, the move to the new design system, and hiring and onboarding for a team of six. I also set up Cypress UI tests and Amplitude funnel tracking.
2019-2021
Senior Frontend Engineer
Doodle
Moved between the Growth, Data, and Design System teams. I started the TypeScript design system, wrote the frontend analytics library that six teams adopted, and helped launch the Contentful-based website.
2007-2019
Frontend & Full-stack Engineer
Earlier work
An ads management tool at Delivery Hero and frontend work at RideLink and Architrave. Before that, about ten years of Plone and Django projects for Brazilian government portals, universities, and agencies, with some clients in the US, Australia, and Germany.
Toolkit
What I work with
Frontend is where I'm strongest. I use the rest when a problem goes past the browser, which in commerce happens a lot.
Frontend
Platform & AI tooling
Reliability & delivery
Backend & infrastructure
Background
How I got here
I studied advertising, not computer science. I got into software through design work, Brazilian public-sector portals, Python, and the Plone open-source community, and I still lean on that background when I explain systems or design for the people using them.
Education
BA in Social Communication (Advertising)
University of São Paulo, 2001-2006
Final thesis: "Wikipedia: an exploratory study"
Download the thesis (PDF, in Portuguese)Visual arts & audiovisual studies
Brazilian Ministry of Culture and SENAC, 2007-2012
Selected talks
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
Public digital services
Led and built content platforms for universities, libraries, legislatures, and government institutions.
Open source
Plone and Python community work: add-ons, upstream fixes, conference talks, and Clips, a Django app for conference schedules used at PyCon Brazil and FISL.
Languages
Portuguese (native), English (C1), German (B2), and Spanish (B1). Based in Berlin.
Let's compare notes
I'm always up for a conversation about frontend architecture, commerce systems, observability, or using AI in day-to-day engineering.