Eine Kursplattform mit Zahlungen, geschütztem Video und einem Audit gegen mich selbst

Warum nicht einfach eine fertige Plattform

Es gibt Plattformen, auf denen man Onlinekurse verkaufen kann. Sie nehmen dafür einen Umsatzanteil und stellen sich zwischen die Anbieterin und ihre Kundinnen: Die Kundendaten gehören der Plattform, die Kommunikation läuft über sie, und der Preis steigt mit dem Erfolg.

Bei einem Kursangebot mit überschaubarem, aber regelmäßigem Umsatz ist das eine laufende Belastung — und der Kundenkontakt ist bei einer Kursleiterin das eigentliche Kapital. Deshalb eine eigene Plattform.

Das ist ausdrücklich keine allgemeine Empfehlung. Bei unklarer Nachfrage oder sehr wenigen Verkäufen ist die fertige Plattform die günstigere Antwort.

Die vier Entscheidungen, die alles andere bestimmt haben

Vor der ersten Zeile Code standen vier Entscheidungen, jede mit Alternativen und Begründung schriftlich festgehalten: Videoanbieter, Backend-Plattform, Deployment und Zahlungsabwicklung.

Die interessanteste ist die zum Video. Videos selbst auszuliefern ist technisch möglich und praktisch eine schlechte Idee — Umkodierung in mehrere Qualitäten, Auslieferung an mobile Verbindungen, Bandbreitenkosten. Also ein spezialisierter Anbieter mit Standort Frankfurt.

Die eigentliche Frage war der Schutz. Kopierschutz ist umgehbar und bestraft zahlende Kundinnen. Die Lösung liegt eine Ebene tiefer: Der Server signiert für jeden Abruf einen kurzlebigen Verweis. Wer eine Adresse weitergibt, gibt etwas weiter, das nach kurzer Zeit nicht mehr funktioniert.

Vier Wochen nach dem Start: das Audit gegen mich selbst

Am 04.08.2026 habe ich das laufende System systematisch geprüft — nicht den Code, den ich geschrieben hatte, sondern das, was im Produktivbetrieb tatsächlich passiert, mit echten Kundendaten und echtem Geld im System.

Drei Befunde sind dabei herausgekommen, die ich selbst gebaut hatte:

Es gab keinen Weg, eine Kundin zu löschen. Kein einziger Pfad im Produktivcode. Eine Löschanfrage nach Art. 17 DSGVO hätte die Betreiberin ohne mich nicht beantworten können — und das ist keine theoretische Situation, sondern eine E-Mail, die jederzeit kommen kann. Behoben, und zwar so, dass sie es selbst kann.

Die Sicherungen trugen Kundendaten im Klartext an einen zweiten Ort. Die automatischen Datenbanksicherungen liefen wie vorgesehen — aber E-Mail-Adressen und Kaufhistorien lagen darin unverschlüsselt.

Preisänderungen hätten die Vergangenheit überschrieben. Wer einen Kurs von 49 € auf 79 € anhebt, hätte damit auch die bereits getätigten Verkäufe rückwirkend anders aussehen lassen. Für Buchhaltung und Erstattungen ist das ein echtes Problem.

Jeder Befund ist mit Auswirkung, Einschätzung der Sicherheit und dem behebenden Commit dokumentiert.

Warum ich das öffentlich aufschreibe

Weil es der ehrlichste Teil dieser Case Study ist. Man kann sie so erzählen, dass alles von Anfang an richtig war — dann ist sie unglaubwürdig, weil so niemand arbeitet. Oder man erzählt, wie die Fehler gefunden wurden.

Der Unterschied zwischen jemandem, der Fehler macht, und jemandem, dem man ein System anvertraut, liegt nicht in der Fehlerzahl, sondern darin, ob er sie selbst sucht. Vier Wochen nach dem Livegang das eigene System gegen Datenverlust, DSGVO und Geldflüsse zu prüfen, ist keine Selbstverständlichkeit — gerade weil es unbequem ausgeht.

Dasselbe Vorgehen liegt dem SEO-Projekt für malexfotografie.de zugrunde: Auch dort hat das Abschluss-Audit einen Fehler gefunden, den ich selbst eingebaut hatte. Das ist kein Zufall, sondern die Methode.

Was noch offen ist

Nutzerzahlen und Umsatzentwicklung stehen hier bewusst nicht — sie gehören der Kundin, nicht mir. Was belegbar ist: Die Plattform läuft, sie nimmt Geld ein, und die Betreiberin kann sie ohne mich bedienen.