Fallstudie: CodeFlash, ein Lernprodukt von der Idee bis zum Betrieb

CodeFlash ist ein eigenes Produkt von Lechner Studios, kein Kundenauftrag. Wir beschreiben es hier, weil es die Frage beantwortet, die ein Portfolio allein nicht beantwortet: Können wir ein Produkt nicht nur gestalten, sondern bauen, in Betrieb nehmen und am Laufen halten? Alles, was folgt, ist im laufenden Produkt und in seinem Quellcode nachprüfbar.

Das Problem

Technisches Wissen hält, wenn man es abruft, nicht wenn man es liest. Entwickler und Quereinsteiger lernen zwischen Projekten, in kurzen Einheiten, oft am Handy. Es fehlte ein Werkzeug, das kuratierte Kartensätze zu konkreten Themen bietet, den Abstand zwischen Wiederholungen steuert und auf Deutsch wie auf Englisch funktioniert.

Unsere Rolle

Konzept, Gestaltung, Entwicklung, Bezahlung und Betrieb kommen aus dem Studio. Das Produkt ist seit 2026 unter codeflash.lechner-studios.at live.

Was läuft

• Kartensätze zu acht Themenfeldern, von Web und Backend über Cloud und Sicherheit bis zu Daten. Die Zahl der Themen, Pakete und Karten liest die Startseite live aus der Datenbank.
• Lernen mit Spaced Repetition nach dem SM-2-Verfahren und ein Quiz-Modus. Der Fortschritt bleibt dem Konto erhalten.
• Zweisprachig, Deutsch und Englisch, in einer Oberfläche.
• Die Grundlagenpakete sind kostenlos; weitere Pakete werden über Stripe gekauft.
• Gekaufte Pakete lassen sich als eigenständige HTML-Datei herunterladen und ohne Verbindung nutzen.
• Drei Marken aus einem Code: CodeFlash, AI Flash und Mainframe Flash werden beim Bauen ausgewählt und teilen Lern-Engine, Konto und Bezahlung.

Entscheidungen, die den Betrieb bestimmen

• Eine statische Web-App auf Vercel; Daten und Anmeldung liegen bei Supabase. Es gibt keinen eigenen Server, der gepflegt werden muss.
• Die Bezahlung läuft über Stripe. Die Bestätigung einer Zahlung kommt als Webhook direkt bei einer Supabase-Funktion an, nicht in der App. So bleibt der Zahlungsweg erreichbar, auch wenn die Oberfläche im Wartungsmodus ist.
• Die Schranke vor kostenpflichtigen Inhalten schließt im Zweifel: Kann der Build nicht feststellen, welche Pakete frei sind, liefert er keine Paketinhalte aus.
• Kartensätze entstehen mit Unterstützung eines Sprachmodells und werden vor der Veröffentlichung geprüft.

Wartung

• Bei jedem Pull Request laufen Lint, Build und Tests, dazu ein Datenschutz-Scan, eine Sperre für zu große Dateien und eine Prüfung der Abhängigkeiten auf bekannte Schwachstellen.
• Jeden Montag prüfen drei automatische Läufe das laufende Produkt: Baut der Hauptzweig? Ist die Bezahlung im ausgelieferten Paket aktiv? Gibt es leere Kartenpakete? Schlägt ein Lauf fehl, wird ein Ticket im Repository geöffnet.
• Ein Wartungsmodus ist dokumentiert und mit einem einzigen Pull Request aktivierbar. Der Zahlungsweg bleibt davon unberührt.
• Änderungen stehen in einem Changelog.

Was Sie selbst prüfen können

Die Startseite zeigt die aktuellen Zahlen aus dem Katalog. Die kostenlosen Grundlagenpakete lassen sich ausprobieren. Die Beispielkarten oben stammen aus dem Produkt.

Was das für Ihr Vorhaben bedeutet

Angenommen, Sie betreiben eine Fahrschule und möchten Ihren Theoriestoff als Lernkarten mit Fortschritt und Bezahlung anbieten. Die Bausteine sind dieselben wie oben: Konto, Inhalte, Lernlogik, Bezahlung, Betrieb. Was sich ändert, sind Inhalte und Marke. Wie wir solche Anwendungen bauen, steht unter Apps & Automatisierung. Das erste Gespräch ist unverbindlich.