The project carried a structural risk that many early-stage SaaS products underestimate: public references become permanent.
A QR code printed on a flyer, business card, package or campaign asset cannot be updated like a normal link inside a website. If the page model is too rigid, the product either breaks existing references or requires a rebuild when new use cases appear.
The platform needed to avoid three common mistakes:
The system had to treat every page as a stable digital object: one public reference, editable content behind it, controlled publishing rules and plan-aware feature access.
A modular editor for creating QR-linked public pages. Users build pages from reusable content sections such as text blocks, links, contact information, structured content areas and campaign-specific modules. The builder was designed so new page types and content modules can be added later without changing the core public URL model.


The platform generates QR codes for published pages and keeps them connected to stable public routes. Use cases: personal profile pages; campaign landing pages; event or promotion pages; product information pages; service menus; contact or booking pages; internal reference pages. The key product principle: the QR code stays the same, while the page content behind it can change.



A structured workspace for managing projects, pages, QR codes and account settings. Users can create and organise projects; create, edit and publish pages; manage QR-linked public URLs; view subscription status and feature limits; update account and profile information; manage content without developer support.


Plan-based access logic for SaaS monetisation. Subscription state display; plan-based page limits; feature availability per plan; upgrade/downgrade states; consistent access checks across dashboard actions and backend rules. This prevents feature gating from becoming a front-end-only patch and keeps paid limits enforceable at product level.
The platform was designed as a SaaS product, not a static page generator. Dashboard layer: authenticated dashboard handles project management, page editing, QR generation, subscription state and user settings. Backend layer: provides product rules — authentication, ownership, page identity, publish state, plan limits and public page resolution. Public rendering layer: served from stable URLs so distributed QR codes continue to work even when content changes. Integration layer: connects account, subscription and page-management workflows through a shared API layer with consistent error handling, session behaviour and validation. 04 · Backend API and data model Structured around the product entities that matter for a QR-linked SaaS platform: users and authentication; projects and ownership; pages and public identifiers; page content and publish state; QR references; subscription plans and usage limits; feature access rules; public rendering data. This separation keeps the platform flexible: public URLs remain stable, while page content, plan rules and dashboard features can evolve behind them. Public page rendering Published pages are rendered through stable public routes. The public rendering layer resolves each page by its public identifier, loads the current published content and displays the page without requiring the visitor to log in. This creates a clean separation between: • private dashboard editing • backend validation and access control • public page delivery • stable QR-linked references
Frontend: Next.js App Router · React · TypeScript · React Query · React Hook Form · Zod · SCSS Modules. Application structure: • app/ — routing and page composition • features/ — domain workflows (auth, subscriptions, projects, QR management) • shared/ — reusable UI and infrastructure utilities
A central API client handles request configuration, normalised errors, session refresh and consistent network-state handling across dashboard and public surfaces.
JWT-based authentication with protected dashboard routes, controlled session refresh and redirects for logged-out users. The backend was designed around the stability of public references: a QR code does not point to a fragile page draft — it points to a stable public identifier. Behind that identifier the system manages the current published version, access rules, account ownership and plan limits. Core backend responsibilities: • resolving public pages from stable identifiers • protecting dashboard actions behind authenticated ownership rules • validating page content before publishing • enforcing subscription and feature limits • separating draft/editing state from public rendering • keeping QR references stable even when content changes • exposing clean API contracts for dashboard and public surfaces
React Query for caching, invalidation, shared query keys and predictable loading/error states across the dashboard and editor flows.
SCSS Modules and design tokens for visual consistency across dashboard, builder and public pages.
This product is not just a «web page generator». Each page is a managed SaaS entity with: a stable public URL; editable content; QR code association; ownership rules; plan-based feature access; publishing state; dashboard controls; public rendering logic. That distinction matters because QR-linked pages often outlive the first version of the product. The architecture must allow the product model to evolve without breaking printed or distributed links.
The product now has a structured SaaS foundation for managing QR-linked dynamic pages. Users can create pages, connect them to QR codes or public URLs, update content over time and manage projects from a personal dashboard — without breaking the public reference already printed, shared or embedded elsewhere. For H-Studio, the case demonstrates a core architecture principle: public references should remain stable while the product model behind them stays flexible enough to evolve.