Senior / Lead Frontend Engineer
Ich baue Commerce-Frontends und die Plattformen darunter.
Meine Arbeit der letzten Jahre liegt meist dort, wo der Checkout auf Payments, APIs, Content-Systeme und Monitoring trifft. Bei SumUp arbeite ich am Kaufprozess, über den Händler Kartenterminals und Abos kaufen, und an dem SDK, dem MCP-Server und der Doku, mit denen andere Teams und KI-Agenten damit arbeiten.
- TypeScript
- React
- Next.js
- SDKs
- MCP
- OpenTelemetry
Berufserfahrung
18+ Jahre
Arbeitsbereich
Produkt und Plattform
Aktueller Fokus
Zuverlässiger Commerce
Standort
Berlin
Ausgewählte Projekte
Drei Projekte aus den letzten Jahren
Jedes beschreibt das Problem, was ich dagegen getan habe und was sich danach geändert hat. Vertrauliche Geschäftszahlen und interne Details habe ich weggelassen.
Commerce-Plattform · KI-Tools
Eine Schnittstelle zur Commerce-Domäne, für Teams und KI-Agenten
Ein TypeScript-SDK und ein MCP-Server, über die Storefronts, Vertriebstools und KI-Clients auf Preise, Bestellungen, Abos, Angebote und Verträge zugreifen.
Das Problem
Die Commerce-Logik war auf mehrere Services verteilt, jeder mit eigenem Ressourcenmodell. Jede Anwendung brauchte diesen Kontext, und ihn überall hineinzukopieren hätte mehr Integrationsfehler und mehr Support-Anfragen für unser Team bedeutet.
Was ich getan habe
- Das typisierte SDK als Schicht mitentworfen, die diese Services bündelt, damit niemand wissen muss, welcher Service wofür zuständig ist. Ich habe es weiter ausgebaut, als andere Teams mehr brauchten.
- Einen MCP-Server ergänzt, dessen Tools angeben, ob sie nur lesen, Daten hinzufügen, sie überschreiben oder gefahrlos wiederholt werden können.
- Agent Skills mit Evals und Repository-Guidance geschrieben, damit Domänenwissen in versionierten Dateien liegt, die sich testen und reviewen lassen.
- Jede Ressource gebenchmarkt, bevor ich die Antworten auf die Felder reduziert habe, die tatsächlich genutzt werden.
Was sich geändert hat
- Kundennahe und interne Vertriebstools binden sich über das SDK an, darunter der Shop auf der Marketing-Website.
- Eine einzige Feldreduktion hat die Payloads von Bestellungen um etwa 93 % und die p50-Latenz einzelner Bestellungen um etwa 11 % gesenkt.
- Agenten können echte Aufgaben in der Domäne erledigen, und ihre Clients wissen, welche Tool-Aufrufe eine Bestätigung durch einen Menschen brauchen.
Observability · On-Call
Browserfehler mit der Transaktion verbinden, die sie ausgelöst hat
Früher mussten On-Call-Engineers Zeitstempel zwischen Sentry und Honeycomb abgleichen, um einen fehlgeschlagenen Kauf zu verstehen. Heute können sie ihn an einer Stelle vom Browser bis in die Backend-Traces verfolgen.
Das Problem
Das Upgrade des Commerce-Layer-SDK hat dessen HTTP-Client von XHR auf fetch umgestellt. Unsere Browser-Instrumentierung deckte nur XHR ab, also erzeugten Auth-, Bestell- und Line-Item-Aufrufe keine Spans mehr. Browserfehler landeten außerdem nur in Sentry, getrennt von den Backend-Traces, die On-Call liest.
Was ich getan habe
- fetch-Instrumentierung mit W3C-Trace-Propagation ergänzt und jedem Span Attribute für Bestellung, Händler, Locale und Flow mitgegeben.
- Unbehandelte Fehler sowie behandelte Fehler bei den Checkout-Requests, die unser SLO misst, in dieselbe Pipeline geschickt. Source Maps hochgeladen, damit Stacktraces aus der Produktion lesbar sind.
- Rauschen aus Hydration und Drittanbietern herausgefiltert, die Fehlererfassung hinter ein eigenes Flag gelegt und den Tracing-Code lazy geladen, um Kosten und Bundle-Größe niedrig zu halten.
- Deployment-Marker hinzugefügt, damit sich eine Veränderung im Graphen dem Release zuordnen lässt, das sie verursacht hat.
Was sich geändert hat
- On-Call kann nach Bestell-ID suchen und sieht den Frontend-Fehler direkt neben dem Backend-Trace.
- Auth-, Bestell- und Line-Item-Requests tauchen wieder in den Traces auf.
Architektur · Migration
Produktdatenmodell und CMS austauschen, während die Teams weiter ausliefern
Eine schrittweise Migration von Contentful zu Builder.io über Storefront, Backoffice, SDK-Konsumenten und den Workflow der Content-Redaktion.
Das Problem
Mehrere Apps und Teams lesen dieselben Produktdaten. Modell und CMS in einem einzigen Cut-over zu tauschen, hätte alle an den Migrationstermin gebunden und ein Rollback schwer gemacht.
Was ich getan habe
- Das Produktmodell neu entworfen und eine abwärtskompatible Reihenfolge geplant, damit jeder Konsument in seinem eigenen Tempo umziehen konnte.
- Ein Commerce-Layer-Plugin für Builder gebaut, das Produkt-Snapshots im veröffentlichten Content speichert, damit dort keine Tokens oder API-URLs landen.
- Prüfungen auf Eindeutigkeit und gegenseitigen Ausschluss in versionierte Validierungs-Hooks verlagert, damit die Redaktion Probleme schon beim Bearbeiten sieht.
- Während des Rollouts beide Provider parallel betrieben und das Plugin per Lasttest geprüft, bevor der Übergangscode entfernt wurde.
Was sich geändert hat
- Storefront und interne Tools sind ohne geplante Downtime umgezogen.
- Veröffentlichte Seiten hängen nicht mehr davon ab, dass Commerce Layer erreichbar ist, wenn das CDN sie ausliefert.
Wie ich arbeite
Meine Arbeit passiert meistens zwischen Systemen
Am meisten bringe ich ein, wenn eine Customer Journey mehrere Systeme und Teams durchläuft und jemand entscheiden muss, welches System welchen Zustand verwaltet und wer gepaged wird, wenn etwas kaputtgeht.
Commerce & Payments
Ich verfolge eine Transaktion vom Browser über unsere APIs und den Zahlungsanbieter bis zu dem Callback, der zurückkommt.
- Recovery in Checkout und Zahlung
- Ratenzahlung und Abos
- Verträge
- Regeln, die je Markt abweichen
Plattformen & KI-Tools
Ich baue SDKs, MCP-Tools und Doku, damit andere Teams eine komplexe Domäne nutzen können, ohne sie erst komplett lernen zu müssen.
- TypeScript-SDKs
- MCP-Server
- Agent Skills mit Evals
Zuverlässigkeit & Observability
Monitoring gehört für mich zum Ausliefern eines Features dazu, vom Browser-Tracing bis zur Nachbereitung eines Incidents.
- OpenTelemetry und Honeycomb
- On-Call
Verträge explizit machen
An jeder Grenze zwischen Teams oder Services schreibe ich Zustände, Fehler und Zuständigkeiten auf, damit niemand sie später rekonstruieren muss.
Mit Fehlern planen
Zahlungen laufen in Timeouts und Callbacks kommen zu spät. Den Recovery-Pfad behandle ich mit derselben Sorgfalt wie den Happy Path.
Aufschreiben
Doku, Tests, Runbooks und Anweisungen für Agenten erlauben der nächsten Person, oder dem nächsten Agenten, dieselbe Entscheidung zu treffen, ohne mich zu fragen.
Zusammenarbeit mit mir
Ich spreche Risiken früh an
Wenn ein Plan eine riskante Abhängigkeit oder einen knappen Termin hat, sage ich das schon in der Planung, solange sich noch etwas ändern lässt.
Ich arbeite gut schriftlich
Ich schreibe Tickets, PR-Beschreibungen und Doku so, dass man sie auch Monate später noch versteht, und arbeite problemlos über Zeitzonen hinweg.
Gib mir ein Mandat
Ich bin am nützlichsten, wenn ich ein Problem von Anfang bis Ende verantworte, auch die Teile, die in andere Teams und Systeme hineinreichen. Nenn mir das Ziel und sag mir, wo meine Rolle endet, den Rest erarbeite ich.
Ich mag Pairing
Ich programmiere gern im Pair und helfe beim Onboarding. Mehrere Engineers haben sich über Pairing-Sessions mit mir in unser Team eingearbeitet.
Erfahrung
Wo ich gearbeitet habe
Achtzehn Jahre Webentwicklung, überwiegend im Frontend, in Analytics, Content-Management, Logistik und jetzt Commerce und Payments.
2023-heute
Senior Frontend Engineer II
SumUp
Ich arbeite am Onlineshop, in dem Händler Kartenterminals und Abos kaufen, und am Vertriebs-Backoffice. Dahinter stehen das SDK, die CMS-Integrationen, die Zahlungsabwicklung, das Monitoring und die Developer-Tools, an denen ich ebenfalls arbeite.
2021-2023
Lead Frontend Engineer
HERE Technologies
Ich habe die Frontend-Arbeit im Logistikbereich geleitet: ein Echtzeit-Dashboard zur Fahrzeugverfolgung über WebSockets, den Umstieg auf das neue Design System sowie Einstellung und Onboarding für ein Team von sechs Personen. Außerdem habe ich Cypress-UI-Tests und Funnel-Tracking mit Amplitude eingeführt.
2019-2021
Senior Frontend Engineer
Doodle
Ich war abwechselnd in den Teams Growth, Data und Design System. Ich habe das TypeScript-Design-System gestartet, die Frontend-Analytics-Bibliothek geschrieben, die sechs Teams übernommen haben, und beim Launch der Contentful-basierten Website geholfen.
2007-2019
Frontend & Full-Stack Engineer
Frühere Stationen
Ein Tool zur Anzeigenverwaltung bei Delivery Hero und Frontend-Arbeit bei RideLink und Architrave. Davor rund zehn Jahre Plone- und Django-Projekte für brasilianische Regierungsportale, Universitäten und Agenturen, dazu einige Kunden in den USA, in Australien und in Deutschland.
Toolkit
Womit ich arbeite
Im Frontend bin ich am stärksten. Den Rest nutze ich, wenn ein Problem über den Browser hinausgeht, und im Commerce passiert das oft.
Frontend
Plattform & KI-Tools
Zuverlässigkeit & Delivery
Backend & Infrastruktur
Werdegang
Wie ich hierher kam
Ich habe Werbung studiert, nicht Informatik. Zur Softwareentwicklung kam ich über Designarbeit, brasilianische Behördenportale, Python und die Open-Source-Community rund um Plone, und auf diesen Hintergrund greife ich bis heute zurück, wenn ich Systeme erkläre oder für die Menschen gestalte, die sie nutzen.
Ausbildung
BA in Sozialer Kommunikation (Werbung)
Universität São Paulo, 2001-2006
Abschlussarbeit: "Wikipedia: an exploratory study"
Abschlussarbeit herunterladen (PDF, auf Portugiesisch)Studien in bildender Kunst und Audiovision
Brasilianisches Kulturministerium und SENAC, 2007-2012
Ausgewählte Vorträge
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
Öffentliche digitale Dienste
Content-Plattformen für Universitäten, Bibliotheken, Parlamente und Behörden geleitet und gebaut.
Open Source
Arbeit in den Plone- und Python-Communities: Add-ons, Upstream-Fixes, Konferenzvorträge und Clips, eine Django-App für Konferenzprogramme, die auf der PyCon Brazil und dem FISL im Einsatz war.
Sprachen
Portugiesisch (Muttersprache), Englisch (C1), Deutsch (B2) und Spanisch (B1). Wohnhaft in Berlin.
Lass uns austauschen
Ich unterhalte mich gern über Frontend-Architektur, Commerce-Systeme, Observability oder den Einsatz von KI im Engineering-Alltag.