Kurz im README: was die Anwendung kann, auf einen Blick. Lang in docs/funktionen.md: jeder Typ mit seinen Grenzen, dazu Landingpages, Dateien, Feedback, Rechte, Single Sign-on, Domains und Betrieb — samt der Frage, warum manches so entschieden ist. docs/roadmap.md haelt fest, was in welcher Reihenfolge gebaut wurde, und sammelt Vorschlaege fuer danach. Bewusst als Vorschlaege mit grober Aufwandsschaetzung, nicht als Zusage: was zuerst kommt, entscheidet, was im Betrieb fehlt.
5.7 KiB
Roadmap
Was gebaut ist, und was danach sinnvoll wäre. Der zweite Teil ist eine Sammlung von Vorschlägen mit einer groben Einschätzung des Aufwands — keine Zusage und keine Reihenfolge. Was zuerst kommt, entscheidet, was im Betrieb fehlt.
Gebaut
Version 1 — Grundgerüst (13.08.2026)
- Next.js-Anwendung und PostgreSQL als Docker-Compose-Stack, ohne Reverse Proxy, Migrationen beim Start
- QR-Typ-Registry als Dispatch-Tabelle — ein neuer Typ ist ein Modul plus ein Formular, ohne Eingriff in den übrigen Code
- Typ Website, statisch und dynamisch, mit Kurz-URL, 302-Weiterleitung und Scan-Zähler
- Gestaltung: Farben mit Kontrastwarnung, Größe, Fehlerkorrektur, Rand
- Download als PNG und SVG, serverseitig gerendert
- „Meine Codes“ mit Ziel ändern und Löschen
- Deutsche Oberfläche, deutsche Fehlermeldungen, Validierung mit Zod
- Update-Skript für Linux/macOS und Windows
Typen einzeln freigeben (14.08.2026)
Ausblenden nicht gebrauchter Typen in der Verwaltung. Bereits erstellte Codes eines abgeschalteten Typs funktionieren weiter.
Phase A — acht weitere Typen (14.08.2026)
vCard, App-Link, WhatsApp, E-Mail, SMS, Standort, Zahlung (GiroCode und Zahlungslink), WLAN.
Phase B1 — Anmeldung, Gruppen, Rollen (14.08.2026)
Abschaltbare Anmeldung, Benutzerverwaltung, Gruppen mit den Rollen Administrator, Bearbeiter und Betrachter, Sitzungen in der Datenbank, scrypt-Passwörter, Sperre nach Fehlversuchen.
Phase B2 — mehrere Domains (14.08.2026)
Domains für Kurz-URLs, den Gruppen zugeteilt. Slug je Domain eindeutig, Host-Header gegen die registrierten Domains geprüft.
Listenansicht (14.08.2026)
„Meine Codes“ als Liste mit Suche, Sortierung und Gruppenfilter — gedacht für viele Projekte nebeneinander. Karten bleiben als zweite Ansicht.
Phase C — die letzten sechs Typen (14.08.2026)
Mehrere Links, Social Media, Video, PDF, Bild, Feedback. Dazu:
- Landingpages als eigene Gattung (
/s/{slug}), ohne App-Navigation - Datei-Upload mit Inhaltsprüfung, Größengrenze und Aufräumen
- Feedback mit anonymer Erhebung und Auswertung
Damit sind alle 15 vorgesehenen Typen gebaut.
Single Sign-on (15.08.2026)
Anmeldung über Authentik und andere OIDC-Anbieter, mit PKCE und geprüftem ID-Token.
Dokumentation (15.08.2026)
Bedienungsanleitung mit Bildern, Authentik-Anleitung, Funktionsübersicht. Die Bilder erzeugt ein Skript, damit sie nicht veralten.
Denkbar als Nächstes
Die Einschätzungen sind grobe Hausnummern für eine Person, die den Code kennt.
Naheliegend
Statistik über die Zeit · mittel Der Zähler weiß heute nur, wie oft und wann zuletzt. Ein Verlauf je Tag wäre eine eigene Tabelle plus ein Diagramm in der Codeansicht. Die eigentliche Frage ist nicht die Technik, sondern wie lange man so etwas aufbewahrt — und was man dabei über die Scannenden erfährt. Ein reiner Tageszähler ohne Herkunft und Gerät ist unbedenklich und würde für „läuft die Kampagne?“ genügen.
Codes exportieren · klein Eine CSV aller Codes einer Gruppe mit Name, Kurz-URL, Ziel und Scans — für die Übergabe an eine Druckerei oder die Ablage.
Papierkorb statt Löschen · klein Gelöschte Codes 30 Tage aufheben, dann endgültig entfernen. Heute ist ein gedruckter Code nach einem Fehlklick unwiederbringlich tot.
Codes duplizieren · klein „Wie dieser, aber mit anderem Ziel“ — bei vielen ähnlichen Projekten spart das jedes Mal ein paar Minuten.
Wenn der Bedarf da ist
Stapelverarbeitung · mittel Eine CSV hochladen und daraus 200 Codes erzeugen, als ZIP zurück. Sinnvoll, sobald jedes Produkt oder jeder Tisch einen eigenen Code bekommt.
Gruppen aus dem Verzeichnis übernehmen · mittel Die OIDC-Anbindung übernimmt heute bewusst nur die Identität. Eine Zuordnung von Verzeichnisgruppen zu Gruppen dieser Anwendung ist möglich, braucht aber eine klare Regel dafür, was mit von Hand vergebenen Rollen geschieht — sonst verliert jemand beim nächsten Anmelden stillschweigend seine Rechte.
Logo im QR-Code · mittel Ein kleines Bild in die Mitte setzen, mit erzwungener Fehlerkorrektur H und einer Warnung, wenn zu viel verdeckt wird. Braucht eine ehrliche Prüfung mit mehreren Scanner-Apps, sonst entstehen Codes, die nur auf dem eigenen Handy funktionieren.
Ablaufdatum und Zeitsteuerung · mittel Ein Code, der ab einem Datum woandershin führt oder abläuft — für Veranstaltungen und Aktionen.
Passwortgeschützte Landingpages · mittel Für Unterlagen, die nicht jeder sehen soll, der den Aushang fotografiert. Heute ist die Empfehlung klar: Vertrauliches gehört nicht hinter einen offenen QR-Code.
Größere Brocken
Mehrsprachige Oberfläche · groß Die Anwendung ist durchgehend deutsch, auch in den Fehlermeldungen und den Landingpages. Eine zweite Sprache berührt jede Datei.
Eigene Gestaltung der Landingpages · groß Logo, Farben und Schrift je Gruppe, damit die Seite nach der eigenen Firma aussieht. Technisch überschaubar, gestalterisch eine eigene Aufgabe — und es braucht Grenzen, damit nichts Unlesbares entsteht.
Dateien außerhalb der Datenbank · mittel
Heute liegen Uploads in PostgreSQL, damit es bei einem Volumen bleibt. Wer
sehr viele oder sehr große Dateien ablegt, will sie irgendwann auf einem
Objektspeicher (S3) haben. Der Wechsel betrifft nur src/lib/uploads.ts und
die Auslieferungsroute — aber auch die Sicherungsstrategie.
Wie ein neuer Typ dazukommt
Falls doch noch einer fehlt: Er besteht aus einem Modul in
src/lib/qr/types/, einer Formular-Komponente, je einem Registry-Eintrag und
— wenn er eine eigene Seite braucht — einer Landingpage. Am übrigen Code
ändert sich nichts. Näheres im README, Abschnitt „Einen
weiteren Typ ergänzen“.