Der vollständige Werdegang
Der Lebenslauf führt jede Station bis zurück ins Jahr 2001 auf — auch die frühen Jahre, die diese Seite weglässt. Deutsch und Englisch, gleicher Inhalt.
Projekte
Eine Auswahl aus fünfundzwanzig Jahren: die Projekte, in denen die Architekturentscheidungen meine waren. Kundenarbeit zuerst; das eigene Produkt steht als Beleg dafür, dass die Praxis aktuell ist.
Ein Teil davon entstand im Angestelltenverhältnis, ein Teil in eigenen Unternehmen — jeder Eintrag sagt, welches von beidem. Wo es eine Anstellung war, ist die genannte Organisation der Arbeitgeber, bei dem ich die Arbeit gemacht habe, nicht mein Kunde; ging das Projekt an einen Kunden des Arbeitgebers, bleibt dieser ungenannt. Beschrieben sind die Architektur und mein Anteil daran; was vertraulich bleibt, steht hier nicht.
Die Schul-IT dreier Bundesländer arbeitet mit einer Oberfläche statt mit fünf Herstellerkonsolen — und wenn das Ticketsystem ausfällt, geht kein Ticket verloren.
Länderübergreifendes DigitalPakt-Projekt für Baden-Württemberg, Nordrhein-Westfalen und Sachsen: eine Oberfläche, über die Schulträger und Schul-IT WLAN-Zugänge, Tickets, Geräte und Contentfilter verwalten. Ein .NET-9-Backend nach Clean Architecture (Minimal APIs, MediatR/CQRS) führt die fünf externen Fachdienste dahinter zu einer einzigen REST-API zusammen, sodass kein Herstellermodell in die Domäne durchschlägt; eine React-19-Anwendung liefert OIDC-Authentifizierung und rollenbasierte Rechte, dazu eine barrierefreie React-Aria-Komponentenbibliothek, in Storybook dokumentiert und als npm-Paket ausgeliefert. Ein eigener Rust-Dienst persistiert Ticketanfragen vor dem Aufruf und wiederholt sie mit Backoff. Betrieb GitOps-artig auf Kubernetes bei einem deutschen Hoster, mit Terraform, FluxCD, Helm und SOPS-verschlüsselten Secrets.
Zwei Architekturentscheidungen haben sich öffentlich bezahlt gemacht: Die Zahlungsanbieter (Stripe Connect und PayPal) konnten komplett ausgetauscht werden, ohne die Abrechnungslogik anzufassen, und vier APIs zogen in einer Woche von Elysia nach Hono um, ohne dass die Domänenpakete angerührt wurden.
Eine produktive, DSGVO-konforme Multi-Tenant-SaaS, entwickelt und gehostet in der EU: vier Hono-APIs, drei Nuxt-4-Frontends, eine Astro-Marketing- und Dokumentationsseite und ein Headless-SDK, verteilt auf dreizehn Pakete und abgesichert durch Integrationstests gegen eine echte PostgreSQL-Instanz in der CI. Elf Monate vom leeren Repository bis in den Produktivbetrieb, nebenberuflich gebaut. Die Mandantentrennung ist durch Row-Level Security in PostgreSQL erzwungen, nicht nur vereinbart; personenbezogene Daten sind pro Mandant verschlüsselt, über Blind Indexes durchsuchbar und durch Löschen des Schlüssels wirklich löschbar. Die Domänen reichen vom Buchungslebenszyklus über Angebote mit mehreren Optionen, ein append-only geführtes Zahlungsjournal, Rechnungen und Abrechnungen, Preise und Verfügbarkeiten und einen CMS-Storefront-Builder bis zu mehrsprachigem SEO und lokalen Steuer- und Meldepflichten. Zu den KI-Funktionen im Produkt gehören ein Tool-Calling-Agent hinter einem Freigabe-Workflow, ein MCP-Server und eine RAG-gestützte Hilfe in der Anwendung.
Architektur und Entwicklung des Backends für eine KI-gestützte Plattform zur Workflow-Automatisierung.
Jede Ziehung ist nachträglich überprüfbar: Der Startwert wird kryptografisch erzeugt und zusammen mit dem Ergebnis gespeichert, sodass ein Verein der Aufsichtsbehörde belegen kann, wie die Gewinner ermittelt wurden.
Eine mandantenfähige Plattform, über die gemeinnützige Vereine kleine Lotterien vollständig digital durchführen — von der Anzeige bei der zuständigen Behörde über den Losverkauf und die Ziehung bis zur Abrechnung. Kern der Fachlichkeit ist ein Regelwerk für das deutsche Glücksspielrecht: Verfahrensschritte, Fristen und zuständige Behörden sind je Bundesland und Landkreis hinterlegt und steuern den Ablauf jeder Lotterie. Da Lose nur innerhalb des zugelassenen Bezirks verkauft werden dürfen, werden die amtlichen Verwaltungsgebiete in PostGIS importiert; die Regions- und Umkreissuche läuft in der Datenbank. Ein .NET-8-Backend nach Clean Architecture (Minimal APIs, MediatR/CQRS) mit SvelteKit-Frontend, Zahlung per SEPA-Lastschrift, Identitätsprüfung über einen externen Dienst und den rechtlich erforderlichen Dokumenten als automatisch erzeugte PDFs.
Architektur und Entwicklung einer NFT-Handelsplattform — Frontend, Backend und Smart Contracts auf Polygon.
Eine Plattform, die den Luftraum über kritischer Infrastruktur mit fest installierten Rundumkameras überwacht — ML-gestützte Bildanalyse erkennt und klassifiziert Flugobjekte, insbesondere Drohnen, verfolgt ihre Bahn und meldet auffällige Annäherungen.
Dieselbe Auftragsform wie die Architektur-Reviews, die ich heute übernehme — ein Blick von außen, schriftlich festgehalten und an das Team übergeben, das damit weiterarbeiten muss.
Code- und Architektur-Reviews, Handlungsempfehlungen und Entwicklerunterstützung.
Architektur und Entwicklung von Frontend und Backend, dazu die gemeinsamen Bibliotheken und der Tool-Stack dahinter.
Ein gemeinsamer Stack und eine gemeinsame Komponentenbibliothek für alle Kundenprojekte der Firma — statt dass sich jedes Projekt eigene zulegt.
Frontend-Technologiekonzepte, Schnittstellendefinitionen sowie die Bibliotheken, der Tool-Stack und das Build-Tooling für die Kundenprojekte — dazu die Unterstützung der Entwickler, die damit arbeiten.
Der vollständige Werdegang
Der Lebenslauf führt jede Station bis zurück ins Jahr 2001 auf — auch die frühen Jahre, die diese Seite weglässt. Deutsch und Englisch, gleicher Inhalt.
Referenzen mit Telefonnummer
Benannte Ansprechpartner bei früheren Auftraggebern — Menschen, die man anrufen und fragen kann, wie die Zusammenarbeit war. Auf Anfrage, sobald es einen konkreten Auftrag zu besprechen gibt.
Welche Aufträge daraus werden, steht auf der Leistungsseite — Reviews, Systementwurf und die Umsetzung selbst.