Standout Builder Studio · planning Index / Users & surfaces review Updated 16 Jun 2026

Users & surfaces

The platform serves three distinct user types across three separate surfaces. We (internal — the Standout team) are the primary users while building out. Access is role-based from day one, with operator and builder scopes fully defined but dormant until those audiences onboard.

CONCEPT · proposed

The three-persona model

Persona Surface Auth What they do
Operators external B2B apps/portal Magic link (Resend) Browse the game catalogue and roadmap, view game factsheets, open permitted embedded demos, chat with the Standout team via per-game threads. Later: manage their own organisation's users and settings.
Builders external / us now Builder Studio — today inside apps/web Account / role (TBD) Pick a build path, configure game mechanics, package assets, and launch a playable sandbox session. Background agents do the engineering work; builders approve at gates.
Internal — us apps/web dashboard Cloudflare Access (Google SSO) Pipeline management, builder oversight, operator administration, portal publishing and grants, revenue visibility, game certification. All sensitive surfaces are Access-gated.
We are the builders right now
Until external game builders onboard, the internal team uses the Builder Studio surface as well as the dashboard. Builder scopes are defined in the data model today so the access separation is already correct — we simply operate both roles.

The admin panel: split, not merged

The operator-management admin pulled from standout-games/apps/admin serves two distinct personas, so rather than porting it as a single standalone app it splits along those lines:

Half Persona Destination Auth Status
Super-admin Internal — us Merges into the dashboard's existing Operators area in apps/web Cloudflare Access (behind the gate already in place) planned
Operator-scoped Operators (B2B) Goes into the portal (apps/portal), magic-link-gated and scoped to that operator's own organisation Magic link — existing portal session deferred

The super-admin half covers: create and configure operators, set global platform settings, and provision operator-level user accounts. The operator-scoped half covers: an operator managing their own org's users, contact details, and notification preferences — deferred until operators actively onboard and request self-service.

Net outcome: three apps, three personas, no standalone admin app
apps/web serves internal (dashboard + Builder Studio + super-admin). apps/portal serves operators (catalogue, chat, and eventually org self-service). The former apps/admin is dissolved into the two existing apps — no third surface to maintain.

Access model summary

Each surface enforces access independently. There is no shared session or single sign-on across surfaces — an operator magic-link session cannot reach the dashboard, and a dashboard Cloudflare Access session cannot reach the portal's operator-scoped data.

Surface Gate Scope isolation
apps/web dashboard Cloudflare Access — Google SSO, @vhslab.com allowlist Full platform — all operators, all games, all revenue data
apps/portal Magic link (Resend) — signed session cookie, email-verified Operator-scoped — only that operator's grants, catalogue view, and conversations
Builder Studio (inside apps/web) Same Cloudflare Access gate as dashboard — builder role TBD Build pipeline — game specs, sandbox sessions, certification queue