All-in-one-Plattform und LMS für Bildungsanbieter, die den Verwaltungsalltag in Audit-Nachweise verwandelt. Gestartet in einem KI-App-Builder, heute ein sicheres Multi-Tenant-Produkt mit Web-, iOS- und Android-App.
So bin ich vorgegangen
Architektur: React auf Vercel, Supabase Postgres mit Row-Level-Security auf jeder Tabelle, 160 Edge Functions und 26 geplante Jobs
Kurse und SCORM-E-Learning, Sessionplanung, E-Signatur-Anwesenheit per QR-Code, Verträge und Zertifikate
Förder-Workflows, ein jährlicher Pflichtbericht, ein CRM und ein öffentlicher Katalog mit Stripe-Checkout
Qualitäts-Audit-Modul: Nachweise pro Indikator, Probe-Audit und Präsentationsmodus für den Auditor
KI-Agent (Gemini), der Datensätze nach Bestätigung bearbeitet, plus MCP-Server in Produktion: Alles, was in der Oberfläche geht, geht auch aus Claude, ChatGPT oder dem eigenen Coding-Agent, inklusive Analytics und Nutzerdaten
Native Android- und iOS-Apps (Kotlin/Compose, SwiftUI), Design-Tokens automatisch aus dem Web-CSS generiert
Release-Pipeline: Migrationen vor dem Merge im Trockenlauf, nur geänderte Functions deployt, Smoke-Tests nach jedem Deploy
Verschlüsselte Backups 7× täglich, Dateien nach Cloudflare R2 gespiegelt, nächtlicher Restore-Test in ein separates Zwillingsprojekt
Ergebnis: 3'025 gemergte Pull Requests in zehn Monaten, in kleinen, umkehrbaren Schritten ausgeliefert.
Helptempo: ein Sales- und Support-Chat für jede Website, gebaut als wiederverwendbare Engine
Rolle: Product Owner und Engineer: Design, Entwicklung, Paketierung
~5 min~5 min
bis zum Einbau in eine Site
~9 KB~9 KB
Widget, gzip, ohne Abhängigkeiten
44
Hosting-Ziele ab Werk
33
Modell-APIs, plus lokale Modelle
Ein KI-Chat zum Einbauen, einmal gebaut und auf jeder Website wiederverwendet; jede Site bringt nur ihre eigene Wissensdatei mit. Er beantwortet offene Fragen, nennt nur Fakten und Preise, die auf der Seite stehen, führt Besucher per Button zum richtigen Abschnitt und schlägt die nächste Frage vor. Der KI-Guide dieser Website läuft darauf: unten rechts ausprobieren.
So bin ich vorgegangen
Widget: ein ES-Modul im Shadow DOM, ohne Abhängigkeiten, rund 9 KB gzip; läuft auf reinem HTML, WordPress, React und Next.js
Ein Backend für jeden Host: Next.js/Vercel, Azure Static Web Apps und Functions, Cloudflare Workers, Node/Express
Jedes Modell: Gemini, Claude oder jede OpenAI-kompatible API, auch lokale Modelle (Ollama, vLLM) und Gateways (LiteLLM), mit automatischer Fallback-Kette
Gebaut zum Verkaufen: Antworten enden mit Navigations-Buttons in die Seite und Folgefragen; er qualifiziert Besucher und zeigt den nächsten Schritt
Vorbereitete Antworten auf Einstiegsfragen (sofort, ohne API-Aufruf) und ein serverseitiger Antwort-Cache
Sicher ab Werk: Keys nur auf dem Server, Modellausgabe nur als Text, freigegebene Links, Rate-Limit, Eingabelimits, CORS standardmässig gesperrt
Englisch, Deutsch, Spanisch und Französisch eingebaut, hell und dunkel, Handy-Layout
In etwa fünf Minuten in eine neue Website eingebaut: installieren, eine Wissensdatei, eine kleine Konfiguration
Ergebnis: Eine neue Produktseite bekommt in Minuten einen funktionierenden, mehrsprachigen Verkaufsberater, der nur zitiert, was die Seite selbst zeigt.
Buchungs- und Betriebsplattform für das Gastgewerbe
Rolle: Architekt und Lead Engineer, von A bis Z
6464
Staff-Ansichten für 7 Rollen
107107
Serverless Functions
4'9584'958
Unit-Tests + 77 End-to-End-Specs
2'1332'133
gemergte PRs in sechs Monaten
Ich habe einen KI-generierten Prototyp übernommen und daraus die Plattform gemacht, die Buchungen, Zahlungen, Mitarbeiter-Abläufe, Vertrieb, Marketing und WhatsApp-Gästekommunikation einer Surfschule mit Hostel steuert.
So bin ich vorgegangen
Buchungsstrecken für Surfkurse, Camps, Coworking, Hostel-Aufenthalte, Mehrwochen-Pässe und Wochenend-Pakete
Stay-Builder mit Live-Preisen aus dem Hostel-System, Buchung nach Zahlung automatisch zurückgeschrieben
Staff-Dashboard mit 64 Ansichten und 7 Rollen: Kalender, Walk-ins, Check-in mit Kurtaxe, Angebote, Gutscheine, Verleih, Finanzen
Vertriebs-CRM mit KI-Lead-Scoring, Antwortentwürfen und Sales-Report für das Management
WhatsApp-KI-Agent (Gemini), dessen Wissensbasis aus Antworten des Teams wächst; neues Wissen geht erst nach Freigabe live
Marketing- und Kampagnenkalender für das ganze Team
Read-only Public API und MCP-Server (keine Personendaten, gehashte Keys), mit denen der Kunde die Wochenplanung automatisiert
Trennung Staging/Produktion, Arbeit nur über PRs, verschlüsselte Backups alle 4 Stunden, unabhängig vom Hosting-Anbieter
Watchdogs: stündliche Probes der Buchungsstrecke, tägliche synthetische Zahlung und Alarm bei ausbleibenden Buchungen
Ergebnis: Als der Anbieter des Hostel-Systems seine API ohne Vorwarnung änderte, schlugen die Probes an, und Aufenthalte waren am selben Tag wieder buchbar.
Die Vertriebspipeline lebt in der Plattform, auf der das Geschäft ohnehin läuft, neben Buchungen, Zahlungen und Marketing. Die KI bewertet die Leads und entwirft die Antworten, und das Management sieht die Zahlen in einem Report.
So bin ich vorgegangen
Vertriebs-CRM von der ersten Anfrage bis zur Buchung
KI-Lead-Scoring (Gemini), damit das Team die besten Leads zuerst anruft
KI-Antwortentwürfe, die das Team anpasst und versendet
Ein Sales-Report für das Management
Auch das Bildungs-SaaS hat ein eigenes CRM-Modul, neben Förder-Workflows und Kurskatalog
Ergebnis: Vertrieb, Buchungen und Marketing in einem System, die KI liefert den ersten Entwurf.
GEO: ein Restaurant-Netzwerk in der KI-Suche sichtbar machen
Rolle: GEO-Berater: Analyse, Baseline, Experimente und Proofs of Concept
1010
Experimente nach Wirkung priorisiert
~150~150
Landingpages in der Prompt-Recherche
33
Phasen: analysieren, auswählen, umsetzen
Eine Plattform mit einem grossen Netzwerk an Restaurant-Websites wollte, dass Gäste Restaurants über ChatGPT, Gemini und Googles KI-Antworten finden und buchen. Ich habe gemessen, woher KI-Traffic heute kommt, Prompt-Recherche aufgesetzt und die Ergebnisse in priorisierte Experimente mit funktionierenden Proofs of Concept übersetzt.
So bin ich vorgegangen
Baseline der KI-vermittelten Besuche und Conversions neben der klassischen Suche, aus Web-Analytics und Google Search Console
Prompt-Recherche für rund 150 Landingpages: realistische Gästefragen per LLM aus der Sitemap erzeugt und in Semrush verfolgt
Bewertung von KI-Visibility- und Listing-Tools, inklusive der Fragen von Recht und Datenschutz
Listing-Plattformen verglichen, um Restaurantdaten per API auf Drittportalen zu veröffentlichen
10 Experimente nach Wirkung und Aufwand priorisiert, im Workshop ausgewählt und in Sprints umgesetzt
Proofs of Concept: automatisches Veröffentlichen auf Drittportalen und ein Generator für SEO/GEO-Artikel
Ergebnis: Eine gemessene Baseline und eine priorisierte Roadmap statt Bauchgefühl, dazu Werkzeuge, die das Team weiter nutzt.
Stack: Semrush, Google Search Console, Web analytics, Open LLMs, Schema.org, Listing APIs, Python
Medienfunktionen für Live-Produktionen laufen als gebuchte On-Demand-Workloads auf Kubernetes: On-Prem auf Bare Metal hinter VPN und auf AWS. Ich habe den Buchungs-Showcase gebaut und einen grossen Teil der Integration, die die Plattform live betreibbar machte.
So bin ich vorgegangen
Buchungs-Showcase in Go und Angular: Produktion buchen, Deployment live verfolgen, Vorschau per WebRTC; Helm-Chart und GitOps-Rollout auf beide Cluster
Windows-Orchestrierungsserver als VM auf KubeVirt im Bare-Metal-Cluster; VM-Image-Import über VPN rund 120× schneller
Cassandra und OpenSearch in den Cluster geholt, damit die Plattform auch air-gapped läuft
Kostenleitplanken im Code: Dev-Umgebung jede Nacht abgebaut, Preview-Umgebungen mit Ablaufzeit, verwaiste Volumes aufgeräumt, Kosten-Tags beim Plan erzwungen, Alerts auf Cross-Zone-Traffic
FluxCD-Health-Alerts in den Chat, Keycloak-SSO für Grafana, External Secrets, oauth2-proxy vor internen Tools
Talos-Cluster auf Bare Metal und EC2 mit Karpenter betrieben und debuggt; Netzwerk-Fixes bei einem Open-Source-Projekt für Medientransport eingereicht
Ergebnis: Produktionen werden auf Abruf gebucht und ausgerollt, und die Dev-Umgebung ist standardmässig jede Nacht und jedes Wochenende aus.
Rolle: Einziger DevOps Engineer, verantwortlich für das Kostenprogramm
−48 %−48 %
gesamte Azure-Kosten, in fünf Wochen
7 → 4
Kubernetes-Nodes
~40×~40×
weniger Cosmos-DB-Last
~35~35
Änderungen in einem Monat, je ein Ticket
Als einziger DevOps Engineer einer Plattform auf AKS, Postgres und Cosmos DB habe ich die gesamten Azure-Kosten (monatliche Run-Rate) in fünf Wochen um 48 % gesenkt, ohne dass sich für Kunden etwas sichtbar änderte.
So bin ich vorgegangen
Amortisierte Kostenbasis pro Ressource aus der Cost-Management-API, mit Run-Rate-Prognose statt Warten auf die Rechnung
Live-Check vor jeder Empfehlung: Was läuft darauf, wer nutzt es, Spitzenlast statt Durchschnitt
Kubernetes-Right-Sizing nach Prometheus-p95-Nutzung, danach weniger Nodes; Reservierungen am Tag des Abbaus zurückgegeben
Datenbank-Standbys und Aufbewahrung an den echten Bedarf angepasst; Mandanten-Datenbanken mit CloudNativePG in den Cluster verlagert, Zeilenzahlen und Prüfsummen identisch
Monitoring-Stack von eigener VM in AKS umgezogen; Debug-Logging in kostenpflichtigen Speicher reduziert
Ein Query-Fix senkte die Last auf einer serverlosen Cosmos DB um etwa das 40-Fache, bei identischem Ergebnis
Täglicher Kostenbericht im Chat, Budgets mit Prognose-Alerts, Tagging-Schema und wöchentlicher Management-Report mit Zwei-Monats-Prognose
Ergebnis: Jede Änderung mit Auswirkung, Risiko und Rückweg, ein Ticket pro Änderung. Nichts, was Kunden bemerken könnten, wurde angefasst.
Muster auf SaaS-, Broadcast- und Retail-Plattformen, 2026
Monitoring auf Geschäftsergebnisse, Backups jede Nacht geprüft
Rolle: Auf jeder Plattform konzipiert und gebaut
10 min10 min
Checks von aussen
nächtlich
Restore-Test
143143
Alert-Regeln auf Kubernetes
Dashboards können grün bleiben, während Kunden nicht bezahlen können. Ich baue Monitoring, das prüft, was für das Geschäft zählt, und Alerts so ruhig hält, dass sie noch gelesen werden.
So bin ich vorgegangen
Synthetische Checks von aussen alle 10 Minuten, stündlicher Durchlauf der Buchungsstrecke und eine tägliche Testzahlung
Ergebnis-Watchdogs gegen die Datenquelle: bezahlt, aber keine Reservierung; Besucher, aber keine Buchungen
Release-Gates: Migrationen vor dem Merge im Trockenlauf, Smoke-Test nach jedem Deploy, der rot wird, wenn eine kritische Route ausfällt
Rauschkontrolle: ein GitHub-Issue pro Ausfall, automatisch geöffnet und geschlossen, dedupliziert, mit Stundenlimit
Prometheus, Grafana, Loki und Alertmanager mit 143 Alert-Regeln auf einer Kubernetes-Plattform
Verschlüsselte Backups alle 3–4 Stunden ausserhalb des Anbieters, jede Nacht in einen isolierten Zwilling wiederhergestellt
Audit-Trail auf S3 Object Lock (einmal schreiben, 90 Tage aufbewahrt) mit reinen Schreib-Zugangsdaten
Ergebnis: Backups werden jede Nacht per Restore geprüft statt nur vorausgesetzt, und die Alert-Kanäle bleiben lesbar.
Ein KI-Agent steuert ein echtes Chrome über Playwright. Sie beschreiben einen User-Flow in Alltagssprache; der Agent klickt ihn durch und liefert ein strukturiertes Bestanden/Nicht bestanden mit Konsolenfehlern, fehlgeschlagenen Requests und Fix-Prompt.
So bin ich vorgegangen
Testszenarien in Alltagssprache mit JSON-Ergebnis: bestanden, verfehlte Erwartungen, Konsolenfehler, Netzwerkfehler, Fix-Prompt
Routen-Map mit vorgewärmten Login-Profilen; ein KI-Fallback meldet verschobene Routen
Mehrrollen-Checks: eine Rolle handelt, der Bildschirm einer anderen muss sich ohne Reload aktualisieren, die Verzögerung wird gemessen
iPhone- und In-App-Browser-Emulation, um gemeldete Fehler von Endnutzern nachzustellen
Ergebnis: Der Standard-Check vor und nach Produktiv-Releases auf zwei Live-Plattformen.
Stack: Node.js, Claude Code, Playwright MCP, Chrome, WebKit
Ein kleiner Roboter, von Grund auf gebaut: ein ESP32 mit Servos, Sensoren und OLED-Display. Sprache und KI laufen auf einem lokalen Whisper-Modell und einem lokalen LLM, er hört, denkt und bewegt sich also ganz ohne Internet.
So bin ich vorgegangen
ESP32-Firmware mit PlatformIO und dem Arduino-Framework: Servos, Sensoren und ein SSD1306-Display
Spracherkennung auf einem lokalen Whisper-Server, Antworten von einem lokalen LLM
Von Grund auf air-gapped, mit eigenem Fallback-Hotspot und WLAN-Steuerung
Dasselbe Muster wie bei privater KI in Unternehmen: Keine Daten verlassen das Gerät
Ergebnis: Ein funktionierender Roboter, der Sprache und KI komplett offline ausführt.
Stack: ESP32, PlatformIO, C++, Arduino, SSD1306 OLED, Whisper, Local LLM
Release Engineering für Banking-Apps mit Millionen Nutzern
Rolle: DevOps Engineer für die mobilen Release-Pipelines
~40%~40%
schnellere Release-Zyklen
22
App Stores, iOS und Android
44
Pipeline-Stufen bis Produktion
Eine ganze Familie von Retail-Banking-Apps im App Store und bei Google Play, inklusive Multi-Banking mit Konten anderer Banken. Ich habe die Pipelines gebaut, die sie bauen, härten, signieren und ausliefern, in einer der am stärksten regulierten Branchen überhaupt.
So bin ich vorgegangen
Mehrstufige Pipelines (Dev, PoC, QA, Prod), die die iOS- und Android-Apps bauen, signieren und an TestFlight, App Store, Firebase, Google Play und SauceLabs ausliefern
Multi-Banking in der App: Konten und Umsätze anderer Banken direkt neben den eigenen, ausgeliefert über dieselben Pipelines
App-Härtung mit Promon und automatische MobSF-Security-Scans in jeder Pipeline
Nightly Builds, die Breaking Changes früh erkennen
Versionskompatibilität zwischen Backend, Web und Mobile, mit Rollback ohne Downtime
Ergebnis: Release-Zyklen rund 40 % schneller, in einem stark regulierten Umfeld.
Eine regulatorisch relevante Anwendung zur Tuning-Erkennung musste auf Azure Kubernetes Service umziehen, ohne eine einzige Kontrolle zu lockern. Alles kam als Code, mit Leitplanken, die für jedes Team gelten.
So bin ich vorgegangen
Die regulatorisch relevante Tuning-Erkennungs-Applikation nach Azure Kubernetes Service migriert, komplett in Terraform
Azure Policies und Blueprints, die Security-Baselines und Netzwerkregeln über alle Teams durchsetzen
Observability mit Azure Monitor, Defender und Grafana
Kostenkontrollen und eine Tagging-Strategie, damit jeder Euro einen Owner hat
Ergebnis: Cloud-Kosten rund 25 % tiefer, mit Security-Baselines, die als Code über alle Teams durchgesetzt werden.
Stack: Azure AKS, Terraform, Azure Policy, Azure Blueprints, Azure Monitor, Microsoft Defender for Cloud, Grafana
Sensible Gesundheitsdaten zwischen zwei öffentlichen Systemen, keiner verloren
Rolle: Cloud Engineer und Vertreter des Kunden in einem interkantonalen Steuerungsgremium
00
verlorene Datensätze
22
öffentliche Gesundheitssysteme verbunden
Zwei öffentliche Gesundheitssysteme mussten hochsensible Datensätze zuverlässig austauschen. Ich habe die Serverless-Middleware dazwischen gebaut und den Kunden im Steuerungsgremium vertreten, das die Releases mit den anderen Kantonen plante.
So bin ich vorgegangen
Serverless-Middleware auf Azure Functions (TypeScript), die hochsensible Datensätze zwischen zwei öffentlichen Gesundheitssystemen überträgt
Azure Queue Storage zwischen den Systemen: Ist eine Seite nicht erreichbar, warten die Datensätze in der Queue, statt verloren zu gehen
Erst Stellvertreter, dann Vertreter des Kunden in einem interkantonalen Steuerungsgremium
Release-Planung über die Kantone hinweg, damit Änderungen auf beiden Seiten gemeinsam live gingen
Ergebnis: Kein einziger Datensatz ging zwischen den beiden Systemen verloren.
ERP ⇄ CRM in beide Richtungen synchron, während beide Systeme live blieben
Rolle: Synchronisation von A bis Z gebaut
2-way2-way
Sync, ERP ⇄ CRM
22
Systeme durchgehend live
Der Vertrieb arbeitete in HubSpot, Finanzen und Projekte in Maconomy, und niemand konnte für einen Big-Bang-Umstieg pausieren. Ich habe eine bidirektionale Synchronisation gebaut, damit beide Systeme mit denselben Daten im Live-Betrieb blieben.
So bin ich vorgegangen
Bidirektionale Synchronisation zwischen Maconomy (ERP) und HubSpot (CRM)
Beide Systeme blieben die ganze Zeit im Live-Betrieb, kein Big-Bang-Umstieg
Änderungen fliessen in beide Richtungen, Vertrieb und Finanzen arbeiten mit denselben Kundendaten
Ergebnis: Ein Kundendatensatz über ERP und CRM hinweg, ohne eines der Systeme anzuhalten.
Rolle: Entwickler: Spring-Boot-Backend und native Apps
33
Teile: Backend, Android- und iOS-App
ISO 27001 zu bekommen und zu halten heisst: eine lange Liste von Controls und die Nachweise zu jedem davon. Dieses Tool gab den Mitarbeitenden einen Ort dafür: ein Spring-Boot-Backend und native Android- und iOS-Apps.
So bin ich vorgegangen
Spring-Boot-Backend mit REST-APIs für Controls, Nachweise und deren Status
Native Android- und iOS-Apps, damit Mitarbeitende Controls und Nachweise von überall verwalten
Ein Ort für die ganze Zertifizierung statt Tabellen und geteilter Ordner
Ergebnis: Controls und Nachweise an einem Ort, im Alltag von den Mitarbeitenden genutzt.
