Why we built Hypertag this way

Most QR systems stop at static links. That creates operational drag: reprints for updates, no control after deployment, and no reliable path to automation.

Hypertag is built to solve that constraint. Every tag is treated as a programmable endpoint tied to a physical asset, not just a one-time redirect.

What is live in the MVP

• Marketing site and product narrative around dynamic tags.
• Firebase authentication with email/password and Google OAuth.
• Protected `/webapp/*` routes using session-cookie middleware and client guards.
• Tag creation with two modes: `Direct` and `Hyper`.
• Full lifecycle states: `Draft`, `Inactive`, and `Active`.
• Staging and active views with inline editing and maintenance actions.
• QR download support for each tag with fallback generation behavior.

Why lifecycle matters

The key product behavior is not code generation. It is lifecycle control over deployed tags.

• `Direct` tags let teams control destination links without reprinting.
• `Hyper` tags allow webhook and payload configuration for system-to-system workflows.
• Status transitions provide an operational model instead of ad hoc link management.

That model makes physical deployments maintainable over time.

Data model direction

Current Firestore-backed fields already reflect orchestration intent:

• identity and ownership (`name`, `userId`)
• behavior (`type`, `status`)
• destination configuration (`link`)
• integration configuration (`webhook`, `payload`)
• time context (`createdAt`)

This is enough to validate ownership, state transitions, and controlled mutation of live behaviors.

Where this goes next

The next phase is runtime intelligence:

• scan ingestion endpoints
• route resolution and decision logic
• event history and observability
• deeper webhook and API integrations
• role and tenant structure for broader deployment

The long-term target is clear: Hypertag should operate as a programmable edge layer for physical-to-digital interaction, not as a static QR utility.