Fitness, Gesundheit & Clubbetrieb
Ein Studio ist kein Webauftritt, sondern ein Mitgliederbetrieb
Für die MK Fitness & Strength GmbH ist eine Clubplattform entstanden, die den öffentlichen Auftritt, den Mitgliederbereich und die Verwaltung im selben System führt: Mitglieder und Verträge, Kurse und Buchungen, Coaching und Trainingsfortschritt, Personal und Schichten, Abrechnung und Lastschrift – angebunden an die bestehende Studioverwaltung.
- Auftraggeber
- MK Fitness & Strength GmbH
- Projekt
- Nice Athletic Club
- Branche
- Fitness, Gesundheit & Clubbetrieb
- Art
- Clubplattform · Mitglieder · Kurse · Verwaltung
56 Seiten in Oberfläche und Verwaltung
61 Tabellen im Datenmodell
11.741 Zeilen Backend-Code
Die Angaben auf dieser Seite sind am Quelltext von Oberfläche und Backend, am Datenmodell und an der ausgelieferten Anwendung geprüft.
Ausgangslage
Worum es geht
Ein Fitnessstudio verkauft eine Mitgliedschaft, betreibt aber einen Alltag: Verträge laufen an und aus, Kurse werden gebucht und abgesagt, Trainingspläne entstehen, Schichten müssen besetzt sein, Beiträge müssen eingezogen werden – und all das hängt an denselben Personen.
Üblicherweise verteilt sich das auf eine Studioverwaltung, eine Kursliste, ein Tabellenblatt für den Dienstplan, ein Buchhaltungswerkzeug und eine Website, die von alldem nichts weiß. Wer eine Frage zu einem Mitglied hat, öffnet drei Systeme.
Erschwerend kommt hinzu, dass eine bestehende Studioverwaltung bereits im Einsatz ist. Sie abzulösen wäre ein Risiko ohne Not – sie zu ignorieren hieße, Stammdaten doppelt zu pflegen.
Was XINOO umgesetzt hat
- Den öffentlichen Auftritt mit Studio- und Angebotsseiten, Kursen, Preisen, Team, Karriere und Presse – redaktionell pflegbar statt fest im Code.
- Den Mitgliederbereich: Buchungen, Kurse, Coaching und Trainingspläne, Fortschrittserfassung, Vertragsübersicht und Profil.
- Die Verwaltung: Mitglieder und Verträge, Kurs- und Buchungsverwaltung, Tarif- und Preisgestaltung, Personal- und Schichtplanung, Abwesenheiten, Finanzen mit Lastschrift und Inkasso, Bewerbungen, Presse und Bewertungen.
- Die tragende Schicht: Anmeldung mit Rollen und Rechten, Protokollierung, Redaktionssystem mit Seitensichtbarkeit sowie die Anbindung an die bestehende Studioverwaltung.
Vorgehen
Was vor der ersten Zeile Code stand
Die teuersten Fehler entstehen nicht beim Programmieren, sondern davor – wenn niemand geklärt hat, welche Vorgänge das System eigentlich abbilden soll.
Bestehendes anbinden statt ablösen
Die Studioverwaltung bleibt führendes System für Kunden und Verträge. Der Entwurf sah deshalb von Anfang an eine Anbindung vor, die Daten übernimmt und abgleicht, statt einen zweiten Stammdatensatz zu erzeugen.
Drei Sichten auf dieselben Daten
Öffentlichkeit, Mitglied und Verwaltung brauchen dieselben Informationen in völlig unterschiedlicher Tiefe. Die drei Bereiche wurden getrennt entworfen und liegen auf einem gemeinsamen Datenmodell.
Was ein Abgleich falsch machen kann
Bei einer Übernahme aus einem Fremdsystem ist die eigentliche Frage nicht der Import, sondern die Zuordnung: Wann sind zwei Datensätze dieselbe Person? Dafür entstand ein eigener Schritt mit Rohdaten, Kandidaten und Entscheidung – statt einer automatischen Verschmelzung, die niemand mehr zurückdrehen kann.
Inhalte gehören dem Studio
Preise, Kurse, Team und Seiten ändern sich laufend. Sie gehören deshalb in ein Redaktionssystem und nicht in den Code – sonst braucht jede Preisänderung eine Auslieferung.
Gestaltung
Die Handschrift des Kunden, nicht die der Agentur
Eine Marke, mehrere Bereiche
Der öffentliche Auftritt folgt der Bildsprache des Studios: kräftige Typografie, großflächige Trainingsfotografie, klare Kontraste. Mitgliederbereich und Verwaltung übernehmen die Marke, treten aber deutlich nüchterner auf.
Verwaltung als Arbeitsgerät
Wer täglich Mitglieder pflegt, Kurse plant und Schichten besetzt, braucht Dichte statt Weißraum: Listen, Filter, Stapelaktionen, sichtbare Zustände. Der Verwaltungsbereich ist bewusst als Werkzeug gestaltet, nicht als Schaufenster.
Zustände sichtbar machen
Vertrag aktiv, pausiert, gekündigt; Kurs gebucht, storniert, ausgefallen; Beitrag offen, eingezogen, im Inkasso. Diese Zustände sind durchgängig gleich dargestellt, damit sich der Stand einer Sache erkennen lässt, ohne sie zu öffnen.
Zuerst das Telefon
Kurse werden unterwegs gebucht, Trainingsfortschritt im Studio erfasst. Der Mitgliederbereich ist für schmale Geräte entworfen und wächst zum Desktop hin.
Architektur
Die Entscheidungen dahinter
Nicht der Funktionsumfang entscheidet, ob ein System trägt, sondern wie es geschnitten ist.
Ein Datenmodell, drei Zugänge
Öffentlicher Auftritt, Mitgliederbereich und Verwaltung liegen in einer Anwendung auf einem Datenmodell. Die API ist entlang dieser drei Zugänge geschnitten – öffentlich, Mitglied, Verwaltung – und prüft an der Grenze, nicht in der Oberfläche.
Fremdsystem als Quelle, nicht als Abhängigkeit
Die Daten der Studioverwaltung landen zunächst unverändert in eigenen Rohdatentabellen. Erst danach werden sie zugeordnet und übernommen. Fällt das Fremdsystem aus, bleibt die Plattform arbeitsfähig.
Zuordnung als eigener Schritt
Zwischen Rohdaten und Stammdaten steht eine Kandidatenliste: Welche Datensätze könnten dieselbe Person sein? Die Entscheidung trifft ein Mensch. Eine automatische Verschmelzung wäre schnell – und im Fehlerfall nicht mehr auflösbar.
Inhalte als Daten
Seiten, Bausteine und deren Sichtbarkeit liegen in der Datenbank. Eine Seite lässt sich vorbereiten und später sichtbar schalten, ohne dass etwas ausgeliefert werden muss.
Systemaufbau
Von außen nach innen
Die Ebenen des Systems in der Reihenfolge, in der eine Anfrage sie durchläuft.
Öffentlichkeit
Studio- und Angebotsseiten, Kurse, Preise, Team, Karriere und Presse – redaktionell gepflegt.
Mitglied
Eigener Bereich für Buchungen, Kurse, Coaching, Trainingsfortschritt und Vertrag.
Verwaltung
Mitglieder, Verträge, Tarife, Kurse, Personal, Finanzen, Inhalte und Auswertung.
Zugriffsschicht
Anmeldung, Rollen und Rechte, Protokollierung – geprüft an jeder API-Grenze, nicht in der Oberfläche.
Daten und Anbindung
61 Tabellen, dazu Rohdaten und Abgleichkandidaten der angebundenen Studioverwaltung.
Funktionen
Was das System kann
Gruppiert nach Bereichen. Die Aufstellung ist die Antwort auf die Frage, wie groß das Vorhaben tatsächlich war.
Mitglieder und Verträge
- Mitgliederverwaltung mit Notizen
- Verträge und Vertragsarten
- Mitgliedschaftsmodelle
- Pausen und Kündigungen
- Anwesenheitserfassung
- Anträge und Vorgänge
Training und Kurse
- Kursverwaltung und Kursbuchung
- Buchungsverwaltung
- Coaching-Anfragen und Trainingspläne
- Trainingsfortschritt und Körperwerte
- Ernährungsziele und -protokoll
- Probetraining und Personal Training
Preise und Abrechnung
- Tarife und Zusatzleistungen
- Preisseite mit Vergleich und Hinweisen
- Rechnungen und Zahlungsvorgänge
- SEPA-Mandate und Lastschrift
- Inkassovorgänge
- Firmenfitness und Wellpass-Angebote
Personal und Betrieb
- Personalverwaltung und Teamprofile
- Schichtplanung und Einsatzplan
- Schichttausch-Anfragen
- Abwesenheiten und Urlaubskonten
- Bewerbungen und Stellenanzeigen
- Aufgaben im Arbeitsablauf
Inhalte und Außenwirkung
- Redaktionssystem für Seiten und Bausteine
- Seitensichtbarkeit steuerbar
- Seiteneditor
- Presseartikel und Magazin
- Bewertungen mit automatischem Abruf
- Interessenten und Anfragen
Zugriff, Anbindung, Nachvollziehbarkeit
- Anmeldung mit Rollen und Rechten
- Rechte je Zugang zusätzlich vergebbar
- Anbindung an die bestehende Studioverwaltung
- Rohdatenübernahme mit Abgleichkandidaten
- Protokoll sicherheitsrelevanter Vorgänge
- Systemprüfung und Diagnose
Technik
Womit es gebaut ist
Oberfläche
Anwendungsschicht
Daten
Angebunden
Integration
Was angebunden ist – und was nicht
Die Plattform bindet die bestehende Studioverwaltung Magicline an: Kunden- und Vertragsdaten werden zunächst unverändert in eigene Rohdatentabellen übernommen, dann über eine Kandidatenliste zugeordnet und erst danach in die Stammdaten überführt. Die Übernahme lässt sich vorab ansehen, bevor sie ausgeführt wird. Ergänzend angebunden sind der Abruf von Google-Bewertungen, der Mailversand über eigene SMTP-Einstellungen und die Lastschrift.
Sicherheit & Zugriff
Sicherheit ist Teil des Entwurfs
Wer Zugriffsrechte nachträglich einzieht, baut Ausnahmen. Wer sie vorher entwirft, baut eine Struktur.
Rechte an der API-Grenze
Die API prüft an 45 Stellen die Anmeldung, an 26 Stellen ein konkretes Recht und an 20 Stellen die Verwaltungsrolle. Die Prüfung liegt im Backend – eine ausgeblendete Schaltfläche ist Bequemlichkeit, kein Schutz.
Rollen und zusätzliche Rechte getrennt
Rechte hängen an der Rolle, lassen sich einem einzelnen Zugang aber zusätzlich gewähren. Damit braucht eine Ausnahme keine neue Rolle – und keine Vergabe der Verwaltungsrolle „nur für diese eine Sache".
Getrennte Zugänge für öffentlich, Mitglied und Verwaltung
Die API ist in drei Bereiche geschnitten. Ein Mitgliederzugang erreicht die Verwaltungsendpunkte nicht, weil sie in einem anderen Bereich liegen und dort erneut geprüft werden.
Datenbankzugriffe durchgängig gebunden
Sämtliche Abfragen laufen über vorbereitete Anweisungen mit gebundenen Werten – 319 Stellen im Backend. Eingaben werden dadurch als Werte behandelt, nicht als Bestandteil der Abfrage.
Kennwörter als Prüfwert, Sitzungen als Token
Kennwörter werden ausschließlich als Prüfwert gespeichert. Sitzungen laufen über signierte Token mit begrenzter Gültigkeit.
Protokollierung
Sicherheitsrelevante Vorgänge werden in einem eigenen Protokoll festgehalten und sind in der Verwaltung einsehbar.
Woran sich die Umsetzung orientiert
- Secure by Design – die Trennung in öffentlich, Mitglied und Verwaltung ist Teil des API-Schnitts, nicht der Oberfläche
- Least Privilege – Rechte hängen an der Rolle und lassen sich einzeln ergänzen, statt die Verwaltungsrolle zu vergeben
- Defense in Depth – Anmeldung, Rechteprüfung, gebundene Abfragen und Protokoll greifen unabhängig voneinander
- An OWASP-Grundsätzen orientierte Anwendungssicherheit bei Authentifizierung, Eingabebehandlung und Zugriffskontrolle
Diese Grundsätze beschreiben die Arbeitsweise. Sie sind keine Zertifizierung und werden hier auch nicht als solche dargestellt.
Was geprüft wurde
- Für das Projekt liegt eine dokumentierte Sicherheitsprüfung vor, die Geheimnisse und personenbezogene Daten im Quelltextbestand untersucht und in einen Behebungsplan mit Rotationsreihenfolge überführt hat.
- Am Quelltext nachvollziehbar sind: 319 gebundene Datenbankabfragen, Kennwortspeicherung als Prüfwert, signierte Sitzungstoken, dreifach getrennte API-Bereiche sowie ein Protokoll sicherheitsrelevanter Vorgänge.
- Eine formale Zertifizierung ist damit nicht verbunden und wird nicht behauptet.
Stand
Was läuft, was noch nicht
Ein Projekt ist selten an einem Stichtag fertig. Der Stand steht hier, weil er zur Sache gehört.
Die Plattform ist entwickelt und im Betrieb: öffentlicher Auftritt, Mitgliederbereich und Verwaltung laufen gegen das Produktivbackend.
Die Anbindung an die bestehende Studioverwaltung ist umgesetzt – mit Rohdatenübernahme, Abgleichkandidaten und Vorschau vor der Ausführung.
Redaktionssystem, Tarif- und Preisgestaltung, Kurs- und Buchungsverwaltung, Personal- und Schichtplanung sowie Abrechnung mit Lastschrift sind entwickelt.
Die Verschlüsselung der Lastschriftdaten ist vorbereitet und wird vor der produktiven Nutzung dieses Bereichs scharf geschaltet.
Öffentlich erreichbar unter www.nice-fitness.de (öffnet in neuem Tab).
Verwandte Themen
Weiterlesen
Ein vergleichbares Vorhaben?
Schildern Sie die Ausgangslage. Wir ordnen ein, welche Ebene zuerst dran ist und ob dafür ein Produkt, eine Integration oder eine Entwicklung das richtige Mittel ist.