Lehrbericht

Wie ich keinen Bock mehr hatte und mir die bestehenden Lösungen nicht gefallen haben.

Lehrbericht

Das Ausbildungsbericht-Problem in Zahlen

1x
Wöchentlich Handschrift entziffern
50%+
Potenzielle Zeitersparnis
50%
Qualitativ verbesserungswürdig

Es ist ein leidiges Thema,


die Pflicht zum Berichte führen. Für die wenigsten dienen sie noch dem eigentlichen Zweck, die Qualität der Ausbildung hochzuhalten. Sie werden schlampig geführt, zu spät nachgeschrieben, irgendetwas wird geschrieben, statt zu reflektieren: Was habe ich gelernt?

Es gibt digitale Lösungen, aber keine hat mich überzeugt also versuche ich mich derzeit selbst daran.

Als Ausbilder in verschiedenen Rollen - Betrieb, selbständiger Dozent, Bildungsträger - habe ich das jahrelang miterlebt.

Die klassischen Probleme

Azubi: "Hab ich vergessen" oder "Ist zu Hause"
Ausbilder: 10 Minuten Handschrift entziffern
IHK-Prüfung: "Wo sind die Berichte?"
Also weg damit, neu schreiben.

Privacy-First bedeutet vor allem eins: alles dauert länger.


Dann stand die Frage im Raum: Wie baue ich so etwas richtig?

Also machte ich mich an die Arbeit. Ich musste erst mal die Grundlagen schaffen, viele neue Themen, mit denen ich mich das erste Mal auseinandergesetzt habe:

Wie setzt man einen Server auf und administriert ihn sicher?

Wie entwickelt man ein Backend, das auch bei Nutzungsspitzen stabil bleibt?

Wie sorgt man für echte Sicherheit?

Wie erkennt man sofort, wenn etwas schiefläuft?

Fragen über Fragen – und das alles nebenberuflich. Oft hatte ich das Gefühl, niemals alles wissen zu können. Und ein Stück weit stimmt das auch. Das musste ich aber erst noch lernen.

Privacy-First vs. Entwicklungsgeschwindigkeit

Firebase Route (schnell & problematisch)

Entwicklungszeit Sofort
Datenschutz Fragwürdig
Kontrolle Gering

Schnell, einfach, aber Azubi-Daten auf US-Servern? Nein danke.

Privacy-First Route (langsam & richtig)

Entwicklungszeit 6+ Monate
Datenschutz Perfekt
Kontrolle Vollständig

Länger, komplexer, aber Daten bleiben wo sie hingehören: In Deutschland.

Swift Smooth vs. Flutter Cursed: Ein Code-Vergleich


Dann ging es weiter, wie werde ich die App umsetzen? Swift und Kotlin hatte ich gelernt, aber möchte ich jede App zweimal schreiben? Also habe ich mir React Native und Flutter angeschaut, beide von der Herangehensweise in meinen Augen absolut cursed, für mich war der Goldstandard immer noch Swift. Aber die Vernunft obsiegte, ich setzte mich mit Flutter auseinander und baue jetzt meine Mobile-Projekte nur noch damit. Gelegentlich brauche ich noch Swift/Kotlin für Plattform-Channel.

Hier ein kleiner Vergleich: Beide sollen eine View darstellen mit einem Schalter und Text:

Swift Smooth vs. Flutter Cursed

Swift - Wie Butter 

struct ReportCard: View {
  @State var title = "Lehrbericht"
  @State var isCompleted = false

  var body: some View {
    VStack {
      Text(title)
      Toggle("Fertig", isOn: $isCompleted)
    }
  }
}

✨ Clean, elegant, intuitiv

Flutter - Eigen 

class ReportCard extends StatefulWidget {
  @override
  _ReportCardState createState() => _ReportCardState();
}

class _ReportCardState extends State<ReportCard> {
  String title = 'Lehrbericht';
  bool isCompleted = false;

  @override
  Widget build(BuildContext context) {
    return Column(children: [
      Text(title),
      Switch(
        value: isCompleted,
        onChanged: (value) {
          setState(() { isCompleted = value; });
        }
      )
    ]);
  }
}

Eleganz eines 🧱

Für und gegen Flutter

Flutter Pain Points

  • • Cursed Syntax
  • • setState() für jeden Furz
  • • Boilerplate Code überall

Warum ich trotzdem Flutter nutze

  • • Cross-Platform aus einer Codebase
  • • Hot Reload ist tatsächlich nice
  • • Learning Experience
  • • Enorme Zeitersparnisse

Aktueller Status: Miniprototyp in Entwicklung


Wo stehe ich gerade? Der Miniprototyp zeigt das Grundkonzept: Lehrbericht erstellen, bearbeiten, simple Synchronisation. Noch buggy, aber die Vision ist sichtbar. Das Backend läuft mit Kotlin Spring Boot, die erste Flutter-App funktioniert auf beiden Plattformen.

Derzeit baue ich das eigene Backend für echte Multi-User-Funktionalität aus. Digitale Unterschriften und die komplette Privacy-First Infrastruktur dauern noch, aber der Grundstein ist gelegt.

Entwicklungsstand heute

Was bereits funktioniert

Working
Grundlegende UI ✓ Done
Bericht erstellen/bearbeiten ✓ Done
Lokale Speicherung (SQLite) ✓ Done
Sich registrieren und anmelden ✓ Done

Was noch entwickelt wird

In Progress
Eigenes Backend (Kotlin) 🚧 Building
Multi-User Support 🚧 Building
Digitale Unterschriften 📋 Planned
End-to-End Encryption 📋 Planned

Erkenntnisse nach dem Flutter-Experiment

Swift > Flutter (Syntax)
Es lohnt sich, über seinen Schatten zu springen und Lösungen sachlich zu betrachten.
Zeit
Auch wenn ich bisher nicht mit Flutter warm geworden bin, kann ich nicht leugnen, dass es die Zeitersparnis wert ist.
Hot Reload
Not Gonna Lie ist ein brutal gutes Feature, was ich so bei Swift und Kotlin vermisse.

What's next?


Backend fertigstellen, Multi-User Support implementieren, digitale Unterschriften hinzufügen. Der Miniprototyp zeigt: Die Idee funktioniert, die Technik ist solide, das Problem ist real.

Ich bin guter Dinge, dass die Beta im Sommer 26 an den Start geht, wenn nicht vorher der Feature-Creep zuschlägt.