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.
05 · 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. Dashboard-Schicht: Das authentifizierte Dashboard übernimmt Projektverwaltung, Seitenbearbeitung, QR-Generierung, Abo-Status und Benutzereinstellungen. Backend-Schicht: Liefert die Produktregeln — Authentifizierung, Ownership, Seitenidentität, Publish-Status, Tariflimits und öffentliche Seitenauflösung. Öffentliche Rendering-Schicht: Wird von stabilen URLs ausgeliefert, damit verteilte QR-Codes weiter funktionieren, auch wenn sich Inhalte ändern. Integrations-Schicht: Verbindet Account-, Abo- und Seitenverwaltungs-Workflows über eine gemeinsame API-Schicht mit konsistentem Error-Handling, Session-Verhalten und Validierung. 04 · Backend-API und Datenmodell Strukturiert um die Produktentitäten, die für eine QR-verknüpfte SaaS-Plattform zentral sind: Benutzer und Authentifizierung; Projekte und Ownership; Seiten und öffentliche Identifier; Seiteninhalte und Publish-Status; QR-Referenzen; Abo-Pläne und Nutzungslimits; Feature-Zugriffsregeln; Daten für das öffentliche Rendering. Diese Trennung hält die Plattform flexibel: Öffentliche URLs bleiben stabil, während sich Seiteninhalte, Tarifregeln und Dashboard-Funktionen dahinter weiterentwickeln können. Öffentliches Seiten-Rendering Veröffentlichte Seiten werden über stabile öffentliche Routen ausgeliefert. Die öffentliche Rendering-Schicht löst jede Seite anhand ihres öffentlichen Identifiers auf, lädt den aktuell veröffentlichten Inhalt und zeigt die Seite, ohne dass sich der Besucher anmelden muss. Das schafft eine saubere Trennung zwischen: • privater Dashboard-Bearbeitung • Backend-Validierung und Zugriffskontrolle • öffentlicher Seitenauslieferung • stabilen QR-verknüpften 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.
