Fractional .NET-Architektur

So arbeite ich

Verantwortung bis in den Betrieb. Wer die Architektur entscheidet, verantwortet sie auch bis in den Produktivbetrieb. Deshalb entwerfe ich nicht nur — ich implementiere, teste, deploye und beobachte das System im laufenden Betrieb.

KI konkret statt Buzzword. Eine nächtliche Claude-Code-Fehler-Triage öffnet Pull Requests zur Review; wöchentliche Infrastruktur-Trend-Analysen werden zu Issues. KI-Werkzeuge beschleunigen meine Arbeit — die Verantwortung bleibt bei mir.

Testdisziplin. xUnit, bUnit und Playwright gehören zum Standard; TDD dort, wo es sich auszahlt — und ehrlicherweise nicht dort, wo ein UI-Prototyp morgen wieder anders aussieht.

Warum fractional?

Viele Produkt- und SaaS-Teams brauchen Architektur-Seniorität, können oder wollen dafür aber keine Vollzeitstelle schaffen. Genau dafür ist mein Modell gebaut: 50 % Kapazität, Aufteilung nach Bedarf, remote-first. Du bekommst Architekturentscheidungen, Reviews und Umsetzung aus einer Hand — kontinuierlich über den Lebenszyklus deines Systems, nicht als einmaliger Beratungseinsatz.

Eigene Produkte

Ich betreibe, was ich baue: Mein Buchungs-SaaS buchungsnest.de läuft produktiv mit externen Kunden — auf einem event-sourced Kern, mit eigener CI/CD-Pipeline inklusive Staging und Smoke-Tests sowie OpenTelemetry-Monitoring. Jede Empfehlung, die ich als Architekt ausspreche, hat vorher meinen eigenen Betrieb überlebt.

Dazu gehört auch DSGVO-konforme Löschung per Crypto-Shredding: Personenbezogene Daten sind pro Person verschlüsselt; eine Löschung vernichtet den Schlüssel und bleibt dabei selbst nachweisbar im Audit-Log. Gleichzeitig respektiert das System die handels- und steuerrechtlichen Aufbewahrungsfristen für Rechnungsdaten. Datenschutz und Audit-Fähigkeit schließen sich nicht aus — wenn die Architektur beides von Anfang an vorsieht.