Ein neuer Anfang: Warum wir Xircuit bauen

Foto: Rawpixel (CC0 1.0), via Openverse

Es gibt eine Sorte Software, die von außen simpel wirkt und im Inneren erstaunlich komplex ist: die Verwaltung von Menschen. Ein Fitnessstudio führt Mitgliederlisten, ein Verein pflegt Beiträge, eine Arztpraxis hält Termine und Befunde. Auf dem Papier klingt das nach demselben Problem — bis man merkt, dass jede dieser Branchen ihre eigene Sprache, ihre eigenen Regeln und ihre eigenen Datenschutz-Anforderungen mitbringt. Genau an dieser Stelle setzt Xircuit an.

Dieser erste Beitrag in unserer Dev-Log-Serie erklärt das Warum. Nicht das Wie im Detail — das kommt in den nächsten Wochen. Sondern die Motivation dahinter und die technischen Grundentscheidungen, die am Anfang stehen und alles Weitere prägen.

Ein Problem, das viele teilen

Über die Jahre habe ich immer wieder dieselbe Szene gesehen. Ein kleiner Betrieb — ein Studio, eine Praxis, ein Salon — jongliert mit einer Tabellenkalkulation für die Mitglieder, einem separaten Kalender für Termine, einem Kartenterminal für Zahlungen und im schlimmsten Fall einem Zettel an der Tür für den Einlass. Jedes Werkzeug für sich funktioniert, aber zwischen ihnen klaffen Lücken, in denen Daten doppelt gepflegt werden und Fehler entstehen.

Xircuit ist als All-in-one-Plattform für Mitglieder- und Gesundheitsdaten gedacht, die diese Lücken schließt. Und zwar nicht für eine Branche, sondern für sieben: Fitnessstudios, Personal Trainer, Arztpraxen, Vereine, Spas sowie Friseur- und Kosmetiksalons. Das ist ein bewusst breiter Anspruch, und er bringt eine unbequeme Frage mit sich — kann eine einzige Plattform so unterschiedlichen Betrieben gerecht werden, ohne für jeden von ihnen halbgar zu sein?

Warum sieben Branchen und nicht eine

Die naheliegende Antwort wäre gewesen, sich auf Fitnessstudios zu konzentrieren und alles andere später zu betrachten. Ich habe mich bewusst dagegen entschieden, weil der gemeinsame Kern dieser Betriebe viel größer ist, als es zunächst scheint. Wer genau hinsieht, findet in allen sieben Branchen dieselben fünf Bausteine wieder.

• Mitglieder verwalten — vom ersten Kontakt über die Stammdaten bis zur Historie.
• Termine buchen — ob Trainingsstunde, Sprechstunde, Behandlung oder Vereinsveranstaltung.
• Gesundheitsdaten sicher einbinden — dort, wo die Branche es erfordert und erlaubt.
• Abrechnen — Beiträge, Pakete, Einzelleistungen.
• Einlass steuern — die Tür, das Drehkreuz, der Check-in.

Der Unterschied zwischen einem Fitnessstudio und einer Arztpraxis liegt nicht in diesen Bausteinen selbst, sondern darin, wie sie gewichtet und kombiniert werden. Ein Studio braucht Einlasssteuerung und Abrechnung ganz vorne; eine Praxis rückt Termine und den sensiblen Umgang mit Gesundheitsdaten in den Mittelpunkt. Wenn man den Kern richtig baut, ist die Branche am Ende eine Frage der Konfiguration — nicht eine Frage von sieben getrennten Produkten.

Eine Codebase, sechs Plattformen

Die zweite Grundentscheidung betrifft die Technik unter der Oberfläche, und sie ist ebenso weitreichend. Xircuit läuft auf einer einzigen .NET-10-Blazor-Hybrid-Codebase mit MAUI. Aus diesem einen Fundament liefern wir Web, Windows, macOS, iOS, iPadOS und Android.

Das ist kein Kompromiss, den man aus Bequemlichkeit eingeht. Blazor Hybrid mit MAUI ist inzwischen reif genug, dass wir auf allen sechs Plattformen eine gute Performance und ein natives Gefühl erreichen, ohne die Logik mehrfach zu schreiben. Wir setzen bewusst kein React Native ein, kein Flutter, kein separates Swift für Apple-Geräte. Der Empfangstresen im Studio, das iPad an der Rezeption und das Smartphone des Mitglieds greifen auf dieselbe Codebase zu. Eine Regel, die für die Terminbuchung gilt, gilt überall — weil sie nur an einer Stelle existiert.

Gerade bei Gesundheitsdaten ist diese Eigenschaft mehr als ein Entwicklungsvorteil. Eine einzige Codebase bedeutet eine einzige Stelle, an der Zugriffsregeln und Datenschutz durchgesetzt werden. Es gibt keine zweite, leicht abweichende Implementierung auf dem Handy, die man vergisst mitzupflegen.

Foto: Khusen Rustamov · StockSnap (CC0 1.0), via Openverse

Der lokale Motor: .NET Aspire

Eine Plattform, die Mitglieder, Termine, Zahlungen, Suche und Einlass verbindet, besteht aus vielen beweglichen Teilen. Im Betrieb sind das eine API, eine Datenbank, ein Message-Bus für asynchrone Abläufe, ein Blob Storage für Dateien und ein Suchindex. Solche verteilten Systeme sind berüchtigt dafür, dass allein das lokale Hochfahren zur Geduldsprobe wird.

Genau dieses Problem nimmt uns .NET Aspire ab. Aspire orchestriert die gesamte lokale Entwicklungsumgebung: API, Datenbank, Service Bus, Blob Storage und Suche starten mit einem einzigen Befehl, sauber verdrahtet und mit einem Dashboard, das zeigt, was gerade passiert. Das klingt nach einem Detail für Entwickler, ist aber in Wahrheit ein Hebel für die Geschwindigkeit des ganzen Projekts. Wer eine Idee in Minuten statt in einer halben Stunde ausprobieren kann, probiert mehr aus — und trifft am Ende bessere Entscheidungen.

Betrieb, Anmeldung und Geheimnisse

Was lokal gut funktioniert, muss in der Produktion verlässlich laufen. Für den Betrieb setzen wir auf Azure Container Apps. Das gibt uns eine Umgebung, die mit der Last mitwächst, ohne dass wir Server von Hand pflegen müssen, und die zu der containerbasierten Struktur passt, die Aspire ohnehin nahelegt.

Bei zwei Bausteinen wollte ich von Anfang an nichts selbst erfinden, weil Fehler hier besonders teuer sind. Die Authentifizierung übernimmt Auth0 — die Frage, wer jemand ist und worauf er zugreifen darf, ist bei Gesundheitsdaten die heikelste überhaupt, und sie gehört in die Hände eines spezialisierten Anbieters. Alle Geheimnisse, von Datenbank-Verbindungen bis zu API-Schlüsseln, liegen in Azure Key Vault statt in Konfigurationsdateien. Keine Zugangsdaten im Code, kein Passwort in einem Repository. Diese beiden Entscheidungen sind unspektakulär, und das ist genau ihr Zweck: Sicherheit soll langweilig und selbstverständlich sein.

Was dieses Fundament tragen soll

Wenn ich die Teile zusammenfüge, ergibt sich ein klares Bild. Ein gemeinsamer Kern aus fünf Bausteinen — Mitglieder verwalten, Termine buchen, Gesundheitsdaten sicher einbinden, abrechnen, Einlass steuern — wird je nach Branche unterschiedlich zusammengesetzt. Darunter arbeitet eine einzige Codebase, die sechs Plattformen bedient, lokal von Aspire orchestriert und in der Cloud auf Azure Container Apps betrieben, abgesichert durch Auth0 und Key Vault.

Nichts davon ist für sich genommen revolutionär. Die Wette liegt in der Kombination und in der Disziplin, den Kern sauber zu halten, statt für jede neue Branche eine Abkürzung einzubauen. Ob diese Wette aufgeht, wird sich in den nächsten Monaten zeigen — und dieser Dev-Log begleitet den Weg dorthin ehrlich, mit den Entscheidungen, den Abwägungen und den Stellen, an denen wir uns noch nicht sicher sind.

Was kommt als Nächstes?

Nächste Woche: warum Identität die heikelste Grundlage überhaupt ist, wenn man mit Gesundheitsdaten arbeitet — und wie Auth0 dieses Fundament trägt.