Entscheidungskontext
Das Projekt barg ein strukturelles Risiko, das viele frühe SaaS-Produkte unterschätzen: Öffentliche Referenzen werden dauerhaft.
Ein QR-Code auf einem Flyer, einer Visitenkarte, einer Verpackung oder einem Kampagnenmaterial lässt sich nicht wie ein normaler Link innerhalb einer Website aktualisieren. Ist das Seitenmodell zu starr, bricht das Produkt entweder bestehende Referenzen oder erfordert einen Rewrite, sobald neue Anwendungsfälle hinzukommen.
Die Plattform musste drei häufige Fehler vermeiden:
- einen QR-Code direkt an eine feste Inhaltsversion zu koppeln
- jede öffentliche Seite als statische Datei zu behandeln, statt als verwaltbare Produktentität
- Abo-Limits nur in der UI durchzusetzen, statt im Backend und im öffentlichen Rendering
Das System musste jede Seite als stabiles digitales Objekt behandeln: eine öffentliche Referenz, editierbarer Inhalt dahinter, kontrollierte Publish-Regeln und tarifbewusster Feature-Zugriff.
Was wir gebaut haben
01 · Dynamischer Seiten-Builder
Ein modularer Editor zum Erstellen QR-verknüpfter öffentlicher Seiten. Nutzer bauen Seiten aus wiederverwendbaren Inhaltsabschnitten: Textblöcke, Links, Kontaktdaten, strukturierte Content-Bereiche und kampagnenspezifische Module. Der Builder wurde so konzipiert, dass neue Seitentypen und Content-Module später ergänzt werden können, ohne das zentrale Public-URL-Modell zu verändern.
02 · QR-Code-Generierung
Die Plattform erzeugt QR-Codes für veröffentlichte Seiten und hält sie mit stabilen öffentlichen Routen verbunden. Anwendungsfälle: persönliche Profilseiten; Kampagnen-Landingpages; Event- oder Promotion-Seiten; Produktinformationsseiten; Service-Menüs; Kontakt- oder Buchungsseiten; interne Referenzseiten. Das zentrale Produktprinzip: Der QR-Code bleibt unverändert, während sich der Inhalt dahinter ändern kann.
03 · Benutzer-Dashboard
Ein strukturierter Arbeitsbereich zur Verwaltung von Projekten, Seiten, QR-Codes und Account-Einstellungen. Nutzer können Projekte anlegen und organisieren; Seiten erstellen, bearbeiten und veröffentlichen; QR-verknüpfte öffentliche URLs verwalten; Abo-Status und Feature-Limits einsehen; Account- und Profildaten aktualisieren; Inhalte ohne Entwickler-Support pflegen.
04 · Abonnements und Funktionslimits
Tarifbasierte Zugriffslogik für SaaS-Monetarisierung. Anzeige des Abo-Status; tarifbasierte Seitenlimits; Feature-Verfügbarkeit pro Tarif; Upgrade-/Downgrade-Zustände; konsistente Zugriffsprüfungen über Dashboard-Aktionen und Backend-Regeln hinweg. Damit wird verhindert, dass Feature-Gating zu einem reinen Frontend-Pflaster wird, und bezahlte Limits bleiben auf Produktebene durchsetzbar.
Architektur
Die Plattform wurde als SaaS-Produkt konzipiert, nicht als statischer Seitengenerator. Verwaltungsoberfläche: Der geschützte Bereich übernimmt Projektverwaltung, Seitenbearbeitung, QR-Generierung, Abo-Status und Benutzereinstellungen. Backend: Hier liegen die Produktregeln für Authentifizierung, Eigentümerschaft, Seitenidentität, Veröffentlichungsstatus, Tariflimits und die Auflösung öffentlicher Seiten. Öffentliche Auslieferung: Stabile URLs sorgen dafür, dass verteilte QR-Codes weiter funktionieren, auch wenn sich Inhalte ändern. Integration: Eine gemeinsame API-Schicht verbindet Konten, Abonnements und Seitenverwaltung mit einheitlicher Fehlerbehandlung, Sitzungslogik und Validierung. 05 · Backend-API und Datenmodell Das Datenmodell bildet die zentralen Produktobjekte ab: Benutzer und Authentifizierung; Projekte und Eigentümerschaft; Seiten und öffentliche Kennungen; Inhalte und Veröffentlichungsstatus; QR-Referenzen; Tarife und Nutzungslimits; Zugriffsregeln; Daten für die öffentliche Auslieferung. Diese Trennung hält die Plattform flexibel: Öffentliche URLs bleiben stabil, während sich Inhalte, Tarifregeln und Funktionen im geschützten Bereich weiterentwickeln können. Öffentliche Seitenauslieferung Veröffentlichte Seiten werden über stabile öffentliche Routen ausgeliefert. Das System löst jede Seite anhand ihrer öffentlichen Kennung auf, lädt den freigegebenen Inhalt und zeigt ihn ohne Anmeldung an. So bleiben vier Bereiche sauber voneinander getrennt: • Bearbeitung im geschützten Bereich • Validierung und Zugriffskontrolle im Backend • öffentliche Seitenauslieferung • stabile, mit QR-Codes verknüpfte Referenzen
Frontend-Stack und Anwendungsstruktur
Frontend: Next.js App Router · React · TypeScript · React Query · React Hook Form · Zod · SCSS Modules. Anwendungsstruktur: • app/ — Routing und Seitenkomposition • features/ — fachliche Workflows (Auth, Abonnements, Projekte, QR-Verwaltung) • shared/ — wiederverwendbare UI- und Infrastruktur-Utilities
API-Integration
Ein zentraler API-Client übernimmt Request-Konfiguration, normalisierte Fehler, Session-Refresh und konsistentes Netzwerk-State-Handling über Dashboard- und öffentliche Oberflächen hinweg.
Authentifizierung und Backend-Logik
JWT-basierte Authentifizierung mit geschützten Dashboard-Routen, kontrolliertem Session-Refresh und Weiterleitungen für nicht eingeloggte Nutzer. Das Backend wurde auf die Stabilität öffentlicher Referenzen ausgelegt: Ein QR-Code zeigt nicht auf einen fragilen Seitenentwurf — er zeigt auf einen stabilen öffentlichen Identifier. Hinter diesem Identifier verwaltet das System die aktuell veröffentlichte Version, Zugriffsregeln, Account-Ownership und Tariflimits. Zentrale Backend-Verantwortlichkeiten: • Auflösung öffentlicher Seiten anhand stabiler Identifier • Schutz von Dashboard-Aktionen durch authentifizierte Ownership-Regeln • Validierung von Seiteninhalten vor der Veröffentlichung • Durchsetzung von Abo- und Feature-Limits • Trennung von Entwurfs-/Bearbeitungszustand und öffentlichem Rendering • Stabilität der QR-Referenzen auch bei Inhaltsänderungen • klar definierte API-Verträge für Dashboard- und öffentliche Oberflächen
Datenmanagement
React Query für Caching, Invalidation, gemeinsame Query-Keys und vorhersehbare Loading-/Error-Zustände über Dashboard- und Editor-Flows hinweg.
UI-System
SCSS Modules und Design-Tokens für visuelle Konsistenz über Dashboard, Builder und öffentliche Seiten hinweg.
Warum das wichtig ist
Dieses Produkt ist nicht einfach ein «Webseiten-Generator». Jede Seite ist eine verwaltbare SaaS-Entität mit: einer stabilen öffentlichen URL; editierbarem Inhalt; QR-Code-Zuordnung; Ownership-Regeln; tarifbasiertem Feature-Zugriff; Veröffentlichungsstatus; Dashboard-Steuerung; Logik für öffentliches Rendering. Dieser Unterschied zählt, weil QR-verknüpfte Seiten oft länger leben als die erste Produktversion. Die Architektur muss es erlauben, das Produktmodell weiterzuentwickeln, ohne gedruckte oder verteilte Links zu brechen.
Relevant für ähnliche Projekte
- QR-verknüpfte Produkte
- dynamische Landingpage-Tools
- digitale Visitenkarten-Plattformen
- Event- oder Kampagnen-Seiten-Builder
- SaaS-Dashboards mit Tariflimits
- öffentliche/private Content-Management-Systeme
- No-Code- oder Low-Code-Publishing-Workflows
- abo-basierte Content-Tools
Ergebnis
Das Produkt verfügt nun über ein strukturiertes SaaS-Fundament für die Verwaltung QR-verknüpfter dynamischer Seiten. Nutzer können Seiten anlegen, sie mit QR-Codes oder öffentlichen URLs verknüpfen, Inhalte über die Zeit aktualisieren und Projekte über ein persönliches Dashboard verwalten — ohne die öffentliche Referenz zu brechen, die bereits gedruckt, geteilt oder anderswo eingebettet ist. Für H-Studio zeigt der Case ein zentrales Architekturprinzip: Öffentliche Referenzen müssen stabil bleiben, während das dahinterliegende Produktmodell flexibel genug für Weiterentwicklung ist.
