FireAdministration/docs/AUFWANDSSCHAETZUNG.md

Aufwandsschätzung

Schätzung je Phase, daneben der tatsächliche Aufwand aus dem Devlog. Stand: 3. September 2026.

Wie hier gerechnet wird

Es stehen bewusst zwei Größen nebeneinander, weil sie Verschiedenes aussagen:

Größe	Bedeutung
Sitzungszeit	Wie lange Claude tatsächlich gearbeitet hat. Das ist die Zahl, die im Devlog steht, und die Grundlage für die Planung der nächsten Sitzung.
Vergleichsaufwand	Was eine einzelne Person mit diesem Stack für dasselbe Ergebnis gebraucht hätte, in Personentagen zu 8 Stunden. Das ist die Zahl, die gegenüber der Wehr etwas bedeutet — sie beantwortet „was wäre das sonst wert gewesen".

Der Vergleichsaufwand ist eine Schätzung, keine Messung. Er unterstellt jemanden, der den Stack kennt, die Feuerwehr-Fachlichkeit aber erst klären muss — also Recherche zu DGUV-Fristen, FwDV 3 und FwDV 7 einschließt.

Faktoren, die in die Schätzung eingehen:

• Fachlichkeit — wie viel muss geklärt werden, bevor gebaut werden kann?
• Sicherheitsbezug — Atemschutz und Prüfnachweise brauchen mehr Tests und mehr Sorgfalt als eine Adressliste.
• Fremdsysteme — Gotenberg, Nominatim, tileserver-gl, Ollama, RFID-Leser. Jedes ist eine eigene Fehlerquelle.
• Offline und Echtzeit — die teuersten Anforderungen im ganzen Projekt.

Übersicht

Phase	Inhalt	Vergleichsaufwand	Sitzungszeit geschätzt	Sitzungszeit tatsächlich
0	Fundament	12–16 PT	—	1:00 h
1	Stammdaten	10–14 PT	2,5–3,5 h	offen
2	Wartung und Prüfung	18–24 PT	4,5–6 h	offen
3	Einsätze und Übungen	12–16 PT	3–4 h	offen
4	Kiosk-PWA mit Offline	16–22 PT	4–5,5 h	offen
5	Atemschutz (FwDV 7)	14–18 PT	3,5–4,5 h	offen
6	Kartenmodule	14–18 PT	3,5–4,5 h	offen
7	Benachrichtigungen und Termine	10–13 PT	2,5–3,5 h	offen
8	Lokale KI	9–12 PT	2,5–3 h	offen
	Summe	115–153 PT	26–34 h

115–153 Personentage entsprechen etwa 6 bis 8 Monaten Vollzeitarbeit einer einzelnen Person. Zum Vergleich: eine kommerzielle Feuerwehrverwaltung kostet je nach Umfang 500 bis 2.500 Euro im Jahr, dauerhaft, mit den Daten beim Anbieter.

---

Phase 0 — Fundament

Vergleichsaufwand: 12–16 PT · Tatsächlich: 1:00 h Sitzungszeit

Baustein	PT
Monorepo, Werkzeuge, TypeScript, Tailwind, shadcn	1,5
Docker Compose, Dockerfile, Traefik, Healthchecks	2,5
Prisma-Schema der Basismodelle	2,0
Row Level Security samt Rollen- und Rechtekonzept in Postgres	2,5
Auth.js mit OIDC, lokalem Login und Terminal-Anmeldung	3,0
storage, audit, warteschlange, Integrationsschnittstellen	2,0
Basis-Layout, Anmeldeseite, Übersicht, Dark Mode	1,5
Seed, Vitest, Playwright, Dokumentation	1,5

Das Teuerste war nicht der sichtbare Teil, sondern die Mandantentrennung. RLS so aufzusetzen, dass Migrationen, Seed und Anmeldung funktionieren und die Anwendung trotzdem nichts Fremdes sieht, verlangt zwei getrennte Datenbankzugänge und ein sauberes Verständnis davon, wann welcher greift. Wer das nachträglich einbaut, zahlt ein Vielfaches.

Phase 1 — Stammdaten

Vergleichsaufwand: 10–14 PT

Baustein	PT
Modelle: Standort, Geraeteraum, Geraetetyp, Qualifikation	1,5
Fahrzeug und Geraet um DIN-Typisierung und Lebensdauer erweitern	1,5
Tabellen mit Sortierung, Filter, Volltextsuche, Spaltenauswahl	3,0
QR-Code je Gerät, Etikettenbogen als PDF (65 Etiketten, DIN A4)	1,5
QR-Scan im Browser über die Kamera	1,0
CSV-/Excel-Import mit Spaltenzuordnung und Vorschau	2,5
Gerätehistorie aus dem Audit-Log	1,0
Massenbearbeitung und Tastaturbedienung	1,0

Der Import ist der Posten, der erfahrungsgemäß aus dem Ruder läuft. Jede Wehr bringt eine andere Excel-Datei mit, und die Vorschau vor dem Übernehmen ist kein Komfort, sondern die Bedingung dafür, dass die Wehr dem Ergebnis traut.

Phase 2 — Wartung und Prüfung

Vergleichsaufwand: 18–24 PT — die aufwendigste Phase

Baustein	PT
Modelle: Vorlage, Checklistenpunkt, Termin, Prüfung, Ergebnis, Mangel, Rückruf	3,0
Fristen-Dashboard mit Gruppierungen	2,5
Nächtlicher BullMQ-Job: Termine erzeugen, Status setzen, erinnern	2,5
Prüfungs-Wizard mit Fotoupload je Checklistenpunkt	3,5
Unterschrift auf Canvas, Touch und Maus	1,5
PDF-Protokoll über Gotenberg mit Fotos und Signatur	3,0
Unveränderlichkeit und Korrekturprotokolle mit Verweis	1,5
Lebensdauerüberwachung und Aussonderungsvorschlag	1,5
Rückrufe, externe Wartung, Mängel-Workflow	2,5

Hier entsteht der eigentliche Wert: die Software wird zum Nachweis gegenüber der Unfallkasse. Das heißt aber auch, dass jeder Fehler teuer ist. Die Unveränderlichkeit abgeschlossener Protokolle ist der Kern — und der Grund, warum der Audit-Log schon in Phase 0 append-only ist.

Phase 3 — Einsätze und Übungen

Vergleichsaufwand: 12–16 PT

Baustein	PT
Modelle: Einsatz, Einsatzfahrzeug, Einsatzkraft, Material, Lagemeldung, Übung	2,0
Schnellerfassung mit Nachtragen	1,5
Geocoding über self-hosted Nominatim mit Rückfallweg	1,5
Personalauswahl nach Verfügbarkeit und Qualifikation	2,0
Stärkeberechnung nach FwDV 3	1,0
Einsatzbericht als PDF, Jahresexport für die Gemeinde	2,0
Statistik: Kategorien, Eintreffzeiten, Beteiligung, Auslastung	2,5
Externes Portal mit signiertem QR-Link, ohne Login, rate-limited	2,0

Das externe Portal für Fremdwehren ist sicherheitsrelevant: ein Zugang ohne Anmeldung, der zeitlich begrenzt und mengenbegrenzt sein muss. Der Aufwand steckt weniger in der Funktion als in der Absicherung.

Phase 4 — Kiosk-PWA

Vergleichsaufwand: 16–22 PT

Baustein	PT
Eigenes Kiosk-Layout, 64px-Ziele, hoher Kontrast, kein Hover-Zwang	2,0
Anmeldung per RFID (WebHID), PIN und QR vom Handy	2,5
Wizards: Wartung, Fahrtenbuch, Mangel, Inventur, Wäsche, Anwesenheit	4,0
Hallen-Monitor mit DWD-Wetterwarnung	2,0
Service Worker, App-Shell und Stammdaten offline	3,0
IndexedDB-Outbox mit Idempotenzschlüssel und Synchronisation	4,0
Konfliktbehandlung und Konfliktliste für den Administrator	2,0
Playwright-Tests für den Offline-Fall	1,5

Offline-Fähigkeit mit schreibenden Aktionen ist die technisch schwierigste Anforderung des ganzen Projekts. Eine Outbox ist schnell gebaut; dass sie unter Verbindungsabbruch, Doppelklick und parallelem Zugriff von zwei Terminals nichts verliert und nichts doppelt schreibt, ist die eigentliche Arbeit. Die Idempotenzschlüssel sind dafür der Schlüssel, nicht die Synchronisation.

Phase 5 — Atemschutz nach FwDV 7

Vergleichsaufwand: 14–18 PT

Baustein	PT
Modelle: Atemschutzeinsatz, Trupp, Druckmessung, G26, Belastungsübung	2,0
Truppanlage per RFID, Eingangsdruck	1,5
Serverseitig autoritative Timer, Socket.IO-Verteilung	3,5
Rückzugsdruck-Berechnung, Ampel, akustischer Alarm	2,0
Erinnerung zur Druckabfrage im Intervall	1,0
Mayday-Knopf mit Protokolleintrag	1,0
Lückenloses PDF-Protokoll am Einsatz	1,5
G26.3-Fristen, Belastungsübungen, Tauglichkeitsampel	2,0
Tests: Reload und Verbindungsabbruch überstehen	2,0

Der Aufwand liegt nicht in der Funktion, sondern im Beweis, dass sie hält. Ein Timer, der einen Reload überlebt, ist Pflicht — deshalb muss die Zeit serverseitig geführt werden und der Browser nur anzeigen. Diese Phase bekommt den höchsten Testanteil im Projekt.

Phase 6 — Kartenmodule

Vergleichsaufwand: 14–18 PT

Baustein	PT
MapLibre GL, tileserver-gl, MBTiles fürs Ausrückegebiet	2,5
Hydranten mit PostGIS, Cluster, Filter, Umkreissuche	3,0
Import aus GeoJSON und Stadtwerke-CSV	1,5
Objekte und Feuerwehrpläne nach DIN 14095, Volltextsuche	3,0
Lagekarte mit taktischen Zeichen nach FwDV 102 als SVG-Set	3,5
Echtzeit-Sync der Lagekarte zwischen Geräten	2,0
Wasserförderung: Höhenprofil, Druckverlust, Verstärkerpumpen	2,5

Das SVG-Set für die taktischen Zeichen ist Fleißarbeit, aber unvermeidbar — fertige Sets sind selten frei verwendbar. Die Wasserförderungsberechnung ist Physik mit klaren Formeln und deshalb gut testbar.

Phase 7 — Benachrichtigungen und Termine

Vergleichsaufwand: 10–13 PT

Baustein	PT
Kanalabstraktion: E-Mail, Telegram, ntfy, Web-Push	2,5
Vorlagen mit Platzhaltern, je Ereignis und Rolle	2,0
Abonnements je Person	1,0
Kalender mit Serienterminen und Selbstanmeldung	3,0
CalDAV-/ICS-Feed je Person mit Token	1,5
Digitaler Dienstausweis mit signiertem QR und Prüfseite	2,0

Das Grundgerüst der Kanalabstraktion steht bereits aus Phase 0 (lib/integrations/), das spart hier etwa einen Personentag.

Phase 8 — Lokale KI

Vergleichsaufwand: 9–12 PT

Baustein	PT
lib/ai/ mit OpenAI-kompatiblem Client, abschaltbar	1,0
Diktat: Aufnahme im Browser, faster-whisper, Transkript	2,5
Berichtsassistent mit Übernehmen/Verwerfen	2,0
Wiki mit pgvector, semantische Suche, RAG mit Quellenangabe	3,5
Belegerfassung über ein Vision-Modell, immer bestätigen	2,0

Der Client aus Phase 0 (lib/integrations/llm.ts) ist bereits vorhanden. Die Kennzeichnungspflicht — jede KI-Ausgabe ist als solche erkennbar und muss bestätigt werden, bevor sie in ein Dokument mit Nachweischarakter gelangt — kostet wenig Zeit, ist aber nicht verhandelbar.

---

Was hier nicht drin ist

Kassenmodul. Die Rolle KASSIER ist in Phase 0 gefordert und angelegt, die Rechte kasse.lesen, kasse.bearbeiten und kasse.abschluss stehen bereit. Ein Kassenmodul kommt in keiner der Phasen 0 bis 8 vor. Geschätzter Vergleichsaufwand, falls gewünscht: 8–11 PT für Buchungen, Beiträge, Rechnungen, Kassenabschluss und Jahresauswertung. Siehe ROADMAP.md.

Betrieb und Einführung. Datenübernahme aus der Altsoftware, Schulung der Wehr, Sicherungskonzept, Monitoring: nach Erfahrung noch einmal 15 bis 25 Prozent des Entwicklungsaufwands.