Sieben Projekte aus unserer Werkstatt

• 30 Testreihen, davon 14 gegen echte Firebase-Emulatoren statt gegen Attrappen
• Eigene Tests für die Datenbank- und Speicherregeln: geprüft wird, dass die falsche Rolle die Daten wirklich nicht bekommt
• Gestufter Deploy: Regeln, Funktionen, Speicher und Oberfläche gehen in fester Reihenfolge live
• Nächtliche Sicherung eingerichtet und das Zurückspielen nachgewiesen, nicht nur eingeplant
• Browsertests mit Playwright über drei getrennte Anmeldungen

Der Auftraggeber sieht die Leistung, nicht die Arbeitszeiten. Diese Trennung war eine Zusage an den Kunden. Sie steht deshalb in den Datenbankregeln und wird von eigenen Tests geprüft.

• 293 automatisierte Tests in 9 Testdateien, alle grün (gemessen am 25.08.2026)
• Die Pausenlogik nach §§ 3 bis 5 Arbeitszeitgesetz liegt in der Datenschicht, nicht in der Oberfläche, denn ausgegraute Schaltflächen schützen niemanden
• Rechteregeln pro Rolle in der Datenbank, nicht nur im Frontend
• Auftragsverarbeitungsvertrag, Verarbeitungsverzeichnis und TOM-Beschreibung liegen geschrieben vor

• Datenbank und Dateispeicher stehen auf Grundregel „alles verboten“: Nur die serverseitigen Funktionen schreiben, aus dem Browser kommt niemand an die Daten
• Schadenmeldung mit Ratenbegrenzung pro Absender, Prüfung von Eingaben und Dateigrößen — nicht nur im Formular, sondern auf dem Server
• Signaturschlüssel für die Wallet-Karten liegen als Firebase-Secrets, nie im Quelltext und nie in der Git-Historie
• HTTPS erzwungen, HTTP wird dauerhaft umgeleitet

• Zwei Dokumente statt einem: die Website liest ohne Anmeldung, deshalb darf das öffentliche Dokument keine internen Notizen und keine Redakteursnamen enthalten — die Trennung liegt im Datenmodell, nicht in der Oberfläche
• Browsertests laufen gegen dieselben Sicherheitsregeln (CSP), die das Hosting später ausliefert, inklusive der strengeren Regel für den Redaktionsbereich: Eine Seite, die nur ohne diese Regeln funktioniert, fällt im Test durch statt nach dem Deploy
• Getestet werden auch arabischer Rechts-nach-links-Satz, Handy- und Desktop-Layout, die Anfragestrecke und reduzierte Bewegung
• Messung ist standardmäßig aus: Solange die vier Kennungen leer sind, lädt kein fremdes Skript, es gibt keinen Zustimmungsdialog und keinen Speicherzugriff
• Kampagnenparameter werden an die vorbereitete WhatsApp-Nachricht angehängt, damit die Beratung die Quelle sieht, ohne ein Auswertungswerkzeug zu öffnen

• Statisch ausgeliefert: keine Datenbank im Auslieferungsweg, nichts, was zur Ladezeit ausfallen kann
• Keine Tracker und keine extern geladenen Schriften, damit ist kein Einwilligungsbanner nötig
• Die Datenbankregeln werden bewusst nicht aus diesem Projekt veröffentlicht, damit eine Änderung an der Website nie die Regeln des Portals überschreiben kann

• Statisch ausgeliefert: keine Datenbank, keine serverseitige Ausführung, nichts, was ausfallen kann
• Keine Tracker und keine externen Schriften, damit ist auch kein Einwilligungsbanner nötig
• Domain am 28.08.2026 umgezogen, ohne die Firmen-E-Mail anzufassen: nur die zwei Wegweiser-Einträge für die Website geändert, die sieben für den Mailversand blieben unberührt

• Statisch ausgeliefert über Firebase Hosting: keine Datenbank, keine serverseitige Ausführung
• Keine Tracker, keine Cookies, keine externen Schriften, keine eingebetteten Fremdvideos; Instagram öffnet sich nur, wenn jemand einem Link folgt (geprüft an der Live-Seite am 08.10.2026)
• Strenge Content-Security-Policy, die nur eigene Quellen und zwei hinterlegte Inline-Skripte erlaubt, dazu HSTS und weitere Sicherheitsköpfe; fehlt einem Inline-Skript der Hash, bricht der Build ab
• Auszeichnung für Suchmaschinen als LocalBusiness mit Angebotskatalog und als FAQPage, dazu Sitemap und kanonische Adresse
• Das Build-Skript bricht außerdem ab bei Dateitypen, die nicht veröffentlicht werden sollen, und bei Platzhaltern oder Arbeitsnotizen im fertigen HTML; für die Live-Adresse gibt es einen Smoke-Test