PodoPilot: Wie ich als Solo-Entwickler eine SaaS-Lern-App gebaut habe

Der Anstoß kam aus Gesprächen mit Auszubildenden in der Podologie. Lernstoff gibt es genug – Bücher, Karteikarten, vielleicht ein ausgedrucktes PDF. Aber eine App, die sich wirklich an der staatlichen Abschlussprüfung orientiert? Das haben mir mehrere angehende Fachkräfte bestätigt: So etwas gibt es schlichtweg nicht.

Da war der Aufhänger. Kein „Wir disrupten Healthcare“, sondern ein konkretes Loch: Podologie-Auszubildende bereiten sich auf die Prüfung nach PodAPrV vor – und die digitale Welt bietet im Grunde nichts, was diesen Anspruch trägt. Ich dachte: Wenn ich schon Code schreibe, dann baue ich etwas, das Prüfungsnähe hat, nicht nur hübsche Karteikarten. Die Idee wurde zu PodoPilot: eine Lern-App mit echter Fragendatenbank, Prüfungssimulation und KI – aber mit klaren Grenzen, was die KI darf und was nicht.

Der Zeitrahmen war bewusst ambitioniert: In etwa acht Wochen wollte ich von Rohidee zu einer installierbaren Beta kommen – inklusive Auth, Cloud-Sync und einem ersten KI-Feature, das nicht nur Spielerei ist. Nicht, weil ich an Wunder glaube, sondern weil moderne Toolchains genau dafür da sind: schnelle Builds, klare Fehler, wenig Boilerplate. Der Rest war Disziplin und sehr viele Abende am Laptop.

Das Problem: 612 Fragen, die niemand digital gestellt hat

Die Abschlussprüfung nach PodAPrV §5 ist strukturiert: Der Prüfungskatalog des ISB gliedert den Stoff in 15 Kategorien, verteilt auf drei Prüfungsgruppen. Wer nur oberflächlich lernt, scheitert – wer nur Multiple-Choice übt, wird im echten Raum überrascht.

Denn in der Realität zählt oft Freitext. Nicht „Welche Antwort ist richtig? A, B, C oder D?“, sondern: Formuliere die Antwort. Erkläre den Zusammenhang. Benenne Schritte. Genau hier scheitern die meisten generischen Lern-Apps: Sie optimieren für „Tippen auf die richtige Antwort“, nicht für Prüfer:innen im Raum.

Bestehende Ressourcen bleiben analog-lastig: Lehrbücher, Zettelkästen, vielleicht ein geteilter Ordner. Das ist nicht falsch – aber es skaliert schlecht, gibt keinen strukturierten Fortschritt über Geräte hinweg und keine sofortige Rückmeldung außer „frag mal die Kollegin“.

Wer die ISB-Struktur einmal gesehen hat, versteht, warum „eine App mit ein paar Quizfragen“ nicht reicht: Du musst Kategorien sauber trennen, Gewichtungen im Kopf behalten und vor allem Formate mischen – sonst trainierst du ein anderes Gehirn als das, das am Prüfungstag aktiv ist. Genau deshalb war mir der Freitext-Modus kein Nice-to-have, sondern Kern des Produkts.

Ich habe mir bewusst keine halb-automatischen Scraping-Pipelines von fragwürdigen Quellen gebaut. Stattdessen: ein eigener Fragenkorpus, den ich erweitern und korrigieren kann. Das ist langsamer, aber verantwortbar. In einem Feld, in dem Begriffe präzise sein müssen, ist „schnell generiert“ ohne Review gefährlich.

Die Fragendatenbank: Von 0 auf 612!

Ich habe realistisch mit den Themen begonnen, die ich am besten validieren konnte: Anatomie (77 Fragen) und Bewegungsapparat (124 Fragen) – zusammen 201 Einträge mit sauberer Struktur, Musterlösung und Erklärungstext. Der Rest der 15 Kategorien kam schrittweise dazu, mit strengen redaktionellen Vorgaben: Fachbegriffe, sachliche Antworten, keine Marketing-Sprache.

Jede Frage enthält einen festen Satz an Bausteinen: die Frage selbst, vier Lernmodus-Optionen (eine korrekt), eine Modellantwort für Freitext-Vergleiche und einen Erklärungstext. Pro Fachbereich kann ich Inhalte einzeln aktualisieren, ohne den ganzen Datenbestand anzufassen.

Bias-Falle – oder: Warum fast alle MC-Fragen kaputt waren

Hier wird es peinlich und lehrreich zugleich. Nach dem ersten großen Generierungslauf habe ich die Daten statisch angeschaut – nicht mit einem cleveren Test, sondern mit der dümmsten Heuristik, die mir eingefallen ist: Ist die richtige Antwort zufällig die längste?

Ergebnis: In etwa 95 % der Fälle war die korrekte Option die längste. Jede vernünftige Lernstrategie hätte gelautet: „Nimm immer den längsten Satz.“ Die App wäre damit wertlos geworden – nicht medizinisch, sondern methodisch.

Endstand nach Review: 612 Fragen, 15 Kategorien, jeweils mit Erklärung und Modellantwort. Nie wieder nehme ich an, automatisch generierte MC-Optionen seien von selbst fair verteilt.

Review-Workflow statt „einmal generieren und fertig“

Für jede neue Kategorie habe ich einen festen Ablauf eingehalten: Stichprobe lesen, Begriffe gegen Lehrbuch-Sprache checken, auffällige Formulierungen markieren, dann gezielt nachschärfen. Wo ich unsicher war, habe ich nachgefragt – bei Fachthemen ist „klingt plausibel“ die gefährlichste Falle.

Für die Beta reicht mir ein einfacher redaktioneller Workflow: Inhalte sind diffbar und versionierbar, eine eigene Verwaltungsoberfläche ist später geplant, aber kein Beta-Blocker.

Parallel habe ich IDs und Kategorie-Slugs so gewählt, dass sich spätere Übersetzungen oder Zusatzmodule (z. B. reine Anatomie-Pakete) ohne Umbenennungs-Höllen einhängen lassen. Vorausdenken kostet am Anfang zehn Minuten pro Frage – und spart später Wochen.

Lernmodus vs. Prüfungssimulation

Im Lernmodus bleibt alles klassisch: vier Optionen, sofortiges Feedback, danach die Erklärung. Das ist für Durchsatz und Wiederholung ideal.

Die Prüfungssimulation spiegelt die Realität: Freitextfeld, Timer (konfigurierbar, z. B. 60 oder 90 Minuten), 40 Fragen pro Prüfungsgruppe entsprechend dem gewählten Setup. Wer alle drei Gruppen am Stück fahren will, bekommt dazwischen Pause-Screens – psychologisch nützlich und nahe am Gefühl eines echten Prüfungstags.

Die Auswertung im Simulationsmodus ist bewusst regelbasiert: Die App vergleicht die Antwort des Auszubildenden mit den Schlüsselbegriffen aus der Modellantwort. Trefferquote ≥ 55 % → bestanden, 25–54 % → teilweise, darunter nicht bestanden. Kein Warten auf eine Cloud-Antwort, keine zufälligen Bewertungs-Schwankungen bei „War das jetzt richtig genug?“

Das ersetzt keine menschliche Prüferin – aber es gibt vergleichbare, reproduzierbare Rückmeldung für Selbsttests. Für echtes Feedback auf Formulierung und Fachlogik kommt die KI im Prüfer-Modus ins Spiel.

Sonderfälle habe ich bewusst simpel gehalten: Sehr kurze Antworten, reine Aufzählungen oder Tippfehler bei Fachbegriffen können die Quote drücken – das ist okay, weil der Modus trainieren soll, nicht rechtlich verbindlich bewerten. Wer nur drei Wörter schreibt, obwohl die Modellantwort einen zusammenhängenden Absatz erwartet, bekommt ehrlich ein schlechteres Signal. Genau das wollte ich: keine künstliche Gnade durch ein LLM im Simulationspfad.

Die komplette Dreier-Fahrt (über alle Prüfungsgruppen mit Pausen dazwischen) ist psychologisch nüchterner, als sie klingt. Wer das einmal durchzieht, weiß ungefähr, wie sich Zeitdruck und Themensprünge anfühlen – auch wenn der Raum am Ende nur das eigene Wohnzimmer ist.

KI als Prüfer, nicht als Fragenerfinder

Das ist die wichtigste Architektur-Entscheidung des Projekts: Alle Prüfungsfragen kommen aus der kuratierten Datenbank. Deterministisch. Versionierbar. Ohne „das Modell hat gerade eine neue Krankheit erfunden“.

Die KI darf zwei Dinge: Im Chat-Assistenten allgemein helfen (Fachfragen, Lernplan, Erklärungen im Rahmen). Im Prüfer-Modus (0.2.0) zieht die App eine echte Frage aus derselben Datenbank, der Auszubildende antwortet frei, und das Modell bewertet pädagogisch: Was war gut? Was fehlt? Wo liegt der Kern der Musterlösung? Anschließend zeige ich immer die Modellantwort an – damit niemand nur auf „KI sagt okay“ vertraut.

Genau so lässt sich Medizin- und Prüfungsnähe mit moderner KI verbinden, ohne die Verantwortung für den Fragenkatalog an ein LLM abzugeben.

Operativ heißt das: Ich achte auf sinnvolle Nutzungsgrenzen, Timeouts und klare Hinweise, wenn die KI gerade nicht erreichbar ist. Der Prüfer-Modus ist bewusst kein Dauerfeuer; er soll qualitativ helfen, nicht jeden Fingertipp monetarisieren. Für die Beta habe ich die Nutzungsgrenzen großzügig gesetzt, damit echtes Feedback kommt, nicht optimiertes Klickverhalten.

Cloud-Fortschritt und Auth

Der Lernfortschritt liegt nicht lokal auf dem Gerät, sondern wird verschlüsselt synchronisiert – wer die App neu installiert oder das Gerät wechselt, hat seine Daten weiterhin. Wer vor dem Login schon offline gelernt hat, bekommt seine Daten beim ersten Anmelden automatisch übernommen. In der UI visualisiere ich den Fortschritt pro Kategorie mit farbcodierten Balken – schneller Scan, welches Fach hinten runterfällt.

Beta-Phase und Preismodell

In der Beta-Phase sind alle Pro-Funktionen kostenlos – ich will echtes Feedback aus dem Lernalltag, nicht eine Paywall vor dem ersten Fehlerbericht.

Geplant ist ein einfaches Modell: Free mit drei Kategorien und begrenzter KI-Nutzung, Pro mit vollem Zugang für 2,99 € pro Monat oder 19,99 € pro Jahr. Die Preise sind transparent und fair – der echte Wert liegt für mich in wiederkehrendem Lernen bis zur Prüfung, nicht in Einmal-Klicks.

Die Landingpage unter podopilot.de mit Warteliste ist bereits online. Wer neugierig ist, kann sich dort eintragen; Feedback kommt mir direkt zugute für die Roadmap.

Was ich gelernt habe

1. Solo-App-Entwicklung ist heute machbar — kurze Iterationszyklen, von der Idee zum Test-Build auf dem Gerät in Minuten statt Tagen.
2. Medizinische Bildung verträgt kein „mal schnell generieren und shippen“: Jede Frage will Plausibilität, jede automatische Ausgabe braucht klare Grenzen.
3. Produktbau ist anders als Kundenauftrag: Du triffst jede Priorisierung selbst. Befreiend und anstrengend zugleich.

PodoPilot ist das erste Mal, dass ich nicht nur „für jemanden“ baue, sondern Verantwortung für ein ganzes Ökosystem aus Content, UX und Rechtlichem trage – und trotzdem jeden Morgen Lust habe, weiterzucoden.

Nächste Schritte

Wenn du die App verfolgen willst: podopilot.de – Warteliste, Updates, irgendwann der Store-Link.

Du hast eine App-Idee? Lass uns reden. Ich baue lieber Lösungen mit messbarem Nutzen als Folien mit Superlativen.